Chaque fois qu’un navigateur affiche votre site, il exécute du code venu de sources variées : vos propres fichiers, mais aussi des scripts de mesure d’audience, des polices distantes, parfois des encarts publicitaires. Si une personne malveillante réussit à glisser son propre script dans ce flux, elle peut voler des informations ou détourner une session. La Content Security Policy est justement la barrière qui indique au navigateur quelles sources il a le droit d’exécuter et lesquelles il doit refuser. Cet en-tête de sécurité, abrégé en CSP, compte parmi les défenses les plus efficaces contre les injections de code. Voyons ce qu’il recouvre, comment ses directives s’articulent, ce qu’il apporte réellement, et comment le déployer sans bloquer par mégarde vos propres ressources.

La Content Security Policy (CSP), définition d’un rempart anti-injection

La Content Security Policy est un en-tête HTTP par lequel votre serveur annonce au navigateur la liste des sources de contenu autorisées. Elle vise une catégorie précise de failles de sécurité d’un site web, les injections de code, en empêchant l’exécution de tout script absent de la liste blanche que vous avez définie. Au lieu de faire confiance à tout ce qui arrive, le navigateur adopte alors une posture de méfiance par défaut.

Le rôle d’une CSP face au XSS

L’attaque que la CSP contre en priorité s’appelle le Cross-Site Scripting (XSS) : un attaquant injecte un script dans une page, via un commentaire ou un paramètre d’URL mal filtré, et ce script s’exécute ensuite chez tous les visiteurs. Une politique bien réglée refuse purement et simplement les scripts qui ne proviennent pas de sources déclarées, ce qui neutralise l’immense majorité des injections, même lorsque le filtrage côté serveur a laissé passer quelque chose. Le XSS figure depuis des années parmi les vulnérabilités web les plus répandues, car la moindre zone de saisie mal filtrée peut servir de porte d’entrée. C’est précisément ce qui rend la CSP si utile : elle joue le rôle d’une assurance de dernier recours, qui limite les dégâts même le jour où une faille parvient à se glisser entre les mailles du filet applicatif. Prenons un cas concret : un script pirate tente de charger du code depuis un domaine inconnu pour exfiltrer les identifiants saisis dans un formulaire. Si votre politique n’autorise que vos propres domaines, le navigateur bloque la requête et consigne l’incident. La protection ne repose plus sur la vigilance du développeur seul, mais sur une règle appliquée par le navigateur pour chaque ressource. On mesure mieux l’intérêt avec un ordre de grandeur : une seule ligne d’en-tête protège l’intégralité des pages servies par le site. Là où corriger chaque formulaire un par un prendrait des semaines, une politique bien posée couvre tout le périmètre d’un seul geste, ce qui en fait l’un des meilleurs rapports effort/protection du domaine.

Un en-tête déclaratif, pas un pare-feu

Il ne faut pas confondre la CSP avec un pare-feu applicatif. Elle ne filtre pas le trafic entrant vers le serveur ; elle agit côté client, en disant au navigateur ce qu’il a le droit de faire avec la page reçue. C’est une couche de défense complémentaire, pas un remplacement des autres mesures comme l’échappement des données ou la validation des entrées. Cette nature déclarative est sa force et sa limite. Sa force, car une seule ligne d’en-tête protège l’ensemble des pages servies ; sa limite, car une politique mal pensée peut soit tout casser, soit ne rien protéger. La CSP s’inscrit donc dans une logique de defense in depth, cette superposition de protections indépendantes qui caractérise les sites bien sécurisés. Cette complémentarité mérite d’être expliquée aux équipes. Une CSP ne dispense jamais d’échapper correctement les données ni de tenir ses dépendances à jour ; elle vient couronner ces bonnes pratiques. Présentée de la sorte, elle s’intègre dans une culture de sécurité partagée, au lieu d’être vécue comme une contrainte technique supplémentaire.

Comment fonctionne une politique CSP, directive par directive

Une Content Security Policy se compose d’une suite de directives, chacune encadrant un type de ressource. Comprendre ce vocabulaire est indispensable, car c’est la précision de ces directives qui sépare une politique réellement protectrice d’une politique de façade que l’on contourne en quelques secondes.

Les directives essentielles

Chaque directive cible une famille de contenus et liste les origines acceptées. La directive default-src sert de filet de sécurité général, tandis que des directives plus spécifiques affinent le contrôle pour les scripts, les styles ou les images. Le tableau ci-dessous présente celles que l’on rencontre dans la quasi-totalité des politiques sérieuses. Une politique se lit de gauche à droite, directive après directive, et chaque mot compte. Mieux vaut partir d’une base restrictive, où la directive de repli n’autorise que vos propres origines, puis ouvrir au cas par cas ce qui se révèle strictement nécessaire. Cette démarche du plus fermé vers le plus ouvert produit des politiques bien plus solides que l’inverse.

Les mots-clés : self, nonce et hash

Au-delà des noms de domaine, une directive accepte des mots-clés spéciaux. La valeur self autorise vos propres origines, alors que none interdit tout. Pour les scripts en ligne, deux mécanismes plus fins existent : le nonce, un jeton aléatoire régénéré à chaque page, et le hash, une empreinte du contenu autorisé. Ces deux approches permettent de garder quelques scripts inline en confiance sans ouvrir la porte à tous les autres. L’ennemi à éviter porte un nom : unsafe-inline. Cette valeur autorise n’importe quel script écrit directement dans la page, ce qui revient à désactiver la principale protection de la CSP. Une politique qui s’appuie sur des nonces ou des hash plutôt que sur unsafe-inline offre une sécurité d’un tout autre niveau, car elle redevient imperméable aux injections. Le choix entre nonce et hash dépend du contexte. Le nonce convient aux pages générées dynamiquement, où le serveur insère un jeton neuf à chaque requête ; le hash s’adapte mieux aux contenus statiques figés. Dans les deux cas, on garde la souplesse du code en ligne sans renoncer à la garantie d’intégrité des scripts réellement exécutés.

Le précieux mode report-only

La CSP possède un mode d’observation, déclenché par l’en-tête Content-Security-Policy-Report-Only. Dans ce mode, le navigateur n’interdit rien mais signale tout ce qu’il aurait bloqué, vers une adresse de collecte que vous choisissez. C’est l’outil idéal pour mesurer l’impact d’une politique avant de l’imposer, sans risquer de rendre le site inutilisable pendant les tests. Ce mode rend aussi service bien après le déploiement. Laissé branché en parallèle de la politique active, il alimente un journal permanent des tentatives bloquées. Chaque entrée raconte quelque chose : un script légitime oublié, ou au contraire une tentative d’injection en temps réel, précieuse à analyser pour comprendre les attaques qui visent le site.

Pourquoi déployer une CSP renforce vraiment la sécurité d’un site

Adopter une Content Security Policy modifie en profondeur la posture de sécurité d’un site, surtout lorsqu’elle s’articule avec les autres briques comme une connexion chiffrée en HTTPS. Là où le code serveur cherche à empêcher l’injection, la CSP ajoute une seconde ligne de défense côté navigateur qui prend le relais si la première a cédé.

Réduire la surface d’attaque

Une politique stricte limite drastiquement ce qu’un script malveillant peut accomplir, même s’il parvient à s’insérer. Impossible pour lui de joindre un serveur distant non déclaré, d’injecter une iframe pirate ou de charger un keylogger externe. En verrouillant les destinations possibles, la CSP prive l’attaquant de ses points de sortie, ce qui transforme souvent une faille critique en simple gêne. Il existe un bénéfice de gouvernance moins visible. Documenter la liste des sources autorisées revient à tenir un inventaire vivant des prestataires qui s’exécutent chez vos visiteurs. Cet inventaire facilite les revues de sécurité et les obligations de transparence, en donnant une vue claire de la chaîne de confiance sur laquelle repose chaque page. Cette réduction profite aussi à la maîtrise des dépendances. En listant explicitement chaque domaine tiers autorisé, on prend conscience de tout ce que la page charge réellement. Beaucoup d’équipes découvrent à cette occasion des scripts oubliés ou douteux, qu’elles retirent au passage, améliorant du même coup la confidentialité et la performance. Cet effet de prise de conscience se prolonge dans la durée. Une fois la liste des domaines établie, tout nouvel ajout devient un acte conscient plutôt qu’un réflexe. La CSP agit alors comme un garde-fou contre la prolifération des scripts, ce phénomène silencieux qui alourdit et fragilise tant de sites au fil des années.

Protéger les visiteurs et la réputation

Une attaque par injection qui aboutit ne nuit pas qu’au site : elle frappe directement les visiteurs, dont les données ou les comptes se retrouvent compromis. Prévenir ce scénario, c’est protéger la confiance que les utilisateurs accordent à la marque, un capital long à bâtir et rapide à perdre lors d’un incident public. Un incident évité, c’est également une crise de communication épargnée. La divulgation d’une fuite mobilise des équipes entières et laisse des traces durables dans la mémoire des clients. En abaissant la probabilité d’un tel scénario, la politique protège un actif souvent sous-estimé : la tranquillité opérationnelle de l’entreprise. Sur le plan de la conformité, une CSP bien tenue constitue une preuve tangible de sérieux. Les audits de sécurité et les référentiels comme le RGPD valorisent les mesures techniques de protection des données. Disposer d’une politique documentée et active envoie un signal de maturité aux auditeurs comme aux clients exigeants sur ces questions.

Mettre en place une CSP sans casser votre site

Mettre en oeuvre une Content Security Policy sur un site existant demande de la méthode, car une politique trop stricte appliquée d’un coup risque de bloquer vos propres scripts. L’approche gagnante consiste à avancer par étapes, en observant avant d’interdire.

Commencer en mode rapport

La première étape consiste toujours à déployer la politique en report-only, puis à laisser tourner quelques jours. Les rapports collectés dressent l’inventaire réel de tout ce que charge le site, y compris les ressources légitimes que vous auriez oubliées. On construit ainsi une politique calquée sur le fonctionnement réel des pages, et non sur une vue théorique forcément incomplète. À mesure que les rapports arrivent, on ajuste les directives pour couvrir chaque source légitime. Quand le flux d’alertes se tarit et ne concerne plus que des tentatives indésirables, la politique est mûre. C’est seulement à ce moment qu’on bascule de l’en-tête d’observation vers l’en-tête actif, en gardant un suivi attentif des premiers jours de mise en application. Pendant cette phase, il est judicieux d’associer les personnes qui connaissent les outils en place. L’équipe marketing sait quels scripts de mesure tournent, l’équipe technique connaît les services appelés. Croiser ces savoirs évite d’autoriser à l’aveugle et construit une politique fidèle aux usages réels du site, sans angle mort ni excès de permissivité.

Gérer les scripts tiers et le code en ligne

Le principal point de friction concerne les scripts inline et les services tiers. Plutôt que d’ouvrir grand les vannes avec unsafe-inline, mieux vaut migrer ces scripts vers des fichiers externes ou les autoriser via un nonce. Cet effort initial transforme la politique en barrière réellement étanche aux injections, ce qui est tout l’objectif recherché. Pour les outils externes (mesure d’audience, cartes, vidéos), on déclare précisément leurs domaines, ni plus ni moins. Le tableau suivant rassemble les erreurs les plus fréquentes lors d’un déploiement, avec le réflexe qui les corrige, afin d’éviter les pièges classiques qui découragent tant d’équipes.

Maintenir la politique dans le temps

Une CSP n’est jamais figée, car un site évolue : nouvel outil marketing, nouvelle police, nouveau prestataire vidéo. Chaque ajout peut introduire une source non autorisée et casser une fonctionnalité, ou au contraire être glissé sans contrôle. Intégrer la révision de la politique au processus de mise en production évite ces deux écueils symétriques. Garder le endpoint de rapport actif, même après le passage en mode bloquant, offre une surveillance continue. Les violations remontées signalent aussi bien une tentative d’attaque qu’un oubli de configuration. Cette vigilance permanente sur les rapports maintient la Content Security Policy utile année après année, au rythme des évolutions du site. Sur les projets menés à plusieurs, consigner la politique dans le dépôt de code, au même titre que le reste, facilite sa relecture. Toute modification passe alors par la même validation que le code applicatif, ce qui empêche les changements furtifs et conserve une trace historique des décisions de sécurité prises au fil du temps.