Générateur CSP : une politique de sécurité du contenu sans migraine

La Content Security Policy (CSP) est l'un des outils de sécurité web les plus efficaces contre les attaques XSS — et l'un des en-têtes HTTP les plus pénibles à configurer. Une faute de frappe dans un nom de directive ne génère aucun message d'erreur. Une directive oubliée peut laisser une faille de sécurité béante ou faire planter complètement la production.

Ce guide explique le fonctionnement de la CSP, les directives essentielles, les erreurs que presque tout le monde commet, et comment le générateur CSP simplifie considérablement tout ce processus.

Pourquoi la CSP est indispensable

XSS (Cross-Site Scripting) figure depuis des années parmi les vulnérabilités web les plus dangereuses. Un attaquant injecte du JavaScript malveillant dans une page web — via des champs de saisie, des paramètres URL ou du contenu tiers mal géré. Les conséquences peuvent être sévères :

Vol de tokens de session et de cookies
Actions effectuées au nom de l'utilisateur
Insertion de faux formulaires de connexion (phishing dans le contexte de la page)
Lecture de données sensibles affichées sur la page

La validation des entrées est la première ligne de défense. Mais les applications réelles sont complexes : éditeurs rich text, intégrations tierces, code legacy... La CSP constitue la deuxième ligne de défense — même si une injection réussit, elle empêche l'exécution du script malveillant.

La structure d'un header CSP

La CSP est envoyée comme en-tête HTTP de réponse :

Content-Security-Policy: directive1 valeur1 valeur2; directive2 valeur1; ...

Exemple concret :

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' data: https:;

Chaque directive est séparée par un point-virgule. Après le nom de la directive viennent les sources autorisées, séparées par des espaces.

Les directives CSP essentielles

default-src : le filet de sécurité

Tout ce qui n'est pas couvert par une directive plus spécifique tombe sous default-src :

default-src 'self';

'self' autorise uniquement les ressources du même origine (même protocole, domaine et port).

script-src : la directive la plus critique

Contrôle d'où le JavaScript peut être chargé :

script-src 'self' https://cdn.jsdelivr.net https://www.googletagmanager.com;

Valeurs sources fréquentes :

'self' — Même origine uniquement
'none' — Aucun script autorisé
'nonce-{valeur_aléatoire}' — Scripts inline avec l'attribut nonce correspondant
'strict-dynamic' — Les scripts de confiance peuvent charger d'autres scripts
https://example.com — Origine explicitement autorisée

À éviter absolument en production : 'unsafe-inline' et 'unsafe-eval'. Ces valeurs annulent l'essentiel de la protection XSS.

style-src : contrôle des feuilles de style

style-src 'self' https://fonts.googleapis.com;

img-src : contrôle des images

img-src 'self' data: https:;

data: autorise les images inline en base64. https: autorise toutes les images externes via HTTPS.

font-src : contrôle des polices

font-src 'self' https://fonts.gstatic.com;

connect-src : contrôle des connexions réseau

Contrôle les destinations pour fetch(), XMLHttpRequest, WebSockets :

connect-src 'self' https://api.example.com wss://ws.example.com;

frame-src : contrôle des iframes

frame-src 'none';                    /* Iframes interdits */
frame-src https://www.youtube.com;  /* Seulement YouTube */

form-action : contrôle les destinations des formulaires

form-action 'self';

base-uri : restreint la balise base

Empêche un attaquant d'insérer une balise <base> pour détourner les URL relatives :

base-uri 'self';

frame-ancestors : qui peut intégrer la page ?

Remplace l'en-tête obsolète X-Frame-Options :

frame-ancestors 'none';   /* La page ne peut pas être intégrée dans un iframe */
frame-ancestors 'self';   /* Seulement le même origine */

upgrade-insecure-requests : forcer HTTPS

upgrade-insecure-requests;

Toutes les requêtes HTTP sont automatiquement promues en HTTPS.

Les erreurs classiques

Erreur 1 : recourir à unsafe-inline par facilité

Les scripts inline ne fonctionnent pas, alors on ajoute 'unsafe-inline'. Résultat : script-src ne protège plus pratiquement rien contre XSS.

La bonne solution : les nonces. Le serveur génère une valeur aléatoire à chaque requête, présente à la fois dans le header CSP et comme attribut nonce sur les balises script autorisées :

<script nonce="xK4mR9pL2qW8">
  // Ce script est autorisé — son nonce correspond
</script>

Header CSP :

script-src 'self' 'nonce-xK4mR9pL2qW8';

Comme le nonce change à chaque requête, l'attaquant ne peut pas le deviner et ne peut pas l'exploiter.

Erreur 2 : oublier les scripts tiers

Google Analytics, Stripe, Intercom, Hotjar et bien d'autres chargent leurs scripts depuis leurs propres CDN — leurs origines doivent être dans script-src :

script-src 'self'
  https://www.googletagmanager.com
  https://www.google-analytics.com
  https://js.stripe.com;

Avant de déployer, vérifiez la console du navigateur (onglets "Réseau" et "Console") pour détecter les ressources bloquées.

Erreur 3 : oublier que connect-src et img-src nécessitent aussi des ajustements

Google Analytics ne nécessite pas seulement script-src, mais également :

img-src     'self' https://www.google-analytics.com data:;
connect-src 'self' https://www.google-analytics.com;

Erreur 4 : déployer en production sans test préalable

Pousser une CSP en production sans test peut casser des fonctionnalités critiques. Un script qui ne charge plus, une police qui disparaît, une requête API bloquée.

Le mode report-only : tester sans risque

Utilisez Content-Security-Policy-Report-Only pour un test sécurisé en production :

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

Cet en-tête :

Ne bloque aucune ressource (le site fonctionne normalement)
Signale toutes les violations à l'endpoint report-uri
Permet de tester avec le vrai trafic de production

Le rapport de violation est envoyé en JSON :

{
  "csp-report": {
    "document-uri": "https://example.com/page",
    "violated-directive": "script-src-elem",
    "blocked-uri": "https://service-externe.com/script.js",
    "original-policy": "default-src 'self'; script-src 'self'"
  }
}

Utilisez ces rapports pour enrichir progressivement la liste blanche, jusqu'à ce que les faux positifs disparaissent — puis basculez sur le vrai header Content-Security-Policy.

Exemples de configurations pratiques

Site statique simple

Content-Security-Policy:
  default-src 'self';
  img-src 'self' data:;
  style-src 'self';
  font-src 'self';
  form-action 'self';
  base-uri 'self';
  frame-ancestors 'none';

Site marketing avec Google Analytics

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com;
  style-src 'self' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' https://www.google-analytics.com data:;
  connect-src 'self' https://www.google-analytics.com;
  form-action 'self';
  base-uri 'self';

Application SaaS avec Stripe

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://js.stripe.com;
  style-src 'self' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https:;
  connect-src 'self' https://api.stripe.com https://api.votreapp.com;
  frame-src https://js.stripe.com;
  form-action 'self';
  base-uri 'self';
  upgrade-insecure-requests;

SPA avec nonces

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{nonce_généré_par_le_serveur}' 'strict-dynamic';
  style-src 'self' 'nonce-{nonce_généré_par_le_serveur}';
  img-src 'self' data: blob:;
  connect-src 'self' https://api.votreapp.com;
  font-src 'self';
  form-action 'self';
  base-uri 'self';
  upgrade-insecure-requests;

CSP via balise meta

Sans accès aux en-têtes HTTP (hébergement statique pur) :

<head>
  <!-- Placer le plus tôt possible dans le head -->
  <meta http-equiv="Content-Security-Policy"
        content="default-src 'self'; script-src 'self'; style-src 'self'">
</head>

Limites de la balise meta :

frame-ancestors non supporté
report-uri non supporté
Protection légèrement retardée par rapport aux headers HTTP

Les headers HTTP restent préférables quand vous en avez le contrôle.

Workflow recommandé pour l'adoption

Démarrer en mode report-only — Collecte de données, aucun blocage
Observer les violations en production — Quelques jours de trafic réel suffisent
Affiner la liste blanche — Ajouter les sources légitimes, identifier les vraies menaces
Passer au header CSP effectif — Une fois la liste blanche stabilisée
Surveiller en continu — Les nouvelles fonctionnalités peuvent introduire de nouvelles violations

Pourquoi utiliser un générateur ?

Écrire un header CSP à la main présente plusieurs pièges :

Les fautes de frappe dans les noms de directive sont silencieuses
La syntaxe exacte (quand les valeurs ont-elles besoin de guillemets ?) est source d'erreurs
Gérer plusieurs services tiers dans une liste blanche devient vite fastidieux
Alterner entre mode report-only et mode appliqué est source de confusion

Le générateur CSP résout ces problèmes :

Interface visuelle pour chaque directive
Syntaxe automatiquement correcte (guillemets, points-virgules, espaces)
Profils préconfigurés pour les services courants (Google Analytics, Stripe, etc.)
Header complet prêt à copier-coller dans la configuration serveur

Récapitulatif

La CSP est une couche de sécurité essentielle pour les applications web modernes. Les points clés :

Éviter 'unsafe-inline' et 'unsafe-eval' en production — les nonces sont la bonne alternative
Tester avec le mode report-only avant d'appliquer la CSP
Les scripts tiers nécessitent des entrées dans script-src, connect-src et souvent img-src
base-uri 'self' et form-action 'self' protègent contre d'autres vecteurs d'attaque
frame-ancestors 'none' remplace X-Frame-Options
Surveiller les violations en continu

Ouvrez le générateur CSP, configurez vos directives via l'interface et copiez le header généré dans votre configuration serveur — c'est plus rapide et plus fiable que de l'écrire à la main.