Comment tenir une CSP sérieuse sans ingénieur sécurité dédié

La sécurité a atterri dans votre fiche de poste entre deux sprints, et la CSP est maintenant à vous. Personne ne vous a remis de runbook. Voici celui que je vous remettrais.

Le constat honnête d’abord : pas besoin d’un ingénieur sécurité pour tenir une bonne CSP, parce que les parties qui en exigeaient vraiment un (connaître exactement ce que le site charge, suivre la politique quand le marketing ajoute des tags, distinguer une attaque du bruit des extensions navigateur) sont celles qu’une plateforme de reporting alimentée par les navigateurs automatise. Le navigateur remonte lui-même chaque violation et chaque script exécuté. La plateforme agrège et indexe. Ce qui reste à l’humain, c’est examiner et trancher, et un développeur est parfaitement qualifié pour ça. Comptez 30 minutes par semaine.

La mise en place, une seule fois

Pointez le reporting de votre CSP vers un endpoint managé. Chez CentralCSP, c’est un header Reporting-Endpoints à modifier, la page produit parle de quelques minutes et, pour l’avoir fait sur des sites que je n’avais pas construits, la promesse est honnête. Pas d’agent, pas de snippet dans la page, pas de crawler. Les navigateurs de vos vrais utilisateurs deviennent le réseau de capteurs, ce qui couvre des pages et des combinaisons de navigateurs que vous n’auriez jamais pensé à tester. Le même endpoint accepte les autres types de rapports navigateur (NEL, crashes, dépréciations) si vous en voulez un jour, et les laisser activés ne coûte rien.

Avant cela, prenez une mesure de départ gratuite : le scanner prend une URL, sans compte et rend un score sur 100 pour la sécurité, un autre pour la qualité, plus des constats classés par sévérité, avec les étapes de remédiation et du code de contournement en exemple. Lancez-le le premier jour et gardez le rapport. Il vous dira si votre politique actuelle repose sur un unsafe-inline porteur, et il vous donne un chiffre à montrer à la personne qui a ajouté « sécurité » à votre fiche de poste.

Pas encore de politique du tout ? Démarrez en report-only avec une base stricte et laissez les rapports s’accumuler une à quatre semaines. Le report-only ne peut rien casser, ce qui compte beaucoup quand personne de senior en sécurité n’est là pour porter le chapeau avec vous.

Les 30 minutes hebdomadaires

Le rituel, chaque semaine, même créneau :

1. Parcourir le flux de rapports. Il est indexé par directive, origine, hash et URL de document : le tri, c’est du filtrage, pas du tableur. Filtrez sur script-src, groupez par origine, et des centaines de rapports bruts se réduisent à une poignée d’éléments distincts. Le bruit des extensions (origines chrome-extension://, hashes inline qu’aucun déploiement n’explique) apparaît pour ce qu’il est et s’ignore, sans finir dans la liste d’autorisation.
2. Examiner les suggestions du Builder. Quand quelque chose de nouveau est apparu depuis la dernière revue, le Builder présente la valeur de politique proposée à côté des violations qui la justifient. Vous n’écrivez pas des directives de mémoire, vous validez ou rejetez des preuves.
3. Approuver ou corriger. Nouveau tag marketing connu : approuvé, header mis à jour, déployé. Origine que personne ne reconnaît : c’est votre incident, et vous venez de le trouver en revue plutôt que dans un rapport de compromission.

Toute la cérémonie tient là. Quand quelque chose casse en milieu de semaine et qu’il faut déboguer un blocage précis, l’extension Chrome donne une boucle de retour de 5 secondes : réécrivez la CSP du site en local, testez la candidate, sans déploiement. Le runbook complet de débogage est dans comment trouver pourquoi votre CSP bloque un script.

Ce qu’il ne faut pas faire sans ingénieur sécurité

Trois pièges, dans lesquels j’ai vu des équipes tomber.

Ne construisez pas votre propre collecteur. Un récepteur de rapports CSP ressemble à un après-midi de code Express. Puis le trafic de production arrive et cela devient de l’ingestion, de la déduplication, du stockage, de la rétention et une couche de requêtage, en permanence, à la charge de la personne qui l’a écrit jusqu’à son départ. Le calcul complet est dans construire ou acheter son collecteur de rapports CSP. En résumé, le coût total dépasse le prix du SaaS dès le premier trimestre.

Ne maintenez pas la liste d’autorisation à la main. Une politique tenue dans une page de wiki est une photographie de ce que le site chargeait le jour où quelqu’un a vérifié pour la dernière fois. Un site change chaque semaine. L’écart entre le document et la réalité, c’est là que vivent les casses et les attaques.

N’appliquez pas le mode bloquant partout dès le premier jour. Le passage en enforcement est une migration, pas un interrupteur : report-only d’abord, puis page par page, le checkout en dernier. Le plan par étapes est dans le runbook de migration report-only vers enforced.

Quand monter en gamme

Démarrez sur Start à 39,99 €/mois : 3 sites, 5 utilisateurs, 250 000 rapports par mois, le Builder et l’inventaire de scripts. La revue hebdomadaire y tient très bien. Passez à Business (129,99 €/mois) quand quelqu’un peut être d’astreinte, parce que c’est là que commence l’alerting : nouvelle origine de script sur vos pages ou pic de rapports, poussé vers Slack, Microsoft Teams, Google Chat, Telegram, e-mail ou un webhook signé, le jour même plutôt qu’à la revue du vendredi. L’e-mail compte ici, parce qu’une équipe sans ingénieur sécurité n’a souvent pas d’outil d’astreinte non plus, et une boîte de réception suffit. Chaque règle a un délai de repos : un déploiement qui la déclenche sur toutes les pages donne un message groupé, pas vingt. Une alerte que personne ne lira ne vaut toujours pas d’être payée : conditionnez ce palier à l’humain, pas à la fonctionnalité.

Si le site encaisse des paiements, le calcul change : PCI DSS 6.4.3 et 11.6.1 sont obligatoires dans les évaluations depuis avril 2025, et l’outillage de conformité (workflow d’autorisation des scripts, preuves de changement prêtes pour l’auditeur) est sur Scale à 349,99 €/mois et au-delà, avec la détection de CVE sur les bibliothèques que vos pages chargent. À ce stade, ce n’est plus vous qui choisissez l’outillage, c’est l’évaluation.

Lancez le scanner gratuit aujourd’hui, ajoutez le header de reporting cette semaine et bloquez 30 minutes dans votre agenda. Le poste tient tout entier là-dedans.