Comment tester une CSP sur un site en production sans rien déployer
Trois façons de tester une CSP sans toucher à la production : réécrire la CSP du site dans son navigateur avec une extension Chrome gratuite, noter la politique avec un évaluateur gratuit, ou passer par le report-only. Itération en 5 secondes au lieu d’un cycle de déploiement.
La méthode standard pour tester un changement de CSP ressemble à ceci : modifier la config de l’en-tête, ouvrir une pull request, attendre la CI, déployer en staging, cliquer partout, découvrir ce qu’on a oublié, recommencer. Chaque itération coûte entre dix minutes et une demi-journée selon le pipeline. Or une CSP demande des dizaines d’itérations. Faites la multiplication et vous comprenez pourquoi tant de politiques partent en production à moitié finies.
Cette boucle peut sauter entièrement. L’extension Chrome CentralCSP est gratuite, sans compte, et son mode Rewrite remplace la CSP réellement servie par un site par votre politique candidate, uniquement dans votre navigateur. Vous parcourez les vraies pages de production, zones connectées comprises, et vous voyez exactement ce que votre politique casserait, en 5 secondes par itération au lieu d’un cycle de déploiement. Ajoutez l’évaluateur gratuit pour noter la politique avant sa mise en ligne, puis confirmez avec un en-tête report-only sur du trafic réel.
Voici les trois options en détail, dans l’ordre où nous les utilisons.
Réécrire la CSP du site dans son propre navigateur
L’extension (présentée sur le site principal) fonctionne entièrement en local. Pas de compte, pas de télémétrie, rien ne quitte votre machine. Elle affiche une note de 5.0 sur le Chrome Web Store, ce qui pour un outil de sécurité signifie surtout qu’elle fait ce qu’elle annonce et rien d’autre. Trois modes :
Observe affiche en direct les violations de la page courante. Ouvrez votre site, ouvrez l’extension et regardez quelles directives se déclenchent contre la politique déjà en place. Rien que ça répond à « que bloque ma CSP actuelle » plus vite que de fouiller le bruit de la console DevTools.
Rewrite est le mode qui tue la boucle de déploiement. Vous collez une politique candidate et l’extension la substitue à la vraie CSP du site, en enforce ou en report-only, pour votre session seulement. Rechargez la page : vous naviguez en production sous une politique qui n’est pas encore déployée. Connectez-vous, passez une commande, ouvrez le back-office. Toute page que vous pouvez atteindre, vous pouvez la tester. Modifiez la politique, rechargez, regardez. L’itération, c’est ça.
Build va un cran plus loin et assemble la politique pour vous. Il applique une base report-only stricte et collecte ce qui casse pendant que vous naviguez : votre tour du site devient un brouillon de politique.
La limite est évidente : vous testez ce que vous parcourez, dans votre navigateur. L’iPad de quatre ans de votre collègue n’est pas couvert. On y revient plus bas.
Noter la politique avant sa mise en ligne
L’évaluateur est le second outil gratuit, sans compte lui aussi. Collez une politique (ou pointez le scanner vers une URL) et vous obtenez deux scores de 0 à 100, sécurité et qualité, plus des constats classés par sévérité, chacun avec sa correction. Au-dessus de 80, c’est solide. Sous 50, il manque des choses.
Les constats sont la partie utile. Il attrape les directives dangereuses, les fautes de frappe (un script-scr passera votre test navigateur en silence, une directive inconnue étant simplement ignorée) et les contournements JSONP. Une politique parfaite dans l’extension peut très bien avoir un mauvais score ici, en général parce qu’elle est assez permissive pour ne jamais rien casser. Ne rien casser n’est pas l’objectif.
Passer en report-only sur le staging
L’option classique garde sa place. Servez la candidate en en-tête Content-Security-Policy-Report-Only sur le staging (ou en production) : le navigateur signale ce qui aurait été bloqué sans rien bloquer, donc impossible de faire tomber le paiement. Cela exige un déploiement, précisément ce qu’on cherche à éviter pendant l’itération, mais c’est la seule méthode qui teste du trafic que vous n’avez pas généré vous-même.
Nous avons traité à part la durée à passer en report-only avant d’appliquer et la migration du report-only vers l’enforce.
Le workflow qui assemble les trois
- Prototyper dans l’extension. Rédigez la politique en mode Rewrite face à la production, ou laissez le mode Build en produire un brouillon. Itérez jusqu’à ce que vos propres sessions soient propres. C’est ici que se jouent les dizaines d’itérations à bas coût.
- La noter dans l’évaluateur. Corrigez ce qu’il signale avant que quiconque d’autre ne voie la politique. Cinq minutes, et il attrape les erreurs que la navigation ne peut pas voir.
- Confirmer sur du trafic réel. Déployez la politique en report-only, pointée vers l’endpoint de reporting managé de CentralCSP et laissez 1 à 4 semaines d’utilisateurs réels exercer les navigateurs, les langues et les pages oubliées que vous n’avez jamais touchés. Quand les violations inexpliquées tombent à zéro, appliquez.
Tout est gratuit et sans compte jusqu’à cette dernière étape. Elle seule réclame un collecteur de rapports, parce que le trafic réel produit du volume réel, et c’est là que la plateforme justifie son existence.
Questions fréquentes
Peut-on tester une CSP sur un site en production sans la déployer ?
Oui. Le mode Rewrite de l’extension Chrome CentralCSP remplace la CSP réellement servie par le site par une politique candidate de votre choix, uniquement dans votre navigateur. Vous naviguez sur le vrai site de production, connecté si besoin, et vous voyez ce que votre politique bloquerait. Rien ne change côté serveur et aucun autre visiteur n’est affecté. L’extension est gratuite et ne demande aucun compte.
Comment tester une CSP sur des pages qui exigent une connexion ?
En testant dans votre propre session de navigateur plutôt qu’avec un scanner externe. Une extension qui réécrit l’en-tête CSP localement, comme celle de CentralCSP, applique votre politique candidate à la page où vous êtes, y compris les tableaux de bord authentifiés, les tunnels de paiement et les back-offices qu’un crawler ne verra jamais.
Existe-t-il un outil gratuit pour vérifier une CSP avant de la mettre en ligne ?
CentralCSP propose un évaluateur gratuit, sans compte : collez une politique et obtenez deux scores de 0 à 100, un pour la sécurité et un pour la qualité, ainsi que des constats classés par sévérité, chacun accompagné de sa correction. Il détecte les directives dangereuses, les fautes de frappe et les contournements JSONP avant qu’un navigateur n’ait à le faire.
Tester dans une extension navigateur suffit-il avant de passer en mode enforce ?
Non. Une personne qui navigue couvre un navigateur, une langue et les pages auxquelles elle a pensé. Avant d’appliquer la politique, faites-la tourner en report-only sur du trafic réel pendant 1 à 4 semaines, le temps que les navigateurs exotiques, les campagnes marketing et les pages oubliées se manifestent. L’extension raccourcit l’itération, le report-only valide la couverture.