# 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 rassemble la manière la plus courte d'envoyer ce
header dans les stacks que l'on nous demande le plus souvent, afin que vous puissiez
trouver la vôtre, la coller, puis passer au réglage de la politique elle-même.

Deux règles s'appliquent à chacun des 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, au
niveau du reverse proxy ou du 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 nécessite
[`mod_headers`](https://httpd.apache.org/docs/current/mod/mod_headers.html) activé.
Comme avec nginx, `always` garantit que le header est défini aussi sur les 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, ceci 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 et d'autres headers de
sécurité et prend en charge un nonce par requête, de sorte que le même middleware qui
définit 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/) l'enveloppe avec des surcharges par
vue et la prise en charge du nonce ; vérifiez ses docs actuelles 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'`). Ce fichier au moment de la
requête est `proxy.ts` avec une fonction `proxy` exportée, renommé depuis
`middleware.ts` dans Next.js 16 et les versions ultérieures.
[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 pièces mobiles
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 ; confirmez la clé de
header `routeRules` exacte par rapport aux docs Nuxt actuelles, 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, donc selon son
[guide de sécurité](https://angular.dev/best-practices/security), une politique
stricte a 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
ce trou, parce que CentralCSP enregistre lesquelles de vos 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)