Glossaire
CSP (Content Security Policy)
En-tête HTTP de sécurité qui définit les sources autorisées pour le chargement de scripts, styles, images et autres ressources dans une page web. La CSP est la défense principale contre les attaques XSS car elle empêche l'exécution de scripts non approuvés. Une CSP mal configurée (unsafe-inline, wildcards) offre peu de protection réelle.
Ce qu'une CSP protège vraiment
La Content Security Policy est un en-tête HTTP qui indique au navigateur quelles sources de contenu sont autorisées : scripts, styles, images, iframes, connexions sortantes. Son rôle principal est de limiter l'impact des XSS : même si un attaquant parvient à injecter du HTML, une CSP stricte empêche l'exécution de scripts non autorisés et l'exfiltration vers des domaines tiers. C'est une défense en profondeur — elle ne remplace pas la correction des XSS, elle en réduit les conséquences.
Les erreurs courantes
Dans nos audits de SaaS, les CSP réellement protectrices sont rares. Les schémas récurrents : absence totale d'en-tête, politiques avec 'unsafe-inline' et 'unsafe-eval' qui annulent l'essentiel de la protection, wildcards trop larges (https: ou *.cloudfront.net), et politiques en mode Report-Only jamais passées en mode bloquant. Une CSP stricte moderne repose sur des nonces ou des hashes ('strict-dynamic'), ce qui demande une intégration dans le framework — Next.js, par exemple, le permet via son middleware.
Notre approche en audit
Nous évaluons la CSP en conditions réelles : politique effectivement servie sur chaque page, directives réellement appliquées, possibilités de contournement (JSONP, bibliothèques whitelistées détournables, injections DOM). Le rapport indique si votre CSP bloquerait une XSS réelle et propose une politique cible adaptée à votre stack, déployable progressivement via Report-Only.
Questions fréquentes
Une CSP empêche-t-elle toutes les XSS ?
Non. Une CSP stricte bloque l'exécution de scripts injectés et limite l'exfiltration, mais des contournements existent (gadgets dans les bibliothèques autorisées, injections dans des contextes non couverts). Elle réduit fortement l'impact d'une XSS mais ne dispense jamais de corriger la faille d'injection elle-même.
Pourquoi 'unsafe-inline' est-il un problème ?
Parce que la majorité des attaques XSS injectent précisément du script inline. Autoriser 'unsafe-inline' revient à désactiver la protection principale de la CSP. La solution moderne : nonces générés par requête ou hashes de scripts, avec 'strict-dynamic' pour les chaînes de chargement.
Comment déployer une CSP sans casser son application ?
Commencez en mode Content-Security-Policy-Report-Only avec un endpoint de collecte des violations. Analysez les rapports, ajustez la politique jusqu'à zéro faux positif, puis passez en mode bloquant. Sur un SaaS en production, ce cycle prend typiquement quelques semaines et évite toute interruption.