Une Content Security Policy (CSP) est un en-tête de réponse HTTP qui indique au navigateur depuis quelles sources une page peut charger scripts, styles, images et connexions. Tout ce qui ne figure pas sur cette liste d’autorisation est bloqué avant son exécution. Normalisée par le W3C, la CSP est la principale défense native du navigateur contre le cross-site scripting (XSS) et l’injection de scripts.
En bref : qu’est-ce que CSP
- CSP fonctionne en déclarant une liste blanche par type de ressource (script-src, img-src, connect-src, etc.). Tout ce qui n’y figure pas est bloqué par le navigateur avant exécution.
- Elle est transmise via un en-tête de réponse HTTP ou une balise
<meta>dans le<head>de la page, et le mode Report-Only permet de tester une politique sans casser le site. - La CSP est une base, pas une défense complète. Elle contrôle d’où un script est chargé, pas ce qu’il fait une fois exécuté : un domaine compromis mais autorisé s’exécute quand même.
- CSP seul ne suffit pas à la conformité PCI DSS 4.0.1. L’exigence §6.4.3 requiert l’inventaire et l’autorisation des scripts ; la §11.6.1 requiert la détection d’altération. Les deux vont au-delà de ce que CSP peut imposer, surtout face à un domaine autorisé compromis comme dans l’incident Polyfill.io de 2024.
Que signifie CSP ?
CSP signifie Content Security Policy (Politique de Sécurité du Contenu). C’est un en-tête de réponse HTTP (que l’on peut aussi définir via une balise <meta> dans le <head> de la page) qui indique au navigateur quelles sources de scripts, de styles, d’images et de connexions une page est autorisée à charger, et qui bloque tout ce qui ne figure pas sur cette liste blanche avant son exécution.
Comprendre la Politique de Sécurité du Contenu (CSP)
La Politique de Sécurité du Contenu (CSP) est une fonctionnalité de sécurité du navigateur qui a été mise en œuvre pour atténuer certains types d’attaques basées sur le navigateur, comme le cross-site scripting. La CSP a été standardisée par le World Wide Web Consortium (W3C) dans la spécification CSP Level 3, elle permet à un site web d’envoyer un ensemble de règles (via des en-têtes de réponse HTTP ou des balises <meta> à l’intérieur du <head> HTML) qui indiquent au navigateur quelles sources de contenu sont autorisées.
Ces règles, appelées directives, spécifient les origines approuvées pour les scripts, les images, les styles, les iframes et plus encore. L’objectif principal de l’utilisation de CSP est d’avoir un contrôle total sur l’origine des scripts chargés, ainsi que de contrôler quels scripts une page est autorisée à exécuter, tentant ainsi d’empêcher l’exécution de scripts injectés ou non autorisés.
Par exemple, une directive CSP pourrait indiquer que les scripts ne doivent être chargés que depuis le propre domaine du site (fait en utilisant ‘self’), ou depuis des domaines de confiance spécifiques. Le navigateur bloquera alors tout fichier de script ou script inline qui n’est pas d’une source autorisée. Cela protège contre les attaques XSS, où un attaquant tente d’injecter des balises <script> ou du code malveillant dans un site. De nos jours, la plupart des navigateurs prennent également en charge le mode ‘Report-only’ de CSP. Cela permet aux développeurs de tester une politique en toute sécurité. Lorsqu’il est activé, les violations de politique sont enregistrées sur un point de terminaison de rapport au lieu d’être bloquées immédiatement. C’est une bonne pratique lors du premier déploiement de CSP.
Comment fonctionne la Politique de Sécurité du Contenu (CSP)
Une Politique de Sécurité du Contenu est livrée à un navigateur via l’en-tête de réponse HTTP nommé Content-Security-Policy, ou via une balise meta dans le <head> HTML. La politique consiste en directives séparées par des points-virgules, et chaque directive contrôle un type de ressource spécifique.
- ‘script-src’ self : permet les scripts uniquement depuis la même origine. Tout
<script>d’un autre domaine (ou code de script inline) est bloqué par le navigateur. - ‘connect-src’ self https://api.domain.com : permet les appels AJAX/XHR/fetch uniquement vers le même site, ou vers le domaine de confiance api.domain.com. Cela empêche le code malveillant d’exfiltrer des données vers des serveurs inconnus depuis le site.
- img-src ‘self’ data : peut être utilisé pour charger uniquement des images depuis le même site et bloquer les images externes, ce qui peut être utilisé pour empêcher les fuites de données via les requêtes d’image.
Nonces CSP et hashes CSP
CSP prend également en charge des mécanismes avancés tels que les nonces (‘nonce-abc123’) et les hashes (‘sha256-xyz…’). Ceux-ci permettent aux scripts inline de s’exécuter en toute sécurité en prouvant cryptographiquement leur intégrité. Au lieu d’interdire tout le code inline, les développeurs peuvent autoriser sélectivement des scripts spécifiques. Cela améliore la flexibilité sans sacrifier la sécurité.
Il existe une multitude d’autres directives qui peuvent être utilisées pour d’autres types de données comme les médias, les polices, les iframes, etc., mais l’idée centrale de l’utilisation d’une Politique de Sécurité du Contenu est de créer une liste blanche de sources de confiance. Lorsque le navigateur charge une page et demande quel contenu charger, il se référera d’abord à la CSP et appliquera ces règles à chaque chargement. Tout script ou ressource qui contrevient à cette politique ne sera pas chargé. Pour un guide d’implémentation détaillé, consultez la fiche de référence CSP d’OWASP.
Directives CSP courantes et leur objectif
| Directive | Objectif | Cas d’usage typique |
|---|---|---|
default-src | Définit une politique de base pour toutes les ressources lorsqu’aucune autre règle ne s’applique. | Commencez strict : default-src 'none'; |
script-src | Contrôle quelles sources JavaScript sont autorisées. | Mettez en liste blanche 'self', les CDN, ou utilisez des scripts basés sur nonce/hash. |
style-src | Limite d’où le CSS peut être chargé. | Utilisez 'self' ; évitez 'unsafe-inline' lorsque possible. |
img-src | Définit les sources d’image de confiance. | Empêchez les fuites de données via les appels d’image externes. |
connect-src | Restreint les destinations AJAX, fetch et WebSocket. | Bloquez l’exfiltration de données vers des domaines inconnus. |
frame-ancestors | Spécifie quels sites peuvent intégrer vos pages dans des iframes. | Empêchez le clickjacking : frame-ancestors 'none'; |
report-uri / report-to | Définit où les rapports de violation CSP sont envoyés. | Enregistrez et analysez les violations CSP pour ajuster la politique. |
Exemples d’en-tête CSP à copier dès aujourd’hui
Voici des points de départ prêts à copier pour les déploiements CSP les plus courants. Testez d’abord en mode Content-Security-Policy-Report-Only, surveillez les rapports pour détecter les scripts légitimes qui seraient bloqués, puis passez en mode d’application.
1. Politique de démarrage stricte (refus par défaut + liste blanche)
Content-Security-Policy:
default-src 'none';
script-src 'self' https://cdn.example.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
connect-src 'self' https://api.example.com;
font-src 'self' https://fonts.gstatic.com;
form-action 'self';
frame-ancestors 'none';
base-uri 'self';
upgrade-insecure-requests;
report-uri /csp-report;
report-to csp-endpoint;2. Scripts inline basés sur un nonce
Content-Security-Policy: script-src 'nonce-r@nd0mNonceHere' 'strict-dynamic';<script nonce="r@nd0mNonceHere">
// this script executes; anything without the matching nonce does not
</script>3. Scripts inline basés sur un hash
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8=';Générez le hash avec : echo -n "your inline script contents" | openssl dgst -sha256 -binary | openssl base64
4. Mode Report-Only (pas de blocage, juste de la surveillance)
Content-Security-Policy-Report-Only:
default-src 'self';
script-src 'self' https://cdn.example.com;
report-to csp-endpoint;5. Point de terminaison Report-To (rapport moderne)
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
Content-Security-Policy: default-src 'self'; report-to csp-endpoint;6. Exemple de payload de violation
{
"csp-report": {
"document-uri": "https://example.com/checkout",
"referrer": "",
"violated-directive": "script-src 'self'",
"effective-directive": "script-src",
"original-policy": "default-src 'self'; report-uri /csp-report",
"disposition": "enforce",
"blocked-uri": "https://malicious.example/skimmer.js",
"line-number": 42,
"source-file": "https://example.com/checkout",
"status-code": 200,
"script-sample": ""
}
}7. Middleware Express.js
app.use((req, res, next) => {
res.setHeader(
"Content-Security-Policy",
"default-src 'self'; script-src 'self' https://cdn.example.com; report-uri /csp-report",
);
next();
});
app.post("/csp-report", express.json({ type: "application/csp-report" }), (req, res) => {
console.log("CSP violation", req.body);
res.sendStatus(204);
});8. Cloudflare Worker
export default {
async fetch(request, env) {
const response = await fetch(request);
const headers = new Headers(response.headers);
headers.set(
"Content-Security-Policy",
"default-src 'self'; script-src 'self' https://cdn.example.com; report-to csp-endpoint",
);
return new Response(response.body, { status: response.status, headers });
},
};Référence étendue des directives
Au-delà des sept directives ci-dessus, CSP en définit plusieurs autres qui apparaissent dans le travail de durcissement en production :
| Directive | Objectif |
|---|---|
strict-dynamic | Fait confiance aux scripts chargés par un script déjà de confiance (nonce ou hash). Simplifie le chargement via CDN. |
upgrade-insecure-requests | Met automatiquement à niveau les sous-ressources http: vers https:. Élimine les alertes de contenu mixte. |
require-trusted-types-for | Applique Trusted Types sur les sinks DOM dangereux (par ex. innerHTML, Function()). |
sandbox | Applique un sandboxing de type iframe à la page entière. Puissant, nécessite des tests soignés. |
form-action | Restreint où les soumissions <form> peuvent envoyer des requêtes POST. Bloque les redirections de phishing. |
base-uri | Verrouille l’élément <base> à des origines spécifiques. Prévient les attaques d’injection <base>. |
manifest-src | Contrôle d’où un manifeste d’application web peut être chargé. |
media-src | Restreint les sources <audio> et <video>. |
object-src | Restreint <object>, <embed>, <applet>. Définir sur 'none' sur les sites modernes. |
worker-src | Restreint les sources des Web Workers et Service Workers. |
Attention à 'unsafe-inline' et 'unsafe-eval'. Les deux sont encore pris en charge mais désactivent la majeure partie de la protection de CSP contre le XSS. 'strict-dynamic' avec des nonces constitue la voie de remplacement moderne.
Voyez-le sur votre propre site
CSP est une couche de défense côté client, et une couche critique pour la conformité PCI DSS 4.0.1. Mais CSP seul n’a pas arrêté l’attaque Polyfill.io en 2024 car le domaine compromis était sur la liste blanche. cside ajoute l’inventaire des scripts et l’analyse de payload par-dessus CSP pour combler la faille. Niveau gratuit disponible.
Comment la CSP prévient-elle les attaques basées sur le navigateur ?
Atténuation des attaques XSS
Dans une attaque de cross-site scripting, ou attaque XSS, un attaquant trouve généralement un moyen d’injecter et d’exécuter du code JavaScript malveillant dans votre page (comme sur une entrée non assainie). Par défaut, une CSP bloquera tout script inline de s’exécuter sur la page, sauf si une directive de politique l’autorise explicitement. Cela signifie qu’un attaquant qui injecte quelque chose comme <script>evilCode()</script> dans une page, cela ne s’exécutera pas (sauf si ‘unsafe-inline’ est autorisé dans la CSP !)
Blocage des scripts tiers non autorisés
De nombreux sites ont des scripts tiers pour des choses comme l’analyse, le suivi des utilisateurs et la publicité. Avec une CSP, les propriétaires de sites peuvent limiter quels sites externes peuvent réellement fournir des scripts. Par exemple, si vous ne cherchez qu’à servir du contenu depuis analytics._example_.com et rien d’autre depuis example.com, la directive script-src de la CSP de votre site peut explicitement n’autoriser que cela.
Prévention de l’exfiltration de données
Comme mentionné précédemment, une CSP peut restreindre les actions sur une page qui peuvent être utilisées pour empêcher le code JavaScript malveillant d’envoyer des données vers un domaine contrôlé par un attaquant. L’utilisation de la directive connect-src bloque les requêtes réseau vers des serveurs non autorisés, et peut être utilisée en combinaison avec la directive form-action pour s’assurer que les données ne sont envoyées qu’à votre domaine.
Application de pratiques de navigation sécurisées
Une CSP dispose de directives pour appliquer des comportements sécurisés qui améliorent la sécurité de votre site en général.
- Un exemple est
upgrade-insecure-requests, qui force le navigateur à charger toutes les ressources via HTTPS, empêchant les problèmes de contenu mixte et non sécurisé. - Une autre directive est
frame-ancestors, qui peut empêcher les attaques de clickjacking en interdisant l’intégration de votre page dans un cadre contrôlé par un attaquant.
Combinées, ces politiques aboutissent à une base solide côté client pour les applications web modernes.
Limitations de sécurité de CSP
L’utilisation d’une Politique de Sécurité du Contenu fournit une protection forte mais ce n’est pas une solution universelle pour votre site, comme le souligne notre article « Pourquoi la Politique de Sécurité du Contenu ne fonctionne pas ».
Les politiques peuvent dériver au fil du temps, et les listes blanches n’inspectent pas le comportement du code. Chaque navigateur majeur implémente CSP à sa manière, légèrement différente. Chrome, Firefox, Safari et Edge prennent tous en charge CSP Level 3 ; le comportement de rapport et les formats de violation peuvent varier. Pour valider et maintenir votre politique, testez-la régulièrement avec les outils de développement du navigateur et des scanners automatisés tels que Mozilla Observatory ou SecurityHeaders.io.
Associer une CSP avec un couche de sécurité côté client active comme cside pour ajouter une inspection et un blocage en temps réel aux scripts tiers sur votre site vous donne une excellente couche de défense, avec la tranquillité d’esprit pour vos clients. D’un point de vue gouvernance, documenter les mises à jour CSP et surveiller les rapports de violation améliore l’auditabilité et la conformité à long terme avec des cadres tels que l’ISO 27001 et l’OWASP ASVS.
Est-ce que CSP fonctionne pour la conformité PCI DSS 6.4.3 ?
Selon l’exigence 6.4.3 de PCI DSS 4.0.1, les commerçants doivent prouver que chaque script côté client est autorisé et prouver l’intégrité du script. CSP et SRI vous mènent en partie là. CSP limite quels domaines peuvent charger des scripts, et SRI vérifie que le code d’un fichier n’a pas changé. Mais ensemble, ils constituent une solution statique à un problème dynamique. Les scripts dynamiques se mettent à jour et les hashes se cassent. La maintenance manuelle des listes CSP est presque impossible.
La plupart des sites modernes utilisent des scripts tiers dynamiques, donc ces contrôles se dégradent rapidement. Cette approche ne répondra généralement pas aux preuves requises pour PCI 6.4.3.
Un exemple de Content Security Policy (CSP) : quand une CSP stricte a cassé la production
Le jour où le check-out a cessé de fonctionner : comment une CSP stricte a cassé la production
Tout a commencé avec un simple nouveau déploiement. Rien de spécial, juste une nouvelle Politique de Sécurité du Contenu pour rendre une boutique de commerce électronique plus sécurisée et empêcher les attaquants d’y introduire du code malveillant.
Le default-src ‘none’ propre a été défini sans test. Et donc, au moment où la CSP a été activée, le site web a bloqué des services dont il avait réellement besoin. Les outils d’analyse ont cessé de fonctionner et, pire que tout, le système de paiement a été bloqué. Les clients ne pouvaient pas finaliser leurs commandes et le système de check-out s’est cassé. Les développeurs se sont mis au travail et ont changé l’en-tête en Content-Security-Policy-Report-Only, puis ont collecté les journaux de violation. À partir de là, ils ont construit une liste blanche (script-src ‘self’ https://pay.examplecase.com) avec tous les services dont la boutique en ligne avait besoin pour fonctionner correctement.
Après avoir affiné la CSP, l’équipe a déployé sans aucune interruption. Ce type de négligence est un incident courant lorsque les équipes gèrent la CSP en interne. Oublier de mettre sur liste blanche un nouveau script marketing, des erreurs de configuration technique, ou des problèmes avec des scripts dynamiques qui cassent les protocoles de hachage font de la CSP un cauchemar à gérer à grande échelle.
Générez et maintenez votre CSP automatiquement avec cside
Écrire et maintenir une Politique de Sécurité du Contenu à la main est là où la plupart des équipes se retrouvent bloquées : chaque nouvelle balise marketing, chaque script tiers dynamique ou changement d’endpoint d’un fournisseur peut casser la politique ou élargir silencieusement la liste blanche. cside supprime ce travail manuel.
cside observe les scripts que votre site charge réellement et génère pour vous un en-tête CSP prêt à déployer à partir de sessions de navigateur réelles, puis le maintient à jour à mesure que ces scripts changent, pour que vous n’ayez pas à poursuivre les mises à jour de la liste blanche à la main. Vous obtenez une Politique de Sécurité du Contenu qui reflète ce que votre site exécute vraiment, ainsi que l’inventaire des scripts et la détection des altérations que la CSP seule ne peut pas fournir pour les exigences §6.4.3 et §11.6.1 de PCI DSS 4.0.1.
Il n’y a rien à développer. Inscrivez-vous à l’offre gratuite, ajoutez votre domaine, et cside commence à générer votre CSP à partir du trafic réel. Découvrez la solution de gestion de CSP ou voyez comment cside comble les lacunes qu’une CSP laisse ouvertes.
