Construire un inventaire de scripts avec le hash reporting CSP

On ne peut pas sécuriser ce qu'on ne voit pas. Un site typique charge des dizaines de scripts : analytics, tag managers, widgets de chat, tests A/B, SDK de paiement et vos propres bundles. Chacun s'exécute dans les navigateurs de vos utilisateurs avec un accès complet à la page. Si l'un d'eux est échangé ou trafiqué, vous voulez le savoir avant vos clients.

Un inventaire de scripts est une liste structurée de chaque script que le navigateur charge et exécute sur une page, propriétaires et tiers. La façon moderne d'en construire un est de laisser le navigateur vous le rapporter. La politique de sécurité du contenu (CSP) niveau 3 ajoute le hash reporting : le navigateur calcule un hash cryptographique de chaque script qu'il récupère et l'envoie à un endpoint de reporting. Vous collectez ces rapports et les transformez en un inventaire vivant, une nomenclature logicielle (SBOM) de votre code côté client.

Cet article montre comment fonctionne le hash reporting CSP, ce que contiennent les rapports, et comment l'inventaire correspond aux deux exigences PCI DSS v4 qui le demandent désormais.

Pourquoi un inventaire de scripts côté client compte

Un scan de dépendances côté serveur vous dit ce qu'il y a dans votre build. Il ne dit rien de ce qui s'exécute réellement dans le navigateur, où les tags tiers injectent d'autres scripts à l'exécution et où un attaquant peut remplacer un fichier sur un CDN que vous ne contrôlez pas.

Le navigateur est le seul endroit qui voit la liste complète et réelle. Avec un inventaire construit à partir de ce que le navigateur rapporte, vous pouvez :

Savoir exactement quels scripts s'exécutent, d'où, et avec quel hash.
Repérer un nouveau script, une nouvelle origine, ou un hash modifié qui peut signaler une dépendance compromise ou une injection.
Montrer à un auditeur quels scripts s'exécutent sur une page de paiement et que vous les surveillez pour changement.

Des menaces comme le formjacking et Magecart (ce que sont Magecart et le formjacking) fonctionnent en modifiant discrètement un script qui se charge sur une page de checkout, et un tag manager de confiance est un vecteur de livraison courant ; voyez comment les attaquants abusent de Google Tag Manager. Un inventaire de référence plus la détection de changement, c'est ainsi que vous attrapez cela.

Comment fonctionne le hash reporting CSP

La CSP niveau 3 introduit trois mots-clés de source réservés au reporting que vous pouvez placer dans une directive de script : 'report-sha256', 'report-sha384' et 'report-sha512'. Ils n'autorisent ni ne bloquent rien. Ils demandent au navigateur de calculer le hash de chaque ressource de type script récupérée et d'envoyer un rapport.

Les rapports voyagent via la Reporting API. Pour les recevoir, vous déclarez un endpoint avec le header Reporting-Endpoints et le référencez depuis une directive report-to dans la même politique, le même câblage couvert dans comment configurer la Reporting API. Sans report-to, le navigateur n'émet aucun rapport de hash.

Voici la paire de headers minimale qui fonctionne. Pointez l'endpoint vers votre URL de reporting CentralCSP.

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Content-Security-Policy: script-src 'self' 'report-sha256'; report-to csp-endpoint

Une bonne façon d'inventorier un site existant sans risque est d'ajouter le mot-clé d'abord en mode report-only. Le navigateur rapporte les hashes de chaque script qui se charge actuellement, et rien n'est bloqué pendant que vous construisez la ligne de base.

Content-Security-Policy-Report-Only: script-src 'self' 'report-sha256'; report-to csp-endpoint

Le mot-clé peut cohabiter avec la directive script-src que vous utilisez déjà. Il coexiste avec votre liste d'autorisation et vos nonces ou hashes existants. Le comportement vérifié concerne script-src ; le fait que d'autres directives de type script (un repli default-src ou script-src-elem) déclenchent aussi le rapport n'est pas documenté, alors fiez-vous à script-src.

Ce que contient le rapport csp-hash

Chaque script rapporté produit un rapport csp-hash. Le corps identifie le document, l'URL du script, et le hash de style integrity pour que vous puissiez le rapprocher d'une valeur connue-bonne.

{
  "type": "csp-hash",
  "age": 12,
  "url": "https://api-next.centralcsp.com/",
  "body": {
    "documentURL": "https://api-next.centralcsp.com/",
    "subresourceURL": "https://api-next.centralcsp.com/main.js",
    "hash": "sha256-85738f8f9a7f1b04b5329c590ebcb9e425925c6d0984089c43a022de4f19c281",
    "type": "subresource",
    "destination": "script"
  }
}

Le champ hash utilise le même format préfixé par l'algorithme et encodé en base64 que Subresource Integrity, il s'aligne donc sur les hashes integrity que vous gérez déjà. Les rapports arrivent sous forme de tableau JSON envoyé en POST avec le type de contenu application/reports+json vers un endpoint sécurisé.

Deux limites pratiques à connaître :

Le navigateur ne calcule un hash exploitable que pour les réponses CORS-same-origin. Un script tiers cross-origin peut être rapporté par URL mais sans hash exploitable. Vous voyez tout de même qu'il s'est chargé et d'où.
Les navigateurs émettent des noms de champs en camelCase (documentURL, subresourceURL, hash, type, destination), c'est la forme montrée ci-dessus. Le JSON d'exemple de la spec CSP3 utilise le snake_case (document_url, subresource_url), un collecteur devrait donc tolérer les deux orthographes.

Collecter, dédupliquer et suivre ces rapports à la main est fastidieux. CentralCSP ingère le flux csp-hash, construit l'inventaire de scripts pour vous, ajoute la détection de technologie, de version et de CVE, et vous alerte quand un script ou un hash change. Vous pouvez l'explorer sur la page de la fonctionnalité inventaire de scripts.

Compatibilité des navigateurs

Le hash reporting CSP pour les scripts a été livré dans les navigateurs basés sur Chromium, y compris Chrome sur Android et WebView. Il a ajouté les mots-clés 'report-sha256', 'report-sha384' et 'report-sha512'. Firefox et Safari ne le prennent pas en charge, alors traitez-le comme du Chromium-seulement aujourd'hui.

Ne le confondez pas avec un origin trial Chromium distinct et ultérieur qui imprime les URL de scripts et les hashes d'eval dans les DevTools et les rapports. Celui-là est expérimental. Le hash reporting de scripts report-sha* décrit ici est livré.

Un inventaire des scripts avec leurs statuts de revue

Ce que cela vous apporte pour PCI DSS v4

PCI DSS v4 a ajouté deux exigences visant directement les scripts qui s'exécutent dans le navigateur du client sur les pages de paiement. Les deux sont passées de bonne pratique à obligatoires après le 31 mars 2025. Pour savoir comment une CSP correspond à celles-ci, voyez CSP pour PCI DSS v4.

L'exigence 6.4.3 vous demande de gérer chaque script chargé et exécuté sur une page de paiement : confirmer que chaque script est autorisé, garantir l'intégrité de chaque script, et tenir un inventaire de tous les scripts avec une justification écrite de la nécessité de chacun.

L'exigence 11.6.1 demande un mécanisme de détection de changement et de falsification qui alerte le personnel des changements non autorisés des headers HTTP et du contenu des pages de paiement tels que reçus par le navigateur, évalué au moins une fois tous les sept jours ou à une fréquence fixée par votre analyse de risque ciblée.

Un inventaire de scripts construit à partir du hash reporting vous aide à répondre aux deux. Les hashes sont votre ligne de base autorisée et votre contrôle d'intégrité pour 6.4.3, et l'inventaire par script est la liste documentée qu'elle réclame. Un hash modifié ou une nouvelle origine de script est le signal de changement que 11.6.1 veut détecter et signaler. CentralCSP ne certifie pas votre conformité PCI DSS ; c'est un QSA qui le fait. Ce qu'il fournit, ce sont les données, l'alerte et les preuves exportables qui soutiennent les exigences. La formulation des exigences ci-dessus est paraphrasée ; le document officiel PCI DSS v4.0.1 est le texte qui fait foi.

Mettez-le en place

Commencez par ajouter 'report-sha256' en mode report-only et par pointer report-to vers votre endpoint, puis passez en revue l'inventaire que le navigateur construit pour vous avant de resserrer la politique appliquée. À partir de là, vous surveillez le changement plutôt que de re-auditer à la main.

Si vous voulez que la collecte, la déduplication, la détection de CVE et l'alerte soient prises en charge pour vous, commencez gratuitement avec CentralCSP et laissez les rapports construire l'inventaire.