Une Content Security Policy indique au navigateur quelles sources de contenu sont autorisées. Elle est particulièrement utile pour limiter l’impact de certaines injections de scripts et empêcher des chargements depuis des origines inattendues.
Une CSP est une liste d’autorisations
Des directives comme default-src, script-src, style-src, img-src, connect-src ou frame-ancestors couvrent des familles de ressources différentes. Une politique efficace doit refléter les besoins réels du site plutôt qu’accumuler des domaines « au cas où ».
Le générateur CSP permet de composer une base lisible. Utilisez-la comme point de départ à tester, pas comme une garantie automatique de sécurité.
Commencer progressivement
Déployer immédiatement une politique très stricte sur un site existant peut casser analytics, widgets, polices, images ou appels API. Il est souvent plus sûr d’inventorier les ressources, de construire une politique minimale, de tester les pages critiques puis de resserrer progressivement les règles.
Évitez surtout de rendre la CSP artificiellement permissive avec des jokers très larges. Chaque exception doit correspondre à un besoin compris.
Nonces, hashes et scripts inline
Les scripts inline sont un point délicat. Les nonces ou hashes permettent d’autoriser explicitement certains contenus sans ouvrir globalement unsafe-inline. Le choix dépend de l’architecture et de la manière dont les pages sont générées.
frame-ancestors et l’intégration dans des cadres
La directive frame-ancestors contrôle quels sites peuvent intégrer la page dans une iframe. Elle participe à la protection contre certaines formes de clickjacking et complète les autres en-têtes de sécurité.
CSP ne veut pas dire « XSS impossible »
Une CSP est une défense en profondeur. Elle ne remplace ni l’encodage des sorties, ni la validation, ni la correction des vulnérabilités applicatives. Une politique faible ou mal adaptée peut également donner une fausse impression de protection.
Après déploiement, vérifiez les erreurs dans le navigateur et contrôlez chaque modification importante du site. Pour les ressources tierces statiques, le guide Subresource Integrity complète cette approche.
Comprendre la logique de repli des directives
default-src sert de règle de repli pour plusieurs catégories lorsqu’une directive plus précise n’est pas définie. Dès que vous ajoutez par exemple script-src, ce sont ses règles qui s’appliquent aux scripts. Cette hiérarchie permet de commencer avec une base restrictive puis d’ouvrir seulement ce qui est nécessaire.
Une politique typique distingue au minimum scripts, styles, images, connexions réseau et cadres. Selon le site, font-src, media-src, worker-src, object-src, base-uri ou form-action peuvent également être importants. L’objectif n’est pas d’utiliser toutes les directives : c’est de décrire précisément le comportement attendu.
unsafe-inline et unsafe-eval méritent une vraie décision
Ces valeurs sont souvent ajoutées pour faire disparaître rapidement des erreurs, mais elles réduisent fortement l’intérêt d’une politique sur les scripts. Si une application dépend de scripts inline, préférez lorsque l’architecture le permet des nonces générés par réponse ou des hashes correspondant à des blocs connus.
unsafe-eval autorise certaines formes d’évaluation dynamique de code et doit également être évité sauf nécessité comprise. Lorsqu’une bibliothèque l’exige, demandez-vous si une version ou une configuration différente permet de supprimer cette exception.
Utiliser Report-Only avant de bloquer
Content-Security-Policy-Report-Only permet d’observer les violations sans bloquer immédiatement les ressources. C’est particulièrement utile sur un site existant : naviguez sur les pages importantes, déclenchez les fonctionnalités, identifiez les origines légitimes puis corrigez la politique.
Attention toutefois : Report-Only est une phase de mise au point, pas une protection finale. Une fois la politique stabilisée, elle doit être réellement appliquée avec l’en-tête Content-Security-Policy.
Exemple de progression
Vous pouvez commencer par inventorier les ressources chargées, définir default-src 'self', puis ajouter explicitement les domaines indispensables pour les images, API ou services tiers. Les scripts doivent faire l’objet d’une attention particulière. Ajoutez ensuite object-src 'none', une règle base-uri adaptée et frame-ancestors selon les besoins d’intégration.
Le générateur CSP facilite l’écriture de la syntaxe, mais la bonne politique dépend toujours de votre application. Copiez moins, observez davantage.
CSP, contenus tiers et évolution du site
Une CSP n’est jamais totalement « terminée ». Ajouter un service analytics, un lecteur vidéo, une police distante ou une nouvelle API peut nécessiter une évolution. Traitez chaque modification comme une extension explicite du modèle de confiance, pas comme une raison d’ajouter * partout.
Lorsque vous autorisez une ressource statique externe précise, SRI peut ajouter une vérification complémentaire sur son contenu. CSP décide d’où une ressource peut venir ; SRI peut vérifier quelle version exacte a été reçue.
