Content Security Policy : la défense la plus importante que 89% des sites ignorent

Partie 3 de la série « Sécurité web dans l'UE : 10 étapes pour une meilleure note »

Pourquoi CSP est important

Le Cross-Site Scripting (XSS) est la vulnérabilité d'application web la plus courante depuis plus de 20 ans. Un attaquant injecte du JavaScript dans votre site web — via un formulaire, un paramètre d'URL, un commentaire. Le navigateur du visiteur exécute le code car il ne peut pas le distinguer du contenu légitime de la page.

Content Security Policy (CSP) résout ce problème : vous définissez explicitement quelles sources le navigateur peut accepter pour les scripts, les styles, les images et les autres ressources. Tout le reste est bloqué.

Taux d'adoption dans l'UE : 10,8%. Neuf sites web sur dix n'ont pas d'en-tête CSP.

Ce que disent les données

D'après le Benchmark SiteGuardian couvrant plus de 700 000 sites web européens :

• 10,8% ont un en-tête CSP
• Les sites web avec security.txt ont CSP dans 47% des cas — 4,7 fois plus souvent
• Permissions-Policy (en-tête associé) : seulement 6,4%

Déployer CSP étape par étape

Le plus grand obstacle : une CSP trop stricte casse le site. Google Analytics ne charge plus, les vidéos YouTube intégrées disparaissent, les styles en ligne ne fonctionnent plus.

Étape 1 : Mode Report-Only (ne casse rien)

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

Le navigateur signale les violations mais ne bloque rien. Vous voyez quelles sources externes votre site utilise sans rien casser.

Étape 2 : Identifier les sources

Surveillez les rapports pendant 1 à 2 semaines. Sources typiques que vous devrez autoriser :

• Google Analytics : https://www.googletagmanager.com https://www.google-analytics.com
• Google Fonts : https://fonts.googleapis.com https://fonts.gstatic.com
• Vidéos YouTube : https://www.youtube.com https://www.youtube-nocookie.com
• Votre CDN : https://cdn.votre-domaine.com

Étape 3 : Construire la politique

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src https://fonts.gstatic.com; img-src 'self' data: https:; frame-src https://www.youtube-nocookie.com

Étape 4 : Activer

Supprimez -Report-Only du nom de l'en-tête. Testez le site en profondeur.

Directives clés

Nginx

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none'; base-uri 'self'" always;

Apache

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none'; base-uri 'self'"

Erreurs courantes

1. unsafe-inline pour les scripts. script-src 'unsafe-inline' autorise n'importe quel script en ligne — rendant la CSP entièrement inutile contre les XSS. Utilisez des nonces ou des hashes à la place.

2. * comme source. default-src * autorise tout depuis partout. Ce n'est pas une politique, c'est un placebo.

3. Commencer trop strictement. Commencez toujours en Report-Only. Une CSP qui casse le site et est immédiatement désactivée ne protège personne.

Contexte réglementaire

• NIS2 Art. 21(2)(d) — sécurité dans le développement et la maintenance des systèmes d'information
• RGPD Art. 32 — les XSS peuvent mener à des violations de données (détournement de session, vol de cookies)
• PCI DSS 4.0 — L'exigence 6.4.3 impose explicitement CSP pour les pages de paiement

Vérifiez votre CSP

SiteGuardian ne détecte pas seulement si un en-tête CSP existe, mais analyse les directives à la recherche de faiblesses connues :

https://siteguardian.io/scan

La semaine prochaine dans la Partie 4 : DNSSEC — pourquoi 84% des domaines de l'UE n'ont aucune protection contre le DNS spoofing.