En-tête HTTP Content-Security-Policy : définition et rôle

La Content-Security-Policy, ou CSP, est un mécanisme de sécurité appliqué par les navigateurs. Envoyée principalement dans l’en-tête HTTP Content-Security-Policy, elle définit quelles ressources une page peut charger ou exécuter. Son rôle est surtout de réduire l’impact d’une injection de code, sans remplacer la correction des vulnérabilités. Une politique bien conçue limite les scripts, styles, images, polices et connexions aux seules sources nécessaires au fonctionnement du site.

Rôle et menaces couvertes

Réduire les risques de cross-site scripting et d’injection de contenu

Le cross-site scripting (XSS) survient lorsqu’un attaquant parvient à injecter du JavaScript dans une page consultée par d’autres utilisateurs. Ce code s’exécute alors dans le contexte du site légitime : il peut lire des données accessibles à la page, modifier son interface ou déclencher des actions au nom de la victime. Une CSP n’empêche pas, à elle seule, l’injection d’un champ HTML mal filtré. En revanche, elle peut empêcher le navigateur d’exécuter un script inline injecté ou de charger un fichier JavaScript depuis un domaine non autorisé. Elle transforme ainsi une vulnérabilité XSS en incident potentiellement moins exploitable. La protection couvre aussi certaines injections de styles, de contenus intégrés ou de ressources tierces. Elle complète les protections de transport : une politique CSP est plus fiable lorsque le site est distribué en HTTPS, dont le rôle est détaillé dans ce guide sur le protocole TLS lors d’une connexion HTTPS.

Comprendre le fonctionnement des directives et des sources autorisées

Une CSP est une suite de directives, chacune associée à un type de ressource ou à un comportement. Chaque directive contient des expressions de source : une origine complète, un schéma tel que https:, ou des mots-clés comme 'self' et 'none'. Le premier désigne la même origine que le document ; le second interdit toute source. Par exemple, script-src 'self' https://cdn.exemple.net autorise les scripts du site et de ce CDN, mais pas ceux d’autres domaines. La politique est généralement envoyée dans la réponse HTTP. Une balise meta http-equiv peut aussi porter une CSP, mais elle est moins complète, notamment pour certaines directives et le signalement des violations. L’en-tête HTTP reste donc le mode de déploiement de référence.

Les directives à connaître en priorité

default-src, script-src et style-src pour contrôler les ressources actives

default-src sert de règle de repli lorsqu’aucune directive plus précise n’existe. Une base fréquente est default-src 'self', puis des exceptions ciblées. script-src encadre le chargement et l’exécution de JavaScript ; style-src fait de même pour les feuilles CSS, les balises style et, selon la politique, les attributs style.

Directive	Ressource ou comportement contrôlé	Point de vigilance
default-src	Source de repli	Ne remplace pas les directives explicitement définies
script-src	Scripts externes et inline	Éviter 'unsafe-inline' et 'unsafe-eval'
style-src	CSS externe et intégré	Les styles inline peuvent nécessiter une adaptation
connect-src	Requêtes réseau du navigateur	Inclure les API et WebSocket réellement utilisés

img-src, font-src, connect-src et frame-src pour les autres chargements

img-src limite les origines d’images, y compris les images chargées via CSS. font-src encadre les polices web. connect-src contrôle les communications initiées par fetch, XMLHttpRequest, EventSource et WebSocket : une API externe non listée sera bloquée. frame-src concerne les documents que la page peut intégrer dans une iframe. Ces distinctions évitent de donner à un prestataire d’images ou de polices un droit inutile de fournir du JavaScript. Elles sont également indépendantes de CORS : le mécanisme CORS dans les navigateurs régit l’accès d’un script aux réponses inter-origines, tandis que CSP détermine notamment si la requête peut être initiée.

object-src, base-uri et frame-ancestors pour renforcer la protection

object-src contrôle les éléments object, embed et applet, hérités de technologies anciennes. Dans la plupart des applications modernes, object-src 'none' est un choix pertinent. base-uri restreint la valeur de l’élément base, qui peut modifier la résolution des URL relatives et faciliter certains détournements. frame-ancestors indique quels sites peuvent intégrer la page dans une iframe. Cette directive aide à limiter le clickjacking et remplace avantageusement les contrôles historiques lorsqu’une granularité par origine est nécessaire. Elle est distincte de frame-src : l’une contrôle qui peut encadrer votre page, l’autre ce que votre page peut encadrer.

Construire une politique adaptée au site

Partir d’une politique restrictive et autoriser les domaines nécessaires

La méthode la plus sûre consiste à commencer par une politique restrictive, puis à ajouter uniquement les origines indispensables. Il faut inventorier les ressources internes, CDN, outils de mesure, lecteurs vidéo, services de paiement et API. Les autorisations doivent être précises : une origine complète est préférable à un joker comme https: ou *.exemple.com lorsqu’il n’est pas requis. Une base peut ressembler à : default-src 'self'; object-src 'none'; base-uri 'self'. Elle doit ensuite être ajustée selon l’architecture réelle. Vérifiez notamment :

• les domaines qui fournissent scripts, styles, polices et images ;
• les API, WebSocket et services tiers utilisés côté navigateur ;
• les pages devant être intégrées, ou autorisées à intégrer d’autres pages ;
• les ressources servies depuis des sous-domaines distincts.

Gérer les scripts inline avec nonce, hash et strict-dynamic

Les scripts inline sont souvent incompatibles avec une politique stricte. Ajouter 'unsafe-inline' les autorise globalement et réduit fortement l’intérêt de CSP contre le XSS. Une meilleure approche consiste à utiliser un nonce aléatoire, créé pour chaque réponse, placé à la fois dans script-src et sur la balise script autorisée. Un hash cryptographique permet d’autoriser un bloc inline dont le contenu correspond exactement à l’empreinte déclarée. Pour les applications dynamiques, 'strict-dynamic', introduit par CSP Level 3, permet à un script de confiance validé par nonce ou hash de charger d’autres scripts. Son adoption doit être testée selon les navigateurs ciblés et les dépendances du site.

Déployer et tester sans interrompre le service

Utiliser Content-Security-Policy-Report-Only avant le blocage

Content-Security-Policy-Report-Only applique la politique en observation : le navigateur ne bloque pas les ressources, mais signale les violations. C’est la voie la plus prudente pour découvrir les scripts, appels API ou styles oubliés avant d’activer le blocage effectif. Les rapports sont adressés à un endpoint déclaré avec report-to ou, pour des configurations héritées, report-uri. Le mode Report-Only ne protège pas les utilisateurs tant que la politique n’est pas activée. Il sert à stabiliser la configuration, non à la remplacer.

Analyser les rapports de violation et corriger les incompatibilités

Un rapport indique généralement la directive enfreinte, la ressource bloquée et le document concerné. Il faut distinguer une dépendance légitime d’un chargement inattendu : ajouter automatiquement toutes les URL rapportées conduit à une politique permissive. Après correction, testez les parcours critiques : connexion, paiement, formulaires, navigation, chargement asynchrone et intégrations tierces. La mise en cache peut aussi compliquer les essais ; le fonctionnement du code HTTP 304 Not Modified aide à comprendre pourquoi un navigateur peut conserver certaines réponses lors des vérifications.

Erreurs fréquentes et limites du dispositif

Éviter unsafe-inline, unsafe-eval et les listes de sources trop larges

'unsafe-inline' autorise les scripts ou styles intégrés sans nonce ni hash. 'unsafe-eval' permet des mécanismes tels que eval(), qui transforment une chaîne en code JavaScript. Ces exceptions peuvent être imposées par des bibliothèques anciennes, mais doivent rester temporaires et documentées. Les erreurs les plus courantes sont les jokers trop larges, l’autorisation de schémas entiers sans nécessité et le mélange de nombreux services tiers dans script-src. Chaque source JavaScript ajoutée élargit la surface de confiance.

Associer la CSP aux autres mesures de sécurité web

La CSP relève de la défense en profondeur. Elle ne corrige ni validation d’entrée insuffisante, ni encodage HTML incorrect, ni faille serveur. Les données affichées doivent toujours être échappées selon leur contexte, et les dépendances doivent être maintenues. Elle complète aussi d’autres en-têtes. Par exemple, l’en-tête HTTP HSTS force l’usage d’HTTPS après son enregistrement par le navigateur. Ensemble, ces mécanismes réduisent des risques différents : transport non sécurisé, injection de contenu et chargement de ressources non maîtrisées.

Le bon équilibre entre protection et compatibilité

Une politique de sécurité efficace ne consiste pas à empiler des autorisations, mais à limiter chaque ressource au strict nécessaire. Son intérêt majeur est de réduire les possibilités d’exploitation lorsqu’une injection de contenu survient, tout en rendant visibles les dépendances réelles d’une application. La restriction des scripts mérite une attention prioritaire, car elle conditionne largement la résistance au XSS. Une mise en place progressive, d’abord en mode de rapport, évite les régressions fonctionnelles et facilite les ajustements. L’objectif est de conserver une configuration lisible, précise et maintenue dans le temps. Commencez par une base restrictive, examinez les violations légitimes, puis activez le blocage une fois la politique validée : la précision vaut mieux qu’une liste d’exceptions étendue.

Questions fréquentes

Une CSP peut-elle casser le fonctionnement d’un site ?

Oui, une politique trop restrictive peut bloquer un script, une police, une image ou un appel API nécessaire. Le risque est particulièrement élevé sur les sites utilisant plusieurs services externes. Le mode Content-Security-Policy-Report-Only permet d’identifier ces blocages potentiels sans interrompre le fonctionnement avant l’activation de la politique définitive.

Quelle différence entre CSP et CORS ?

La CSP définit quelles ressources une page est autorisée à charger ou à exécuter. CORS détermine si un script déjà exécuté peut lire une réponse provenant d’une autre origine. Une requête peut donc être autorisée par la CSP, mais sa réponse rester inaccessible au JavaScript si le serveur distant ne fournit pas les en-têtes CORS appropriés.

Faut-il supprimer tous les scripts inline ?

Non, mais ils doivent être contrôlés. Un script inline peut rester autorisé avec un nonce unique généré côté serveur ou avec un hash correspondant exactement à son contenu. Cette approche préserve certaines contraintes techniques sans ouvrir l’exécution à tout code injecté. L’autorisation globale unsafe-inline doit être évitée autant que possible.

La CSP protège-t-elle contre toutes les attaques XSS ?

Non. Elle limite surtout les possibilités d’exécution ou de chargement de code malveillant dans le navigateur. Une faille XSS peut néanmoins conserver des effets selon la politique, les navigateurs et le contexte applicatif. La protection principale reste la prévention : validation des données, encodage adapté à chaque contexte HTML ou JavaScript, et correction rapide des vulnérabilités.

À quel niveau configurer l’en-tête Content-Security-Policy ?

Il peut être défini par le serveur web, le framework applicatif, un proxy inverse ou une plateforme d’hébergement capable de modifier les réponses HTTP. L’essentiel est que l’en-tête soit envoyé avec les documents HTML concernés. Une politique peut aussi varier selon les pages si leurs dépendances diffèrent réellement.