L'équipe sécurité clôture un audit avec une recommandation claire : déployer une Content Security Policy stricte. Le développeur ajoute le header en production un vendredi après-midi. Vingt minutes plus tard, le checkout Stripe ne charge plus, Google Tag Manager est muet, et le back-office admin affiche une page blanche. Rollback du header, post-mortem tendu, promesse de « reprendre plus tard » — qui devient jamais.
Une CSP bien menée n'est pas un interrupteur. C'est une liste blanche exécutable : le navigateur n'exécute que ce que vous autorisez explicitement pour les scripts, styles, images, connexions XHR et iframes. Chaque pixel marketing, chaque bundle webpack, chaque iframe de paiement compte — y compris celui que personne n'a inventorié depuis la dernière campagne.
La bonne montée se fait en report-only, avec le marketing dans la boucle, un pipeline de nonce côté build, et un test checkout complet avant le passage en enforce. Sans ça, vous punissez le panier, pas l'attaquant XSS.
Déploiement en quatre phases
Phase 1 — inventaire : listez tous les scripts et styles, y compris ceux injectés par Tag Manager, A/B testing, chat support, heatmaps. Exportez les violations depuis le navigateur (onglet Réseau + console) sur les parcours critiques : accueil, inscription, checkout, admin.
Phase 2 — Report-Only deux à quatre semaines : header Content-Security-Policy-Report-Only avec endpoint /csp-report ou service tiers. Collectez, agréguez par directive violée, triez : script-src d'abord, puis connect-src, frame-src, img-src.
Phase 3 — corrections : nonce par requête pour inline légitime, hash SHA-256 pour snippets statiques, refactor vers fichiers externes pour le reste. Chaque nouveau domaine marketing passe par un ticket CSP avant mise en prod du tag.
Phase 4 — enforce avec monitoring : basculez vers Content-Security-Policy quand les violations critiques tendent vers zéro sept jours consécutifs. Prévoyez rollback header documenté (feature flag ou config nginx) et test E2E checkout en staging enforce avant prod.
Directives et pièges fréquents
| Directive | Rôle | Piège courant |
|---|---|---|
default-src | Fallback | Trop permissif masque des trous sur script-src |
script-src | JavaScript | Oublier js.stripe.com ou GTM |
style-src | CSS | Inline React/Vue sans nonce |
connect-src | fetch/XHR | API paiement ou analytics oubliée |
frame-src | iframes | 3-D Secure Stripe bloqué |
img-src | Images | Pixels tracking sur domaine inconnu |
'strict-dynamic' avec nonce modernise la chaîne de confiance : un script nonce peut charger des descendants — testez Safari et Firefox cibles, pas seulement Chrome.
unsafe-inline et unsafe-eval ne sont acceptables qu'en transition courte et documentée. Chaque occurrence doit avoir une date de retrait.
Pipeline nonce et build
Le framework génère un nonce par requête (session ou middleware). Le template injecte <script nonce="{{nonce}}">. L'outil de build préserve le placeholder — minification ne doit pas le casser.
Pour du contenu inline immuable (snippet analytics legacy), calculez le hash SHA-256 et déclarez 'sha256-…' dans script-src. Documentez la commande de génération dans le README d'exploitation.
CI staging : test automatisé que le header CSP est présent et que la page checkout charge sans violation console. Bloquez le merge si régression.
Tiers : Stripe, GTM, analytics
Stripe exige typiquement script-src js.stripe.com, frame-src hooks.stripe.com, connect-src api.stripe.com. Listez-les explicitement — ne comptez pas sur default-src seul.
Google Tag Manager propage des domaines variables : imposez un processus « nouveau tag = revue CSP » avec SLA 48 h. Sinon, la campagne du lundi casse le mardi.
Après chaque changement de header, exécutez un parcours checkout complet avec carte test, 3-D Secure si activé, et confirmation webhook côté serveur.
Gouvernance et reporting
Nommez un CSP owner dans la matrice RACI sécurité — pas un comité vague. Il participe aux releases marketing tags.
Agrégation hebdomadaire des rapports report-only : volume par directive, nouveaux domaines, pages affectées. Spike post-deploy = rollback ou hotfix, pas silence.
RGPD : les rapports CSP peuvent contenir des URLs avec paramètres — filtrez ou anonymisez avant stockage long terme.
Décider et avancer sans angle mort
- Inventaire scripts et styles — build, inline, Tag Manager, Stripe ; owner CSP nommé dans le RACI.
- Report-Only 2–4 semaines — endpoint
/csp-reportrate limited, triage hebdo script-src. - Pipeline nonce ou hash CI — staging enforce avant prod ; test checkout et admin WordPress.
- Formulaire marketing nouvelle tag — domaines script/connect/frame revus 48 h avant publish.
- Scorecard enforce — zéro violation critique 7 jours, rollback header documenté.
Front et CDN : vérifiez headers via curl -I ; comparez hébergeurs via l'annuaire et le comparateur.
Questions fréquentes
CSP bloque quoi exactement ?
Elle limite les sources exécutables (scripts, styles, connexions, frames) pour réduire l'impact d'une injection XSS. Le navigateur refuse ce qui n'est pas whitelisté — y compris un pixel marketing oublié.
Report-Only suffit-il longtemps ?
Non : c'est la phase d'inventaire (2–4 semaines minimum). Les violations doivent tendre vers zéro sur les parcours critiques avant enforce en production.
Comment gérer les scripts inline ?
Trois voies : nonce unique par requête injecté par le framework, hash SHA-256 du contenu statique, ou refactor vers fichiers externes. unsafe-inline n'est acceptable qu'en transition courte.
Stripe et Tag Manager coexistent-ils avec CSP ?
Oui, avec script-src et connect-src listant js.stripe.com, les domaines GTM et les API de paiement. Testez le checkout complet après chaque changement de header.
Lisez deux semaines de rapports CSP avant d'interdire — les surprises viennent du marketing, pas du backend.