CSP (Content Security Policy) : le bouclier invisible qui protège vos sites web
Mis à jour le 11/07/2026 par Adrien Vialatte
La CSP, ou Content Security Policy, est l'un des mécanismes de sécurité les plus puissants disponibles dans les navigateurs modernes — et pourtant l'un des moins connus du grand public. En résumé : une CSP est un en-tête HTTP qui dicte au navigateur quelles ressources il est autorisé à charger sur une page web. Selon l'OWASP (Open Web Application Security Project), les attaques XSS (cross-site scripting) figurent encore parmi les dix vulnérabilités web les plus fréquentes ; une CSP bien configurée réduit drastiquement leur impact.
Qu'est-ce qu'une CSP ?
Une CSP (Content Security Policy) est une politique de sécurité des contenus transmise par un serveur web au navigateur via un en-tête HTTP, qui définit précisément les sources de données autorisées pour une page donnée. En clair : elle dit au navigateur « tu n'as le droit de charger du JavaScript qu'en provenance de ces domaines, et rien d'autre ».
Ce mécanisme a été introduit par Mozilla en 2004 sous le nom de « Content Restrictions », avant d'être standardisé par le W3C. Aujourd'hui, la spécification CSP Level 3 est supportée par tous les navigateurs modernes — Chrome, Firefox, Safari, Edge — et constitue une couche de défense indispensable dans toute architecture web sérieuse.
Pour un non-développeur, imaginez que votre navigateur est comme un agent de sécurité à l'entrée d'un bâtiment. Sans CSP, il laisse entrer n'importe qui. Avec une CSP, vous lui remettez une liste blanche : seules les personnes sur cette liste franchissent la porte. Même si un attaquant a réussi à glisser un bout de code malveillant dans votre page (via une faille dans un formulaire, un plugin tiers, un éditeur de contenu), le navigateur refuse simplement de l'exécuter.
La CSP ne remplace pas les autres protections (validation des entrées côté serveur, HTTPS, gestion des sessions...), mais elle est une défense en profondeur essentielle. Elle représente la deuxième ligne de défense quand la première — la prévention des injections — a été contournée.
Pourquoi la CSP est-elle indispensable aujourd'hui ?
La CSP est indispensable parce que les attaques XSS (cross-site scripting) sont massives, souvent invisibles pour l'utilisateur, et potentiellement dévastatrices pour les données personnelles.
Pour mettre les choses en perspective : selon le rapport annuel de l'OWASP (disponible sur owasp.org), les failles d'injection — dont XSS — font partie du Top 10 des vulnérabilités web depuis plus de dix ans. Le principe d'une attaque XSS est simple : un attaquant parvient à injecter du code JavaScript malveillant dans une page web légitime. Ce code s'exécute dans le navigateur de chaque visiteur et peut :
- Voler les cookies de session (et donc se connecter à la place de l'utilisateur)
- Capturer les frappes au clavier (keylogging) sur les formulaires de paiement
- Rediriger vers des sites de phishing
- Exfiltrer des données sensibles vers un serveur contrôlé par l'attaquant
J'ai eu l'occasion d'accompagner plusieurs projets web côté audit de sécurité. Dans un cas concret, un site e-commerce sur WordPress avait un plugin de gestion de commentaires mal maintenu. Une injection XSS était possible via le champ "site web" du formulaire. La CSP configurée sur le serveur a bloqué l'exécution du script injecté lors de mes tests — sans aucune modification du plugin lui-même. C'est exactement le rôle que la CSP est supposée jouer.
Comment fonctionne une Content Security Policy ?
Une CSP fonctionne en ajoutant un en-tête HTTP nommé `Content-Security-Policy` à chaque réponse du serveur web. Cet en-tête contient une liste de directives qui définissent les sources autorisées pour chaque type de ressource (scripts, styles, images, polices, etc.).
Le mécanisme d'en-tête HTTP
Lorsque votre navigateur reçoit une page web, il inspecte les en-têtes HTTP avant même de rendre la page. Si un en-tête `Content-Security-Policy` est présent, le navigateur applique ses règles à la lettre. Toute ressource dont l'origine ne figure pas dans la liste est bloquée et signalée dans la console du navigateur.
Voici un exemple simplifié d'en-tête CSP :
``` Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src *; ```
Ce que dit cette règle :
- `default-src 'self'` : par défaut, toutes les ressources ne peuvent venir que du même domaine
- `script-src 'self' https://cdn.example.com` : les scripts ne peuvent être chargés que depuis le domaine du site lui-même OU depuis cdn.example.com
- `img-src *` : les images peuvent venir de n'importe où
Le mode rapport (Report-Only)
L'une des fonctionnalités les plus utiles de la CSP est son mode "rapport uniquement" : en utilisant l'en-tête `Content-Security-Policy-Report-Only` à la place, le navigateur ne bloque rien, mais envoie un rapport JSON à une URL de votre choix chaque fois qu'une ressource aurait été bloquée. Ce mode est précieux pour tester une politique CSP sans risquer de casser le site en production.
La directive `report-uri` (ou `report-to` dans CSP Level 3) permet de collecter ces violations et de les analyser avant d'activer le blocage réel.
Quelles sont les directives CSP les plus importantes ?
Les directives CSP les plus importantes sont celles qui contrôlent le chargement des scripts, des styles et des connexions réseau, car ce sont les vecteurs d'attaque les plus courants.
Voici un tableau récapitulatif des principales directives :
| Directive | Rôle | Exemple de valeur |
|---|---|---|
| `default-src` | Fallback pour toutes les ressources non spécifiées | `'self'` |
| `script-src` | Sources autorisées pour le JavaScript | `'self' https://cdn.jsdelivr.net` |
| `style-src` | Sources autorisées pour les CSS | `'self' 'unsafe-inline'` |
| `img-src` | Sources autorisées pour les images | `* data:` |
| `connect-src` | URLs autorisées pour fetch/XHR/WebSocket | `'self' https://api.monsite.fr` |
| `font-src` | Sources autorisées pour les polices | `'self' https://fonts.gstatic.com` |
| `frame-src` | Sources autorisées pour les iframes | `'none'` |
| `report-uri` | URL de collecte des violations | `/csp-rapport` |
Les valeurs spéciales à connaître
Certaines valeurs méritent une attention particulière :
- `'self'` : uniquement l'origine du document (même protocole + domaine + port). À noter les apostrophes simples obligatoires.
- `'none'` : aucune source autorisée (bloque tout pour cette directive).
- `'unsafe-inline'` : autorise le code inline (`