← Retour au générateur CSP AdminTools.fr — Guide sécurité

Comprendre la Content-Security-Policy (CSP)

La CSP est l'une des défenses les plus efficaces contre les attaques XSS, mais aussi l'une des plus mal comprises — une politique trop stricte casse le site, une politique trop permissive ne protège rien. Ce guide explique comment trouver le bon équilibre.

Le principe de la CSP

La Content-Security-Policy fonctionne sur le principe d'une liste blanche : plutôt que d'essayer de bloquer les contenus malveillants connus (liste noire, toujours incomplète), elle définit précisément quelles sources sont autorisées à fournir chaque type de ressource (scripts, styles, images, polices...). Tout ce qui n'est pas explicitement autorisé est bloqué par le navigateur, qu'il s'agisse d'un script légitime oublié ou d'un script injecté par un attaquant.

Les directives essentielles

Directive	Rôle
default-src	Valeur de repli pour toute ressource sans directive spécifique.
script-src	La plus critique en sécurité — contrôle quels scripts peuvent s'exécuter.
frame-ancestors	Protection anti-clickjacking, remplace X-Frame-Options.
object-src 'none'	Recommandé presque systématiquement — les plugins (Flash et consorts) sont obsolètes et risqués.
base-uri 'self'	Empêche une injection de modifier la balise <base> pour rediriger les chemins relatifs.

Pourquoi éviter unsafe-inline et unsafe-eval

unsafe-inline autorise l'exécution de scripts écrits directement dans l'attribut onclick ou entre des balises <script> sans source externe — exactement la technique la plus utilisée par les attaques XSS. L'activer revient à neutraliser une grande partie de la protection de la directive script-src.

unsafe-eval autorise l'utilisation de eval() et fonctions similaires qui exécutent du texte comme du code — un vecteur d'attaque tout aussi dangereux si une entrée utilisateur atteint un jour ce code, même indirectement.

Si une application existante dépend fortement de scripts inline, la migration vers une CSP stricte demande un travail de refactoring (déplacer le JavaScript inline vers des fichiers externes) — un coût ponctuel pour un gain de sécurité durable.

Tester sans risque avec Report-Only

L'en-tête Content-Security-Policy-Report-Only applique exactement la même syntaxe que la CSP normale, mais ne bloque rien : il se contente de journaliser (ou d'envoyer à une URL de rapport via report-uri) ce qui aurait été bloqué. C'est la méthode recommandée pour déployer une nouvelle CSP sur un site existant sans risquer de casser une fonctionnalité en production.

Une alternative : les nonces et hash

Pour les sites qui ont réellement besoin de scripts inline (générés dynamiquement côté serveur), la CSP propose deux alternatives plus sûres qu'unsafe-inline :

• Nonce : une valeur aléatoire générée à chaque chargement de page côté serveur, ajoutée à la fois dans l'en-tête CSP et dans l'attribut nonce du script autorisé. Un script injecté par un attaquant ne connaîtra jamais le nonce courant.
• Hash : le hash SHA du contenu exact du script est ajouté à la CSP — seul ce contenu précis sera exécuté, toute modification (légitime ou non) invalide le hash.

Utiliser le générateur CSP →

Erreurs courantes

• Déployer une CSP stricte directement en production sans phase de test en Report-Only, cassant des fonctionnalités du site sans avertissement préalable.
• Mélanger 'none' avec d'autres sources dans la même directive — la spécification CSP traite 'none' seul, toute autre source listée avec lui est ignorée par certains navigateurs.
• Oublier de mettre à jour la CSP après l'ajout d'un nouveau service externe (widget, analytics, CDN), bloquant silencieusement la nouvelle ressource.
• Définir une CSP uniquement via balise meta HTML alors qu'un en-tête HTTP est disponible — l'en-tête HTTP est appliqué plus tôt et couvre des cas que la balise meta ne couvre pas (comme certains rapports de violation).

Questions fréquentes

La CSP remplace-t-elle la validation et l'échappement des entrées utilisateur ?

Non — la CSP est une protection en profondeur supplémentaire, pas un substitut. Échapper correctement les sorties HTML et valider les entrées reste la défense de première ligne contre les failles d'injection.

Peut-on avoir plusieurs en-têtes CSP sur la même page ?

Techniquement oui, mais les navigateurs appliquent alors l'intersection la plus restrictive de toutes les politiques — généralement source de confusion plutôt que de bénéfice ; une seule politique bien pensée est préférable.

La balise meta CSP a-t-elle les mêmes capacités que l'en-tête HTTP ?

Presque, mais pas totalement — certaines directives comme frame-ancestors ou report-uri ne fonctionnent pas (ou pas correctement) via la balise meta et nécessitent l'en-tête HTTP.

Comment savoir si ma CSP bloque quelque chose par erreur ?

La console JavaScript du navigateur affiche un message explicite "Refused to load/execute..." pour chaque violation, indiquant la ressource et la directive concernée — le point de départ pour ajuster la politique.