Le Cross-Site Scripting (XSS) reste dans le Top 10 OWASP année après année. La Content Security Policy (CSP) est un puissant en-tête HTTP qui indique à votre navigateur quelles ressources peuvent et ne peuvent pas être chargées. Dans cet article, vous apprendrez à implémenter CSP efficacement, à éviter les erreurs courantes et à protéger votre application web contre les attaques XSS.
Qu'est-ce que la Content Security Policy ?
La Content Security Policy est un standard W3C qui communique au navigateur via un en-tête HTTP ou une balise meta quelles sources sont de confiance. Lorsqu'un script, une feuille de style ou une image provenant d'une source non autorisée tente de se charger, le navigateur le bloque automatiquement. Cela fait du CSP l'un des mécanismes de défense les plus puissants contre le XSS, le clickjacking et les attaques par injection de données.
CSP fonctionne avec des directives comme script-src, style-src, img-src et default-src, chacune spécifiant quelles sources sont autorisées pour ce type de contenu. Vous pouvez ajouter des domaines spécifiques en liste blanche, utiliser des nonces ou des hashes pour les scripts inline, et même activer le reporting pour surveiller les violations sans bloquer le trafic.
# Exemple d'en-tête CSP dans Nginx
add_header Content-Security-Policy "
default-src 'self';
script-src 'self' 'nonce-abc123' https://cdn.example.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://api.example.com;
frame-ancestors 'none';
base-uri 'self';
form-action 'self';
";Erreurs CSP courantes et comment les éviter
L'erreur la plus courante dans l'implémentation CSP est l'utilisation de unsafe-inline et unsafe-eval pour les scripts. Ces directives sapent l'objectif même du CSP, car elles laissent ouvertes exactement les vecteurs d'attaque que CSP devrait bloquer. Utilisez plutôt des politiques basées sur les nonces ou les hashes qui autorisent des scripts inline spécifiques.
Une autre erreur courante est une directive script-src trop large, comme le whitelisting de domaines CDN entiers. Si un attaquant peut héberger un script malveillant sur le même CDN, il contourne votre CSP entièrement. Utilisez strict-dynamic combiné avec des nonces pour une approche plus robuste.
- Évitez unsafe-inline et unsafe-eval — utilisez des nonces ou des hashes
- Commencez avec Content-Security-Policy-Report-Only pour tester sans bloquer
- Utilisez strict-dynamic pour la compatibilité avec les frameworks modernes
- Configurez report-uri ou report-to pour une surveillance continue
- N'oubliez pas frame-ancestors — il remplace X-Frame-Options
- Implémentez base-uri pour prévenir le détournement de balise base
CSP en production : surveillance et itération
Un CSP efficace n'est pas une configuration unique mais un processus continu. Commencez par Content-Security-Policy-Report-Only pour collecter les violations sans casser la fonctionnalité. Analysez les rapports, affinez votre politique, et ne passez à l'application que lorsque vous êtes sûr que toutes les sources légitimes sont autorisées.
Utilisez des outils comme le CSP Evaluator de Google ou Report URI pour valider votre politique et agréger les rapports. Dans un pipeline CI/CD, vous pouvez ajouter des tests automatisés qui vérifient que l'en-tête CSP est présent et correct après chaque déploiement. N'oubliez pas de mettre à jour votre CSP lors de l'intégration de nouveaux services tiers.
Conseil Pro
Commencez dès aujourd'hui en ajoutant un en-tête Content-Security-Policy-Report-Only à votre application. Utilisez une approche basée sur les nonces pour les scripts et configurez report-to pour surveiller les violations. En une semaine, vous aurez suffisamment de données pour implémenter un CSP strict qui bloque 90% de toutes les attaques XSS.
Partager cet article