Comment utiliser le CSP Builder

Écrire une politique de sécurité du contenu (CSP) à la main est lent et facile à rater. Vous listez chaque source de script, de style, de police et d'image que la page charge, vous en oubliez quelques-unes, et soit vous cassez le site, soit vous laissez un trou. Le CSP Builder prend une autre voie. Il lit les reports de violation que votre site envoie déjà et les transforme en une politique qui couvre ce que vos pages chargent réellement.

Cet article parcourt le Builder de bout en bout : choisir une politique de départ, choisir combien de données de reports analyser, générer la politique, revoir chaque source, et déployer. Vous obtenez un header prêt à déployer au lieu d'un fichier vide et d'un long après-midi.

Si la CSP vous est nouvelle, lisez d'abord démarrer avec la Content Security Policy, puis revenez ici pour générer votre première vraie politique.

Ce que fait le CSP Builder

Le CSP Builder est un outil à l'intérieur du dashboard CentralCSP, donc vous le lancez contre les données de reports de votre compte plutôt que d'installer quoi que ce soit.

Une Content Security Policy est un header de réponse HTTP qui indique au navigateur depuis quelles sources une page peut charger scripts, styles, images et autres ressources. Le navigateur l'applique ; tout ce qui n'est pas autorisé est bloqué et signalé.

Le Builder travaille à partir de ces reports. Quand votre site envoie des reports de violation à un endpoint de reporting, chaque ressource bloquée ou qui aurait été bloquée est enregistrée avec sa directive et sa source. Le Builder lit cet historique et assemble une politique qui autorise les sources que votre application utilise légitimement, avec des valeurs par défaut sûres appliquées au reste. Vous revoyez le résultat avant que quoi que ce soit ne soit déployé.

Il n'impose ni ne proxie le trafic. Il produit un header ; vous déployez ce header sur votre serveur, et le navigateur fait l'application.

Avant de commencer

Il vous faut des données de reports pour que le Builder apprenne. Deux choses doivent être en place :

Un endpoint de reporting. Votre site envoie les reports CSP à un endpoint CentralCSP de la forme https://<Endpoint-ID>.report.centralcsp.com. Voyez démarrer avec le reporting CSP pour la configuration.
Un peu d'historique de reports. Plus les reports couvrent de trafic, plus la politique générée est complète. Une fenêtre plus longue attrape les ressources qui ne se chargent que sur des pages rarement visitées, alors laissez les reports s'accumuler sur un cycle de trafic complet avant de générer.

Lancez votre première politique en mode Report-Only pour rassembler des reports sans rien bloquer. Report-Only envoie les mêmes reports de violation qu'une politique imposée, donc le Builder obtient de vraies données pendant que votre site continue de fonctionner.

Étape 1. Choisissez une politique de départ

Le Builder part d'une politique de base et l'affine. Vous pouvez le laisser détecter la politique que votre site sert déjà, partir d'un modèle de départ CSP strict, ou coller une politique personnalisée.

Un point de départ courant est une base stricte qui refuse tout par défaut et n'ouvre que ce que les reports prouvent nécessaire :

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' 'report-sample';
  style-src 'self';
  img-src 'self';
  font-src 'self';
  object-src 'none';
  base-uri 'none';
  form-action 'self';
  frame-ancestors 'none';
  report-uri https://<Endpoint-ID>.report.centralcsp.com

Ici default-src fixe le repli, object-src et base-uri verrouillent une surface d'attaque héritée, et frame-ancestors bloque le clickjacking. Le mot-clé 'report-sample' dit au navigateur d'inclure un extrait du contenu bloqué dans chaque report, ce qui vous aide à distinguer le code légitime du code injecté.

Étape 2. Choisissez une fenêtre de reporting

Ensuite, choisissez la plage temporelle des reports que le Builder doit analyser. Une fenêtre plus longue couvre davantage du comportement de votre site, y compris les pages et parcours qui ne tournent qu'occasionnellement. Une fenêtre plus courte reflète seulement le trafic récent.

Le Builder lit les reports de violation de cette fenêtre, les regroupe par directive, et détermine quelles sources vos pages ont réellement demandées. C'est là qu'il apprend que vos scripts viennent de votre propre origine plus un host d'analytics précis, vos polices d'un CDN, et ainsi de suite.

Étape 3. Générez et revoyez la politique

Le Builder assemble une politique à partir des reports analysés. Il ajoute les sources dont votre application a besoin par directive et applique des valeurs par défaut sûres aux directives qui n'ont eu aucun trafic légitime.

Une politique générée pour un site typique ressemble à ceci, une directive par ligne :

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'strict-dynamic' 'nonce-r4nd0m' https://cdn.example.com;
  style-src 'self' https://fonts.googleapis.com;
  img-src 'self' data: https://*.example.com;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.example.com;
  object-src 'none';
  base-uri 'none';
  form-action 'self';
  frame-ancestors 'none';
  upgrade-insecure-requests;
  report-uri https://<Endpoint-ID>.report.centralcsp.com

Quelques points à remarquer dans un header généré :

script-src porte l'approche moderne : un nonce par requête plus 'strict-dynamic', pour que les scripts de confiance puissent charger les scripts dont ils ont besoin sans que vous listiez chaque host. Voyez comment fonctionne 'strict-dynamic' pour le mot-clé, et les nonces CSP dans Next.js pour câbler les nonces dans le code applicatif.
connect-src, font-src et img-src listent les vrais hosts vus dans vos reports, rien de plus.
upgrade-insecure-requests pousse toute sous-ressource en HTTP simple vers HTTPS.

Si vos reports montrent des styles ou scripts inline, le Builder les fait remonter pour que vous décidiez entre un nonce, un hash, ou refactoriser le code inline. Évitez de recourir à 'unsafe-inline' ; pourquoi unsafe-inline affaiblit votre CSP explique le coût.

Étape 4. Revoyez chaque source

La génération n'est pas le dernier mot. Le Builder vous guide dans la politique directive par directive pour que vous approuviez ce qui y entre. C'est l'étape qui garde un host égaré hors de votre script-src.

Pour chaque source, vérifiez qu'elle a sa place. Un host que vous reconnaissez (votre CDN, votre fournisseur d'analytics) est à garder. Un host que vous ne reconnaissez pas mérite une investigation avant que vous l'autorisiez, car le report peut refléter une ressource injectée ou tierce que vous ne voulez pas permettre. Revoir les tags tiers est une tâche en soi ; CSP pour Google Analytics et Tag Manager couvre les plus courants.

Gardez la politique en Report-Only pendant votre revue. Le navigateur signale contre la nouvelle politique sans l'imposer, pour que vous confirmiez qu'elle couvre le trafic réel avant qu'elle ne puisse casser quoi que ce soit.

Étape 5. Déployez la politique

Quand la politique semble bonne, copiez le header et définissez-le sur votre serveur. La syntaxe exacte dépend de votre stack, et comment définir le header CSP dans chaque framework couvre chacun ; voici nginx en exemple :

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-r4nd0m' https://cdn.example.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' data: https://*.example.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests; report-uri https://<Endpoint-ID>.report.centralcsp.com" always;

Basculez de Content-Security-Policy-Report-Only vers Content-Security-Policy seulement quand vous êtes confiant. Les deux headers peuvent tourner côte à côte : imposez la politique en laquelle vous avez confiance sur Content-Security-Policy pendant que vous testez la prochaine itération sur le header Report-Only.

Après avoir imposé, gardez l'endpoint de reporting actif. Du nouveau code et de nouveaux tiers feront surface sous forme de nouveaux reports, et vous relancez le Builder pour les intégrer.

Validez avant et après le déploiement

Deux outils gratuits vous aident à vérifier la politique sans la déployer d'abord :

L'évaluateur CSP note une politique et signale les points faibles, comme un script-src trop large ou un object-src manquant.
Le scanner CSP lit le header en direct sur une URL pour que vous confirmiez ce que la production sert réellement.

Passez la politique dans l'évaluateur avant de l'imposer, et scannez le site en direct après, pour savoir que le header déployé correspond à ce que vous avez approuvé.

De la politique générée à la surveillance continue

Une politique n'est pas une tâche ponctuelle. Les sites changent, les dépendances se mettent à jour, et de nouveaux scripts tiers apparaissent. Les mêmes reports qui ont alimenté le Builder continuent d'affluer, donc vous voyez les violations à mesure qu'elles se produisent et vous régénérez quand votre stack évolue.

Pour les pages de paiement, cette visibilité continue est aussi une preuve. La surveillance continue des scripts et des headers vous aide à respecter les exigences 6.4.3 et 11.6.1 de PCI DSS v4, où vous devez gérer et détecter les changements des scripts sur les pages de paiement. CentralCSP enregistre cet historique ; un QSA valide la conformité, pas nous.

Prêt à générer une politique à partir de vos propres reports ? Commencez gratuitement et pointez votre site vers un endpoint de reporting, puis lancez le Builder contre du trafic réel.