Politique de sécurité du contenu (CSP).

La CSP est délivrée via l'en-tête de réponse Content-Security-Policy (ou un élément meta) et applique une liste d'autorisation fine par type de ressource : script-src, style-src, img-src, connect-src, frame-ancestors, etc. Elle est normalisée par le W3C, CSP Level 3 ayant introduit les primitives qui rendent les politiques strictes réellement exploitables. En tant que mesure de défense en profondeur, elle réduit fortement l'impact des XSS, du clickjacking (via frame-ancestors) et du contenu mixte, sans pour autant remplacer la validation des entrées ni l'encodage des sorties.

Les listes blanches d'hôtes constituent l'erreur classique. Les recherches de Google (l'article CSP Is Dead, Long Live CSP!, portant sur environ un milliard de pages) ont montré que la grande majorité des politiques fondées sur les hôtes étaient trivialement contournables, généralement parce qu'un CDN autorisé servait aussi des endpoints JSONP ou une version obsolète d'Angular/AngularJS exploitable comme gadget. La réponse moderne est une CSP stricte fondée sur les nonces : chaque réponse émet un nouveau nonce aléatoire (script-src 'nonce-r4nd0m'), les scripts en ligne portent ce nonce, et un <script> injecté qui ne le possède pas ne s'exécute tout simplement pas. Associer le nonce à 'strict-dynamic' permet aux scripts de confiance de charger leurs propres dépendances tout en ignorant entièrement les listes d'hôtes, ce qui garde la politique courte et indépendante du CDN. Ajoutez toujours object-src 'none' et base-uri 'none' pour fermer les contournements via les balises <object> et <base>.

Déployez-la en toute sécurité avec Content-Security-Policy-Report-Only, qui n'impose rien mais envoie des rapports de violation au format JSON via report-to/report-uri, ce qui permet d'ajuster la politique face au trafic réel avant de passer en mode application. GitHub, Google et Dropbox exécutent tous des CSP strictes fondées sur les nonces en production. N'oubliez pas que l'en-tête est appliqué côté client par le navigateur : il atténue les injections côté serveur plutôt qu'il ne les empêche.

flowchart TD
  A[Le serveur génère la réponse] --> B[Nouveau nonce aléatoire par requête]
  B --> C["Header: script-src 'nonce-abc123' 'strict-dynamic'; object-src 'none'; base-uri 'none'"]
  C --> D[Le navigateur analyse la page]
  D --> E{Le script a-t-il un nonce correspondant ?}
  E -->|Oui : script en ligne légitime| F[Exécution + strict-dynamic charge ses dépendances]
  E -->|Non : balise de script injectée par XSS| G[Bloqué]
  G --> H[Rapport de violation vers l'endpoint report-to]
  style F fill:#27ae60,color:#fff
  style G fill:#c0392b,color:#fff