Temps de lecture estimé : 11 minutes
Points clés à retenir
- Un CSP trop permissif (avec * ou unsafe-inline) n’apporte aucune protection réelle.
- Commencer par le mode report-only avant d’activer le blocage.
- Auditer toutes les ressources tierces chargées, y compris leurs sous-ressources.
- Tester 100% des parcours critiques avant durcissement (connexion, paiement).
- Un CSP doit être maintenu à chaque nouvelle dépendance ou prestataire.
Comprendre le CSP et son rôle
Les pièges du CSP commencent souvent avant même la première ligne de configuration. Beaucoup d’équipes abordent le Content Security Policy comme une formalité à cocher, sans mesurer ce qu’il implique côté déploiement.
Le Content Security Policy est un en-tête HTTP (ou une balise meta équivalente) qui indique au navigateur quelles sources de contenu sont autorisées à s’exécuter sur une page. Défini par le W3C, il fonctionne comme une liste blanche : tout ce qui n’y figure pas est bloqué.
Ce que le CSP protège réellement
Son rôle principal est de limiter l’impact des attaques XSS (Cross-Site Scripting). Si un attaquant parvient à injecter du code dans une page, le CSP peut empêcher ce code de se charger ou de communiquer avec l’extérieur.
Le CSP protège aussi contre le clickjacking, le chargement de ressources non autorisées et les fuites de données vers des domaines tiers. Sur les applications modernes. Avec authentification, paiement, données personnelles — c’est un filet de sécurité qui compte.
Pourquoi il devient difficile à ignorer
Les navigateurs modernes le supportent nativement. Les audits de sécurité le signalent systématiquement quand il est absent. Et les réglementations (RGPD, PCI-DSS pour les sites e-commerce) commencent à l’intégrer dans leurs exigences techniques. Regardons cela de plus près : un site sans CSP expose chaque visiteur à des risques que la politique de cookies seule ne couvre pas.
Les erreurs de base les plus fréquentes
La plupart des erreurs CSP ne viennent pas d’un manque de connaissances techniques. Elles viennent d’une mise en place précipitée, souvent faite sous pression, sans inventaire préalable.
Des sources trop larges dès le départ
La directive default-src * autorise tout. C’est la configuration la plus courante chez les équipes qui veulent « activer le CSP » sans casser le site. Elle coche la case, mais n’apporte aucune protection réelle. Une politique aussi permissive laisse passer exactement le type de ressources qu’un attaquant exploiterait.
Dans mon expérience, cette erreur arrive surtout quand le CSP est ajouté en fin de projet, sans avoir anticipé les dépendances réelles du site.
Pas de plan de migration progressif
Activer un CSP strict directement en production sans phase d’observation, c’est jouer à la roulette. Le mode report-only, défini par MDN comme l’un des 2 modes principaux du standard, permet d’envoyer les violations à un endpoint de rapport sans rien bloquer. C’est le filet qui évite la casse.
Sauter cette étape, c’est découvrir les problèmes via les retours des utilisateurs plutôt que via les logs. Ce n’est pas la même chose.
Des ressources oubliées en cours de route
Un site charge rarement uniquement ses propres ressources. Fonts Google, scripts analytics, widgets de chat, iframes marketing : chaque service tiers doit figurer dans la politique. Une seule ressource oubliée suffit à bloquer un composant entier, parfois invisible jusqu’à ce qu’un utilisateur signale que le formulaire de contact ne répond plus.
Les pièges de configuration avancés
Quand on dépasse la configuration minimale, les risques changent de nature. Ce ne sont plus des oublis, mais des compromis qui semblent raisonnables et qui ne le sont pas.
unsafe-inline : la facilité qui coûte cher
Autoriser unsafe-inline dans script-src ou style-src revient à ouvrir une brèche dans la logique même du CSP. L’OWASP le place parmi les 2 mots-clés à éviter absolument dans une politique stricte, avec unsafe-eval.
Le problème : beaucoup de frameworks, de CMS et d’outils tiers injectent des scripts inline. Désactiver unsafe-inline casse souvent des fonctionnalités que personne n’avait documentées. La solution passe par les nonces ou les hashes. Plus complexes à gérer, mais sans failles.
unsafe-eval et les frameworks JavaScript
unsafe-eval pose un autre type de problème. Certains bundlers, certains moteurs de templates et des bibliothèques comme AngularJS l’utilisent en interne. Le retirer peut paralyser des parties entières d’une application sans message d’erreur immédiatement lisible.
Pour aller plus loin, les alternatives existent : les Trusted Types, introduits par Google, permettent de contrôler dynamiquement les appels à eval sans tout interdire. Mais ça demande un travail d’adaptation du code existant.
Scripts tiers et CDN : la zone grise
Les 3 familles de ressources tierces qui posent le plus de problèmes en pratique sont les outils analytics (Google Analytics, Matomo), les widgets marketing (chatbots, pop-ups, A/B testing) et les lecteurs médias (YouTube, Vimeo, Spotify). Chacun peut charger des sous-ressources depuis ses propres domaines, qui eux-mêmes chargent d’autres ressources.
Autoriser cdn.example.com ne suffit pas si ce CDN sert des scripts qui appellent api.example.com. Il faut tracer toute la chaîne.
Les faux sentiments de sécurité
Avoir un CSP ne suffit pas. Une politique mal construite peut donner l’impression d’une sécurité renforcée tout en laissant les vulnérabilités intactes.
Une politique présente mais inefficace
Un en-tête CSP qui contient default-src 'self' * data: blob: 'unsafe-inline' 'unsafe-eval' est techniquement présent. Il passera certains outils d’audit automatiques. Mais il n’apporte rien. La présence d’un CSP ne garantit pas sa rigueur.
L’écart entre report-only et mode bloquant
Le mode report-only est indispensable en phase de test. Mais certaines équipes restent en report-only indéfiniment, par crainte de casser le site. Résultat : les violations sont collectées, personne ne les lit, et le site n’est pas plus protégé qu’avant.
La transition vers le mode bloquant doit être planifiée et suivie. Ce n’est pas une décision de dernière minute.
Les impacts invisibles sur certains parcours
Un CSP peut bloquer le bouton de paiement uniquement dans un contexte précis : navigateur spécifique, extension installée, version mobile. Ces cas passent sous les radars des tests standards. 100% des chemins critiques doivent être testés avant de durcir une politique : navigation, connexion, tunnel de commande, formulaire de contact.
Méthode pour déployer un CSP sans casser le site
Google Web.dev le formule clairement : commencer par observer avant de bloquer. C’est l’unique étape de migration qui fait consensus parmi les pratiques d’intégration CSP. Tout le reste découle de là.
Inventorier les ressources chargées
Avant d’écrire la moindre directive, ouvrir l’onglet réseau du navigateur et lister toutes les ressources chargées sur chaque type de page : accueil, page produit, tunnel de commande, espace connecté. Chaque domaine externe est une entrée potentielle dans la politique.
Des outils comme CSP Evaluator (Google) ou les extensions de développeur permettent d’automatiser une partie de ce travail. Mais rien ne remplace un audit manuel sur les pages à fort trafic.
Tester en mode report-only d’abord
Déployer le CSP en Content-Security-Policy-Report-Only sur 2 environnements: préproduction puis production. Les violations remontent dans les rapports sans rien bloquer. C’est là que les ressources oubliées se révèlent, les scripts tiers inattendus, les iframes de support client qui n’étaient documentés nulle part.
Un rapport d’erreur exploitable contient l’URL de la ressource bloquée, la directive violée et la page concernée. C’est suffisant pour corriger la politique avant de passer en mode bloquant.
Durcir par étapes
Le CSP s’affine progressivement. Commencer par les 4 directives de base recommandées par MDN : default-src, script-src, style-src, img-src. Affiner chaque directive selon les violations constatées. Puis ajouter les directives spécialisées (font-src, connect-src, media-src) une fois le socle stable.
Cas concrets selon le type de site
Les pièges du CSP ne sont pas les mêmes selon l’architecture du site. Démystifions le sujet à travers trois cas représentatifs.
Site vitrine
Un site vitrine classique (HTML statique ou CMS simple, sans espace connecté) est le contexte le plus favorable. Les ressources sont limitées : quelques polices, un script analytics, peut-être un widget de formulaire. Une politique stricte est atteignable en quelques heures d’audit. Le risque principal est d’oublier les polices Google ou les scripts de tags marketing ajoutés directement dans le HTML par l’équipe com.
E-commerce
Un site e-commerce cumule les dépendances : prestataire de paiement (Stripe, PayPal), scripts de recommandation, pixels publicitaires (Meta, Google Ads), outils de personnalisation. Chaque intégration marketing peut modifier dynamiquement le DOM et charger des sous-ressources. La politique CSP doit être revue à chaque nouvelle intégration, pas seulement au lancement.
Application web avec authentification
C’est le contexte le plus exigeant. Les applications SPA (React, Vue, Angular) utilisent souvent des mécanismes qui entrent en conflit direct avec un CSP strict : eval() pour la compilation de templates, scripts inline pour l’hydratation, WebSockets pour les connexions temps réel. La migration vers des nonces ou des hashes est souvent incontournable, et elle prend du temps.
Vérifier, maintenir et faire évoluer le CSP
Un CSP n’est pas une configuration qu’on pose une fois et qu’on oublie. C’est un outil vivant, qui doit suivre l’évolution du site.
Contrôler les rapports d’erreurs
Configurer un endpoint de rapport (report-to ou report-uri) et le surveiller activement. Les violations en production signalent soit une ressource légitime oubliée dans la politique, soit une tentative d’injection réelle. Les deux méritent une réponse.
Adapter la politique aux nouveaux services
Chaque nouveau script tiers, chaque nouveau prestataire de paiement, chaque plugin ajouté au CMS peut nécessiter une mise à jour du CSP. Sans processus formalisé, la politique se dégrade progressivement : des directives trop larges sont ajoutées « pour débloquer », et la protection s’érode.
Auditer régulièrement les dépendances
Un script tiers autorisé aujourd’hui peut changer de comportement demain (mise à jour du prestataire, changement de CDN, ajout d’une sous-ressource). Un audit trimestriel des ressources effectivement chargées, croisé avec la politique en place, permet de détecter les dérives avant qu’elles deviennent des failles.
Questions fréquentes
Qu’est-ce qu’un Content Security Policy ?
Le Content Security Policy est un en-tête HTTP qui liste les sources autorisées à charger du contenu sur une page web. Défini par le W3C, il indique au navigateur ce qu’il peut exécuter ou afficher : scripts, styles, images, polices, iframes. Tout ce qui n’est pas explicitement autorisé est bloqué.
Le CSP peut-il empêcher une attaque XSS ?
Il peut en réduire l’impact, pas l’empêcher totalement. Si un attaquant injecte du code dans une page, un CSP bien configuré peut empêcher ce code de se charger ou de communiquer avec l’extérieur. Mais il ne corrige pas la faille qui a permis l’injection. C’est un filet, pas une solution complète.
Pourquoi mon site casse-t-il après l’activation du CSP ?
Parce que des ressources utilisées par le site ne sont pas listées dans la politique. Un script tiers, une police externe, un iframe de support : une seule ressource absente de la liste blanche suffit à bloquer le composant qui en dépend. La solution est de passer d’abord par le mode report-only pour identifier ce qui manque avant de bloquer quoi que ce soit.
Faut-il utiliser unsafe-inline dans un CSP ?
Dans la mesure du possible, non. unsafe-inline autorise l’exécution de scripts et styles directement dans le HTML, ce qui annule une partie de la protection contre les XSS. L’OWASP le déconseille explicitement. Si des scripts inline sont nécessaires, il vaut mieux utiliser des nonces ou des hashes, qui permettent d’autoriser des blocs précis sans tout ouvrir.
Quelle différence entre report-only et un CSP actif ?
En mode report-only, les violations sont enregistrées et envoyées à un endpoint, mais rien n’est bloqué : le site continue de fonctionner normalement. En mode actif, les ressources non autorisées sont bloquées par le navigateur. Le mode report-only sert à observer et corriger la politique avant de l’activer réellement.
Comment gérer les scripts tiers avec un CSP strict ?
Il faut identifier tous les domaines que ces scripts chargent, y compris leurs sous-ressources, et les ajouter explicitement dans les directives concernées (script-src, connect-src, etc.). Pour les scripts qui changent fréquemment, certaines équipes utilisent un proxy interne pour garder le contrôle. C’est plus complexe, mais ça évite d’ouvrir des plages de domaines entières.
Un CSP suffit-il pour sécuriser un site web ?
Non. Le CSP est une couche de défense parmi d’autres. Il complète les en-têtes de sécurité HTTP (HSTS, X-Frame-Options, Permissions-Policy), la gestion des sessions, la validation des entrées et les mises à jour régulières des dépendances. Seul, il n’est pas suffisant. Mais sans lui, la surface d’attaque est nettement plus large.
Comment savoir si ma politique CSP est trop permissive ?
Passer la politique dans CSP Evaluator (outil Google) est un bon point de départ. Si elle contient *, unsafe-inline, unsafe-eval ou data: sans restriction, elle est probablement trop large. Croiser ensuite avec les ressources chargées sur le site : si la politique autorise dix fois plus de domaines que le site n’en utilise, il y a de la marge pour durcir. Les pièges du CSP se révèlent presque toujours dans cet écart entre ce qui est autorisé et ce qui est nécessaire.
