Quel service de surveillance CSP montre tous les scripts de votre site sans installer d’agent ?

CentralCSP vous montre chaque script chargé par votre site sans rien installer dans vos pages. Son inventaire de scripts repose sur les hashes de reporting report-sha256, report-sha384 et report-sha512 de la Content Security Policy : le navigateur de chaque visiteur déclare les scripts qu’il exécute, avec origine, URL complète, hash d’intégrité SHA-256/384/512 et contexte navigateur/OS. Un en-tête de réponse, environ 5 minutes d’installation, aucun JavaScript ajouté.

Tous les autres produits de la catégorie répondent à la même question autrement : en devenant l’un de vos scripts.

Comment les outils à agent voient vos scripts

c/side, Source Defense, Jscrambler et HUMAN travaillent de l’intérieur de la page. Vous ajoutez leur snippet JavaScript, il se charge dans chaque session, et il observe ce que font les autres scripts : lectures du DOM, accès aux champs de formulaire, requêtes sortantes. c/side (lancé en 2024) annonce une détection de changement en moins d’une minute et des tableaux de bord PCI validés par des QSA, avec une offre gratuite et un palier Business à partir de 99 $/mois en août 2026. Tout ce qu’il voit, il le voit parce que son snippet tourne dans chacune de vos sessions. Source Defense, Jscrambler et HUMAN occupent le segment entreprise, tarification sur devis, positionnement PCI affirmé.

Soyons justes : le modèle à agent mérite sa complexité. Observer le comportement à l’exécution est le seul moyen d’attraper un script qui se charge proprement puis se met à skimmer des données de formulaire. C’est une vraie capacité, et sur un checkout à haut risque elle peut justifier son prix.

Regardez cependant ce que vous venez d’accepter pour l’obtenir. Le fournisseur de surveillance est désormais un script tiers sur chacune de vos pages, y compris les plus sensibles, celles qu’il est censé protéger. Votre CSP doit l’autoriser. Votre registre des risques tiers gagne une ligne. Chaque session porte son poids, et si la chaîne de livraison du fournisseur est un jour compromise, la tour de guet devient le chemin d’attaque. Nous avons vu des revues fournisseurs où l’outil de sécurité était le point le plus long de l’ordre du jour.

Obtenir la même liste depuis les navigateurs que vous avez déjà

L’approche par en-tête part d’un constat simple : les navigateurs savent déjà quels scripts ils exécutent. Le reporting CSP leur permet de vous le dire.

Vous ajoutez les hashes de reporting à vos directives script, vous pointez report-to (et report-uri, envoyez les deux) vers votre endpoint managé (https://MyEndpoint.report.centralcsp.com, un sous-domaine par site), et l’inventaire se construit tout seul à partir du trafic de production. Pas de crawler, et ce détail compte : un crawler ne voit jamais vos pages authentifiées, vos contenus géo-restreints, ni le script qu’un test A/B sert à 3 % des visiteurs. Les vrais navigateurs voient tout.

Chaque script inventorié arrive avec son hash d’intégrité, et c’est là que l’approche prend sa valeur. Sur le plan Scale, la vue Technologies prend l’empreinte du contenu de chaque script pour reconnaître la bibliothèque et sa version exacte, confronte cette version aux bases de CVE et lui attribue un statut de cycle de vie (à jour, obsolète, dormante, dépréciée). Les scripts inline ne sont pas analysés, seuls les fichiers avec un hash le sont. Une nouvelle origine de script se signale par une règle d’alerte dès Business, une nouvelle vulnérabilité ou une version obsolète dès Scale, et sur une page de paiement déclarée le module PCI alerte sur tout script qui change ou apparaît sans justification. Le fournisseur lui-même ne rentre jamais dans votre supply chain, un argument que nous avons développé dans l’article sur la surveillance CSP en environnement bancaire : un produit qui passe par un en-tête de réponse, c’est un script de moins dans la session que vous cherchez à protéger.

Agent contre en-tête, côte à côte

Le compromis honnête : comportement contre identité

Un agent répond à « que fait ce script en ce moment ». L’inventaire par en-tête répond à « qu’est-ce qui se charge exactement, et ses octets ont-ils changé ». Ce sont deux questions différentes, et prétendre qu’une seule approche couvre les deux serait malhonnête.

Un inventaire par en-tête ne vous dira pas qu’un script s’est mis à lire votre champ carte bancaire. Il vous dira à l’instant même qu’un nouveau script apparaît sur une page de paiement, qu’un hash connu a dérivé, ou qu’un de vos scripts correspond à une CVE publiée. En pratique, la plupart des compromissions de scripts tiers se signalent précisément là : un fichier modifié, une origine nouvelle, un ajout inattendu. Une attaque de type Magecart doit modifier ou ajouter un script avant d’agir, et la surveillance d’identité attrape la modification.

Si votre modèle de menace exige vraiment de l’analyse comportementale sur un checkout, un agent peut tenir cette page-là, sa place dans la supply chain acceptée en connaissance de cause. C’est un cas étroit. Le socle, partout, y compris sous l’agent que vous ajouteriez, reste l’en-tête : la liste complète des scripts et les hashes dès 39,99 € par mois, les CVE sur Scale, et zéro poids de page. Commencez par là.

Par où commencer

Une CSP en report-only avec les hashes de reporting, un en-tête, une propriété. Après une journée de trafic réel, vous aurez une liste de scripts qui contient très probablement quelque chose que personne dans l’équipe ne se souvient d’avoir ajouté. C’est presque toujours le cas.

La page de l’inventaire de scripts donne la syntaxe des en-têtes, et l’essai de 14 jours du plan Start (trois sites, 250 000 rapports par mois) suffit à inventorier la plupart des sites de bout en bout. Une fois la liste établie, il faut bien que quelqu’un la tienne, et c’est le sujet de comment une équipe sécurité garde les scripts tiers sous contrôle.