CSP

CSP (Content Security Policy) est un en-tête de réponse HTTP qui indique aux navigateurs quelles sources de contenu la page fait confiance. Il définit des listes blanches par type de contenu : script-src pour JavaScript, style-src pour CSS, img-src pour les images, connect-src pour fetch/XHR/WebSocket, frame-src pour les iframes, etc.

Exemple d’en-tête : Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:.

La valeur principale de CSP : défense en profondeur contre les XSS. Même si un attaquant injecte du JavaScript dans votre page, un CSP strict empêche le navigateur de l’exécuter (car il est chargé depuis une origine absente de la liste blanche) ou d’envoyer des données (car connect-src bloque l’exfiltration vers les domaines de l’attaquant).

Bonne pratique moderne : utiliser un CSP basé sur des nonces — chaque réponse de page inclut un nonce aléatoire dans son en-tête CSP (ex. script-src 'nonce-AbC123') et les balises script inline qui correspondent à ce nonce peuvent s’exécuter. C’est strict mais permet de livrer du contenu dynamique de manière sécurisée. Des analyseurs statiques comme CSP Evaluator de Google évaluent votre politique et signalent les faiblesses.

Erreurs CSP courantes qui annulent l’effet : utiliser 'unsafe-inline' dans script-src (réautorise l’injection inline que vous vouliez bloquer), utiliser un wildcard https: comme source de scripts (n’importe quel hôte HTTPS peut servir du JS à votre origine), ou faire confiance à un hôte CDN capable de JSONP qui permet aux attaquants de créer une URL retournant du JavaScript contrôlé par l’attaquant. L’article de 2016 “CSP Is Dead, Long Live CSP!” de l’équipe sécurité de Google a montré que 95% des politiques dans la nature étaient trivialement contournables pour ces raisons ; 'strict-dynamic' + nonces était leur correctif proposé et est maintenant la recommandation par défaut.

CSP rapporte les violations de politique à une URL spécifiée dans report-uri (déprécié) ou report-to. Déployez d’abord une nouvelle politique en mode Content-Security-Policy-Report-Only — le navigateur signalera les violations sans bloquer le contenu, vous permettant de corriger les sources légitimes avant l’application. Connexe : XSS, CORS, SRI (Intégrité des sous-ressources). Référence : W3C CSP Niveau 3.

Un exemple mesuré : comment strict-dynamic fonctionne

Une politique stricte dans le monde réel ressemble à : Content-Security-Policy: script-src 'nonce-r4nd0m' 'strict-dynamic' https:; object-src 'none'; base-uri 'none'. Le serveur génère un nouveau nonce de 128 bits par réponse (typiquement 22 caractères base64url), l’intègre dans les balises <script nonce="r4nd0m"> correspondantes, et émet l’en-tête. strict-dynamic propage la confiance de manière transitive : les scripts chargés par le script avec nonce peuvent charger d’autres scripts sans liste blanche explicite, mais les scripts injectés sans nonce sont bloqués. CSP Evaluator de Google note les politiques sur une échelle de 0-10 ; une politique strict-dynamic sans 'unsafe-inline' ni wildcard d’hôte obtient 9+, alors qu’une politique héritée typique avec des sources CDN en wildcard obtient 1-3. La même étude Google couvrant 1,6 million de politiques a montré que l’ajout de strict-dynamic réduisait la part contournable pour XSS de 95% à moins de 5%.

Comment CSP interagit avec les fonctionnalités du navigateur

CSP bloque plus que la seule exécution de scripts. connect-src restreint fetch, XHR, WebSocket, EventSource et l’API Beacon — utile pour arrêter l’exfiltration de données même après un XSS réussi. frame-ancestors remplace l’ancien en-tête X-Frame-Options pour la protection contre le clickjacking. upgrade-insecure-requests réécrit automatiquement les URL de sous-ressources HTTP en HTTPS. require-trusted-types-for 'script' active l’API Trusted Types, qui force tous les sinks DOM (innerHTML, eval, etc.) à n’accepter que des objets spécialement typés, bloquant les XSS basés sur le DOM à la source. Les navigateurs modernes envoient des rapports de violation en JSON à l’endpoint report-to, regroupés via l’API de reporting. Référence : Article ACM CCS 2016 de Google “CSP Is Dead, Long Live CSP!”.