Définir le header Content-Security-Policy dans chaque 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.

nginx

nginx.conf

add_header Content-Security-Policy "default-src 'self'" always;

Placez ceci dans le bloc server ou location, avec la directive add_header. 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

.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 soit activé. Comme avec nginx, always étend le header aux réponses d'erreur.

Express (Node.js)

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. La plupart des applications réelles utilisent Helmet, 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.

Django

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

Un middleware Django personnalisé qui définit le header sur la response sortante est l'approche la plus simple, et le paquet django-csp 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

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 ; 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. Pour faire tourner un tag manager sous cette politique, voyez GTM sous une CSP stricte dans Next.js.

next.config.js

async headers() {
  return [{ source: "/(.*)", headers: [
    { key: "Content-Security-Policy", value: "default-src 'self'" }
  ]}];
}

Nuxt

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

Les route rules de Nuxt 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

app/Http/Middleware/AddCspHeader.php

$response->headers->set('Content-Security-Policy', "default-src 'self'");

Enregistrez le 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.

Angular

Angular 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é, 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

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é, et lisez les compromis dans balise meta CSP vs header.

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

Construisez la politique avec comment construire une CSP solide.
Abandonnez les allowlists d'hôtes avec strict-dynamic expliqué.
Scannez votre politique en production avec le scanner CSP.

Surveillez votre CSP sur chaque page.

Comment définir le header Content-Security-Policy dans chaque framework