Comment corriger un en-tête Content-Security-Policy (CSP) manquant | Scanthra

Scanthra · 7 min de lecture · Mis à jour Mai 2026

Qu'est-ce que l'en-tête Content-Security-Policy ?

Le CSP est un en-tête de réponse qui dit au navigateur exactement quelles sources de scripts, de styles, d'images et de frames il est autorisé à charger. Si quelque chose sur la page essaie de charger un script depuis un domaine qui n'est pas sur ta liste blanche, le navigateur refuse. C'est comme une liste d'invités pour le videur à l'entrée.

Sans CSP, n'importe quelle balise <script> injectée — depuis un plugin piraté, une faute de frappe dans un widget tiers, une XSS stockée dans un commentaire — s'exécute avec un accès total aux cookies, aux données de formulaire et à la session de tes visiteurs. Avec un CSP strict, la même injection est silencieusement bloquée et journalisée.

Pourquoi c'est important pour une petite entreprise

Deux exemples concrets qu'on voit chaque semaine dans les rapports Scanthra :

• Skimming de carte sur les paiements — une bibliothèque JavaScript compromise sur une boutique WooCommerce lit les numéros de carte et les exfiltre. Avec CSP, cette requête d'exfiltration vers un domaine attaquant est bloquée.
• Défacement et superpositions de phishing — un script injecté remplace ton formulaire de contact par un qui envoie les données à l'attaquant. CSP refuserait de charger le script inconnu dès le départ.

Le CSP est aussi explicitement recommandé par OWASP (standard de sécurité applicative), attendu par la plupart des questionnaires de cyber-assurance, et — pour les entreprises européennes — une partie sensée des « mesures techniques appropriées » requises par l'article 32 du RGPD et la directive NIS2 (directive UE sur la cybersécurité).

Le déploiement sûr : d'abord en mode report-only

La principale raison pour laquelle les petits sites évitent le CSP, c'est la peur de casser la mise en page. La solution : déploie d'abord Content-Security-Policy-Report-Only. Le navigateur vérifie la politique et signale les violations, mais ne les applique pas. Observe les logs pendant une semaine, corrige ce qui est bloqué, puis bascule vers l'en-tête d'application.

Une politique de démarrage qui fonctionne pour la plupart des sites

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com;
  style-src  'self' 'unsafe-inline' https://fonts.googleapis.com;
  font-src   'self' https://fonts.gstatic.com;
  img-src    'self' data: https:;
  connect-src 'self' https://www.google-analytics.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  upgrade-insecure-requests

Cette politique suppose que tu sers tout depuis ton propre domaine plus Google Analytics + Google Fonts. Presque tous les sites WordPress, Shopify ou statiques rentrent dedans avec de petits ajustements. Remplace ou supprime les lignes GA/Fonts si tu ne les utilises pas.

Comment déployer sur nginx

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests" always;

Comment déployer sur Apache

Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests"

Comment déployer sur Cloudflare

Dans ton tableau de bord Cloudflare, va dans Règles → Règles de transformation → Modification d'en-tête de réponse HTTP. Ajoute un en-tête nommé Content-Security-Policy-Report-Only avec la politique ci-dessus comme valeur. C'est l'option la plus rapide si tu n'as pas d'accès shell à ton serveur.

Comment déployer sur WordPress

Installe un plugin d'en-têtes comme Headers Security Advanced & HSTS WP ou ajoute les en-têtes via ton panneau d'hébergement. Évite de définir le CSP dans le functions.php d'un thème — beaucoup de thèmes chargent des assets WordPress-admin ou de l'éditeur de blocs dynamiquement, ce qui casse l'expérience de l'éditeur.

Les pièges courants

• Scripts en ligne. Si ton CMS (système de gestion de contenu) injecte des balises <script> en ligne, tu verras des violations. Le correctif : soit des nonces (le mieux), soit, comme mesure temporaire, script-src 'self' 'unsafe-inline' — mais prévois de supprimer 'unsafe-inline' en un sprint.
• Google Tag Manager. GTM charge d'autres scripts au moment de l'exécution depuis des hôtes tiers. Soit tu pré-déclares ces hôtes dans ta politique, soit tu utilises les Custom Templates intégrés de GTM avec une stratégie de nonce.
• YouTube / Vimeo embarqués. Ajoute frame-src https://www.youtube.com https://player.vimeo.com.
• Point de rapport. Ajoute report-uri /csp-report ou report-to pour capturer les violations côté serveur. Certains hébergeurs (Cloudflare, Sentry) offrent des points de rapport CSP gratuits.

Du mode report-only à l'application

Après une semaine de report-only sans nouvelles violations sur le trafic réel, renomme l'en-tête de Content-Security-Policy-Report-Only en Content-Security-Policy. La politique est maintenant appliquée. Garde le point de rapport — tu détecteras les nouvelles violations dès qu'une mise à jour de plugin introduit un script inattendu.

Comment Scanthra détecte ça

Notre module Security Headers fait un seul GET sur ta page d'accueil et lit les en-têtes de réponse. Si Content-Security-Policy est manquant, faible, ou contient unsafe-eval, tu recevras un problème détecté avec sa gravité, une description en langage clair et un correctif à copier-coller — même format que dans cet article.