# Comment définir le header Content-Security-Policy dans chaque framework (/fr/blog/set-csp-header-every-framework)



Une politique de sécurité du contenu (CSP) ne protège les utilisateurs que lorsque
le navigateur la reçoit réellement, et la bonne façon de la transmettre est un
header de réponse. Cette page réunit la manière la plus courte d'envoyer ce
header dans les stacks qu'on nous demande le plus souvent, pour que vous trouviez
la vôtre, colliez l'extrait, puis passiez au réglage de la politique elle-même.

Deux règles valent pour tous les exemples ci-dessous. Commencez en
**Report-Only** (utilisez le nom de header `Content-Security-Policy-Report-Only`)
pour qu'une politique trop stricte se signale au lieu de casser la page pendant que
vous l'ajustez. Et définissez le header le plus haut possible dans la stack, dans
le reverse proxy ou le hook de réponse global du framework, pour ne pas avoir
à y penser sur chaque route. Pour construire la valeur de la politique elle-même,
voyez [comment construire une CSP solide](/fr/blog/how-to-build-a-strong-csp).

## nginx [#nginx]

```nginx title="nginx.conf"
add_header Content-Security-Policy "default-src 'self'" always;
```

Placez ceci dans le bloc `server` ou `location`, avec la
[directive `add_header`](https://nginx.org/en/docs/http/ngx_http_headers_module.html).
Le flag `always` a son importance : sans lui, nginx omet le header sur les réponses
d'erreur (4xx et 5xx), qui sont justement les pages qu'un attaquant pourrait
atteindre.

## Apache [#apache]

```apache title=".htaccess"
Header always set Content-Security-Policy "default-src 'self'"
```

Ceci se place dans le virtual host ou dans un fichier `.htaccess`, et demande que
[`mod_headers`](https://httpd.apache.org/docs/current/mod/mod_headers.html) soit activé.
Comme avec nginx, `always` étend le header aux réponses d'erreur.

## Express (Node.js) [#express-nodejs]

```javascript
app.use((req, res, next) => {
  res.setHeader("Content-Security-Policy", "default-src 'self'");
  next();
});
```

Enregistré comme premier middleware, ce code applique le header à chaque réponse
[Express](https://expressjs.com/). La plupart des applications réelles utilisent
[Helmet](https://helmetjs.github.io/), qui définit la CSP avec d'autres headers de
sécurité et gère un nonce par requête, si bien que le middleware qui pose le
header injecte aussi le nonce dans le template. Pour le pattern du nonce
lui-même, voyez
[comment mettre en place un nonce par requête](/fr/blog/csp-nonce-setup).

## Django [#django]

```python
# in middleware or a response processor
response["Content-Security-Policy"] = "default-src 'self'"
```

Un [middleware Django](https://docs.djangoproject.com/en/stable/topics/http/middleware/)
personnalisé qui définit le header sur la `response` sortante est l'approche la plus
simple, et le paquet
[`django-csp`](https://django-csp.readthedocs.io/) fait la même chose en y ajoutant
des surcharges par vue et la gestion du nonce ; reportez-vous à sa documentation à
jour pour les noms de settings exacts.

## Next.js [#nextjs]

Définissez le header dans `next.config.js` pour une politique statique, ou dans le
proxy au moment de la requête quand vous avez besoin d'un nonce par requête (le cas
courant une fois que vous retirez `'unsafe-inline'`). Côté requête, ce fichier est
`proxy.ts` et exporte une fonction `proxy` ; il s'appelait `middleware.ts` avant
Next.js 16.
[Next.js documente tout le flux CSP et nonce](https://nextjs.org/docs/app/guides/content-security-policy) ;
le pattern App Router plus nonce dans le proxy comporte assez de rouages
pour avoir aussi son propre article ici : [le nonce CSP dans Next.js](/fr/blog/csp-nonce-nextjs).
Pour faire tourner un tag manager sous cette politique, voyez
[GTM sous une CSP stricte dans Next.js](/fr/blog/gtm-csp-nextjs).

```javascript title="next.config.js"
async headers() {
  return [{ source: "/(.*)", headers: [
    { key: "Content-Security-Policy", value: "default-src 'self'" }
  ]}];
}
```

## Nuxt [#nuxt]

```javascript
// nuxt.config, route rules or a server middleware
routeRules: { "/**": { headers: { "Content-Security-Policy": "default-src 'self'" } } }
```

Les [route rules de Nuxt](https://nuxt.com/docs/guide/concepts/rendering) couvrent au
même endroit les réponses statiques et rendues côté serveur ; vérifiez le nom exact
de la clé de header `routeRules` dans la documentation Nuxt à jour, et pour un nonce
par requête, utilisez plutôt un server middleware.

## Laravel [#laravel]

```php title="app/Http/Middleware/AddCspHeader.php"
$response->headers->set('Content-Security-Policy', "default-src 'self'");
```

Enregistrez le [middleware](https://laravel.com/docs/middleware) dans le kernel HTTP
global pour qu'il s'exécute sur chaque réponse, puis lisez le nonce depuis la requête
dans vos templates [Blade](https://laravel.com/docs/blade).

## Angular [#angular]

[Angular](https://angular.dev/) est un framework côté client, il n'envoie donc pas
lui-même de headers de réponse. La CSP vient de ce qui sert les fichiers compilés :
nginx, un serveur Node, ou votre hébergeur statique. Définissez-la là, avec le bloc
adapté ci-dessus. Le runtime d'Angular injecte aussi des styles : d'après son
[guide de sécurité](https://angular.dev/best-practices/security), une politique
stricte a donc besoin d'une stratégie `style-src` (un nonce ou des hash) plutôt que
de `'unsafe-inline'`.

## Confirmez que le header part vraiment [#confirmez-que-le-header-part-vraiment]

Un piège courant consiste à définir la politique dans une balise `<meta>` en
supposant qu'elle est équivalente. Elle ne l'est pas : une politique en balise meta ne
peut pas utiliser `frame-ancestors`, `sandbox` ou le reporting, et elle ne s'applique
qu'au contenu analysé après la balise. Vérifiez le véritable header de réponse avec le
[scanner de headers de sécurité](/tools/security-headers), et lisez les
compromis dans [balise meta CSP vs header](/fr/blog/csp-meta-tags-vs-headers).

Un scan prouve que le header part sur l'URL scannée. Les frameworks en font une question
par route : un middleware qui rate une route, un export statique servi directement depuis
un CDN, une page d'erreur rendue hors de la stack. Ajouter un endpoint de reporting comble
cette lacune : CentralCSP note quelles pages ont produit des violations et lesquelles
n'ont rien produit du tout, et une page qui ne signale jamais rien est en
général une page que le header n'a jamais atteinte.

## Prochaines étapes [#prochaines-étapes]

* Construisez la politique avec [comment construire une CSP solide](/fr/blog/how-to-build-a-strong-csp).
* Abandonnez les allowlists d'hôtes avec [strict-dynamic expliqué](/fr/blog/strict-dynamic-csp).
* Scannez votre politique en production avec le [scanner CSP](/tools/csp-scanner).

[Surveillez votre CSP sur chaque page](/register).

## Sources [#sources]

* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
* [MDN, Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy)
* [MDN, Content Security Policy guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)