Content-Security-Policy (CSP) : protéger son site contre le XSS
La Content-Security-Policy (CSP) est une liste blanche que vous transmettez au navigateur : elle énumère précisément les sources de scripts, styles, images, polices et autres ressources qu'il a le droit de charger sur vos pages. Tout ce qui n'est pas explicitement autorisé est bloqué.
C'est, de loin, l'en-tête de sécurité le plus puissant — et le plus délicat à régler. Bien construite, une CSP neutralise la majorité des attaques par injection de script (XSS), même lorsqu'une faille existe dans votre code : c'est une véritable filet de sécurité de dernier recours. Mal construite, elle casse l'affichage de votre site ou, à l'inverse, n'apporte aucune protection réelle. Ce guide vous donne la méthode pour la déployer progressivement et sans risque.
Pourquoi la CSP est cruciale
Le XSS (Cross-Site Scripting) reste l'une des vulnérabilités web les plus répandues : un attaquant parvient à faire exécuter son propre JavaScript dans le navigateur de vos visiteurs, ce qui lui permet de voler des sessions, de défigurer la page ou de monter une page de hameçonnage crédible. La CSP agit comme un dernier rempart : même si un script malveillant est injecté dans votre HTML, le navigateur refuse de l'exécuter s'il ne provient pas d'une source que vous avez autorisée.
Attention au piège qui vide la CSP de son intérêt : une politique contenant 'unsafe-inline' ou 'unsafe-eval' rouvre précisément la porte que la CSP est censée fermer, puisqu'elle autorise l'exécution de scripts arbitraires intégrés à la page. CheckCyber signale ces CSP « affaiblies », car leur présence donne une fausse impression de sécurité.
Comprendre les directives principales
Une CSP se compose de directives, chacune ciblant un type de ressource. default-src est la règle de repli qui s'applique à tout ce que vous ne précisez pas. script-src contrôle les scripts (la directive la plus critique contre le XSS), style-src les feuilles de style, img-src les images, font-src les polices, connect-src les requêtes AJAX/fetch, et frame-ancestors qui peut mettre vos pages en iframe (protection anti-clickjacking).
La valeur 'self' autorise votre propre origine ; vous pouvez aussi lister des domaines précis (par exemple https://www.googletagmanager.com pour un outil d'analyse). Pour autoriser des scripts intégrés légitimes sans ouvrir 'unsafe-inline', utilisez un nonce (jeton unique régénéré à chaque requête) ou un hash du script.
Construire une CSP sans casser le site
Commencez restrictif puis élargissez. Une politique de départ raisonnable n'autorise que vos propres ressources, puis vous ajoutez au cas par cas les domaines tiers réellement utilisés (analytics, polices Google, widget de paiement, régie publicitaire). Adaptez surtout img-src et script-src à vos services concrets.
<IfModule mod_headers.c>
Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data:; style-src 'self'; object-src 'none'; frame-ancestors 'self'; base-uri 'self'"
</IfModule><IfModule mod_headers.c>
Header always set Content-Security-Policy-Report-Only "default-src 'self'"
</IfModule>Tester avant de bloquer
Pour éviter de casser votre site, déployez d'abord la politique en mode « rapport seul » via l'en-tête Content-Security-Policy-Report-Only : le navigateur signale dans sa console toutes les ressources qui seraient bloquées, sans rien empêcher réellement. Naviguez sur l'ensemble de votre site, relevez les violations légitimes (un script utile bloqué à tort), ajustez votre politique en conséquence, puis seulement une fois la liste vide basculez vers l'en-tête bloquant Content-Security-Policy.
Cette approche en deux temps est la clé d'un déploiement CSP réussi : elle vous évite de découvrir en production qu'une fonctionnalité essentielle a cessé de marcher.
[ FAQ // QUESTIONS FRÉQUENTES ]
▸Qu'est-ce que 'unsafe-inline' et pourquoi l'éviter ?
C'est une valeur qui autorise les scripts et styles écrits directement dans le HTML. Pratique, mais elle ouvre grand la porte au XSS, car le navigateur ne peut plus distinguer vos scripts légitimes de ceux injectés par un attaquant. Préférez les nonces ou les hash pour n'autoriser que vos scripts inline réellement légitimes.
▸La CSP suffit-elle à elle seule contre le XSS ?
Non : c'est une défense en profondeur, une dernière ligne. Elle complète — mais ne remplace pas — l'échappement systématique des données affichées et la validation des entrées côté serveur. Une CSP solide réduit fortement l'impact d'une faille, mais l'objectif reste de ne pas en avoir.
▸Ma CSP bloque une ressource légitime, comment la débloquer ?
Ouvrez la console du navigateur : chaque blocage indique la directive et la source concernées. Ajoutez cette source à la directive appropriée (par exemple le domaine d'une police à font-src), puis retestez. Travaillez d'abord en mode Report-Only pour repérer tous les cas avant d'activer le blocage.
[ PASSEZ À L’ACTION ]
Votre site est-il concerné ?
Lancez un audit de surface gratuit et obtenez en quelques secondes la liste exacte de vos failles, avec le correctif pour chacune. Anonyme, sans inscription.
▶ Auditer mon site[ À LIRE AUSSI ]
[ CheckCyber // MIS À JOUR LE 2026-06-29 ]