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

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 nécessite mod_headers activé. Comme avec nginx, always garantit que le header est défini aussi sur les 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, ceci applique le header à chaque réponse Express. La plupart des applications réelles utilisent Helmet, 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.

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 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

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 ; 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. 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 ; 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

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, donc selon son guide de sécurité, 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

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 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

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