Combien de temps rester en CSP report-only avant de passer en mode bloquant ?

Tous les guides de déploiement CSP s’accordent sur la séquence : publier Content-Security-Policy-Report-Only, observer les rapports de violation, puis basculer la politique dans l’en-tête bloquant. Ce que les guides précisent rarement, c’est quand arrêter d’observer.

La réponse honnête : 1 à 4 semaines de trafic représentatif. Et « représentatif » pèse plus lourd que le chiffre. La fenêtre doit contenir au moins un cycle de déploiement complet, du trafic de semaine et de week-end, les campagnes marketing et tests A/B en cours, et assez de volume pour que la longue traîne des navigateurs apparaisse. Quand les critères ci-dessous sont remplis, bloquez, que cela ait pris neuf jours ou trente. Ce n’est pas le calendrier qui décide, c’est la couverture.

Débutant sur le sujet ? Commencez par ce qu’est une Content Security Policy, puis revenez.

Pourquoi « représentatif » compte plus que le nombre de jours

Un mardi calme ne prouve rien. Il vous apprend ce que votre site charge un mardi calme.

Ce que la fenêtre doit attraper :

• Votre cadence de déploiement. Une fenêtre de cinq jours peut rater une release entière, et c’est à la release que les nouveaux scripts apparaissent. Visez un cycle complet, idéalement deux.
• L’écart semaine/week-end. Le trafic du samedi penche souvent grand public : autres appareils, navigateurs plus vieux, autres pages. Les sites B2B vivent l’inverse.
• Campagnes et tests A/B. Une landing page marketing embarque des pixels de tracking et des conteneurs de tag manager qui ne se déclenchent que pour certains paramètres UTM. Avec un test A/B, la moitié de vos utilisateurs charge des scripts que l’autre moitié ne verra jamais. Si une campagne démarre la semaine suivant le passage en bloquant, ses scripts sont bloqués dès le premier jour.
• La longue traîne des navigateurs. Chrome sur desktop se montre dans la première heure. Le Safari d’un iPad de quatre ans, en deuxième semaine.

Comment savoir si vous avez collecté assez ?

Trois signaux, et il faut les trois.

Le taux de nouvelles violations est à plat. Pas le volume brut de rapports, qui suit simplement le trafic : comptez les paires directive-origine distinctes par jour. La courbe grimpe vite les premiers jours, s’infléchit, puis s’aplatit. Plusieurs jours consécutifs sans rien de nouveau, et la découverte a convergé.

Chaque violation restante est expliquée. Trois cases possibles : corrigée (le gestionnaire inline est devenu un fichier externe, le script a reçu un nonce), autorisée (l’origine a été ajoutée volontairement à la politique), ou bruit (les scripts injectés par les extensions de navigateur, qui ne sont pas votre code). Zéro violation n’est pas atteignable. Zéro violation inexpliquée l’est.

Chaque type de page a été exercé. Checkout, réinitialisation de mot de passe, pages d’erreur, panneau d’administration que personne ne visite. Les rapports portent l’URL du document, donc cela se vérifie : groupez par page et cherchez les silences. Une page sans aucun rapport n’a peut-être simplement jamais été visitée pendant la fenêtre. Allez cliquer dessus vous-même avant de conclure.

Les pièges de l’arrêt trop précoce

Certaines choses ne se montrent qu’à leur propre rythme, et ce sont les incidents post-enforcement classiques.

Le batch mensuel. La page de facturation qui ne s’affiche que le 1er du mois, l’export de paie. Une fenêtre de trois semaines qui rate le 1er les rate entièrement.

Les pages saisonnières. Les bannières de soldes, les landing pages de fin d’année, le widget de compte à rebours que quelqu’un ressuscite chaque novembre. S’il ne s’est pas affiché pendant votre fenêtre, ses scripts ne sont pas dans votre politique.

Le contenu géo-spécifique. Les scripts de consentement varient par pays. Un prestataire de paiement chargé sur un seul marché ne remonte des rapports que depuis ce marché. Si 95 % de votre trafic de découverte est domestique, votre checkout brésilien reste inexploré.

Inutile d’attendre tous ces cas, mais décidez consciemment : allonger la fenêtre, ou bloquer quand même et surveiller les rapports de près au prochain déclenchement du batch. Ce qui n’est pas permis, c’est d’être surpris.

Le piège de ne jamais s’arrêter

L’échec inverse est plus fréquent, et plus silencieux. Nous avons vu des équipes collecter des rapports pendant plus d’un an sans jamais bloquer. Le report-only donne une impression de travail : le tableau de bord se remplit, les tickets se ferment. Pendant ce temps, une politique qui ne bloque rien ne protège rien.

Si votre équipe est en report-only depuis plus de deux mois, le blocage est rarement un problème de données. Nommez le vrai obstacle, corrigez-le et mettez une date dans le sprint.

Une semaine, est-ce assez ? Cela dépend du site

Le générateur de politique de Report URI est conçu autour d’environ sept jours de trafic collecté (documentation publiée, août 2026). Une semaine fixe, c’est un pari : celui que tout le comportement de votre site se montre en sept jours. Vrai pour certains sites à fort trafic, silencieusement faux pour tous ceux dont le batch mensuel de facturation, les pages saisonnières ou le rythme de déploiement lent tombent hors de la fenêtre.

Le chiffre cesse de fonctionner sur les sites calmes. Un outil interne à 40 utilisateurs met des semaines à accumuler la couverture qu’un commerçant voit en une journée. Le Builder de CentralCSP accepte n’importe quelle fenêtre de 1 à 90 jours exactement pour cette raison : la rétention est de 90 jours sur tous les paliers, alors un site calme laisse les rapports s’accumuler jusqu’au vrai plateau, puis construit la politique sur la fenêtre complète.

La checklist pour passer en mode bloquant

• Aucune nouvelle paire directive-origine distincte pendant 5 à 7 jours consécutifs, week-end compris.
• Au moins un cycle de déploiement complet dans la fenêtre.
• Chaque violation ouverte est corrigée, autorisée, ou étiquetée bruit d’extension.
• Chaque type de page remonte des rapports, ou quelqu’un l’a exercé à la main.
• Les jobs périodiques connus (facturation mensuelle, pages saisonnières) sont observés ou consciemment reportés.
• Une personne nommée assure les 48 premières heures après la bascule.

Toutes les cases cochées, la découverte est finie. La bascule elle-même (déploiement progressif, report-only maintenu à côté de l’en-tête bloquant, critères de rollback) est détaillée dans le runbook de migration report-only vers enforced. Et si la personne désignée est un développeur backend qui a hérité du sujet en plus de son sprint, tenir une CSP sans ingénieur sécurité dédié décrit la charge réelle que ça représente.