A quoi ressemble le CTEM dans la couche navigateur: un script tiers, cinq constats

Reponse rapide: Continuous Threat Exposure Management (CTEM), le cadre defini par Gartner pour reduire l'exposition de facon continue, se casse au niveau du navigateur dans la plupart des programmes d'entreprise. L'analyse en direct de c/side sur un seul widget de feedback client Skeepers dans une grande banque de detail internationale a revele deux constats eleves et trois moyens, dont un sous-script controle par serveur absent de la Content Security Policy et un cookie de suivi de 360 jours etendu au sous-domaine d'authentification de la banque, malgre zero signalement dans les bases de menaces. Cet article relie chaque constat aux cinq etapes CTEM et montre pourquoi les clauses PCI DSS 4.0.1 6.4.3 et 11.6.1 demandent plus qu'un inventaire de scripts.

Une grande banque de detail internationale charge un widget de feedback client sur son site principal. Le widget pose un cookie de suivi de 360 jours etendu a tout le domaine bancaire, y compris le sous-domaine d'authentification. Il injecte dynamiquement un sous-script dont le nom de fichier est decide par le serveur du fournisseur au runtime, et ce sous-script n'est pas dans la Content Security Policy de la banque. Les pages de login n'ont aucun CSP.

Rien de cela n'est hypothetique. C'est ce que c/side a trouve dans une analyse approfondie d'un script Skeepers / MyFeelBack execute sur une propriete bancaire active.

Cet article utilise ce cas reel, anonymise mais avec les noms de fournisseurs conserves, pour montrer a quoi ressemble le CTEM quand il est vraiment applique a la couche navigateur, et ou la plupart des programmes laissent la boucle ouverte.

TL;DR

• CTEM, le cadre Gartner qui traite l'exposition comme une boucle continue, compte cinq etapes: cadrage, decouverte, priorisation, validation, mobilisation. La plupart des programmes couvrent les deux premieres et s'arretent au navigateur.
• L'analyse en direct d'un seul widget Skeepers sur une banque internationale a revele deux constats HIGH et trois MEDIUM, dont un sous-script controle par serveur absent de l'allowlist CSP.
• Les pages d'authentification de la banque n'avaient aucun en-tete CSP, en conflit apparent avec la clause PCI DSS 4.0.1 6.4.3.
• Un cookie de suivi de 360 jours etait etendu a tout le domaine bancaire et accompagne les flux de login.
• La chaine mediane d'inclusion tierce sur le web moderne a trois niveaux de profondeur, avec une profondeur maximale observee de 2 285 (Web Almanac 2025).
• Les activites Magecart et skimmer ont compromis plus de 23 millions de transactions en ligne en 2025 (Recorded Future via Mastercard).
• La visibilite sans enforcement est de la documentation, pas de la protection.

Qu'est-ce que le CTEM, et ou se casse-t-il?

Le CTEM est le cadre Gartner qui traite l'exposition comme une boucle continue en cinq etapes: cadrage, decouverte, priorisation, validation et mobilisation. Le principe est que l'exposition change constamment, donc la reponse doit etre continue elle aussi.

La plupart des programmes securite ont progresse sur les trois premieres etapes pour les actifs traditionnels. Les configurations cloud sont scannees. La dispersion d'identite est cartographiee. Les vulnerabilites sont notees.

Puis la boucle se casse a la validation et a la mobilisation pour tout ce qui s'execute dans le navigateur.

CTEM navigateur vs CTEM cloud

Etape CTEM	Cloud et identite	Couche navigateur
Cadrage	Mature	Souvent saute
Decouverte	Outillage solide	Partielle, surtout via tag managers
Priorisation	Score de risque	Rarement notee
Validation	Pentests, BAS	Presque jamais testee
Mobilisation	Corriger, isoler, revoquer	Envoyer un email a l'equipe marketing

L'exposition navigateur n'est pas mobilisee parce que l'equipe securite ne peut generalement pas la mobiliser. Elle peut voir un script. Elle peut creer un ticket. Elle ne peut pas empecher le script de s'executer au prochain chargement de page.

C'est la faille. Le parcours ci-dessous montre ce que cette faille donne en production.

Cas d'etude: un script, cinq constats pertinents pour le CTEM

Le script concerne est le chargeur principal du widget de feedback client Skeepers, anciennement MyFeelBack. Il est heberge sur cdnactor.myfeelback.com et charge sur les pages generales du site principal d'une banque de detail internationale.

Il n'est pas malveillant. Aucun hit YARA, aucune entree dans une base de menaces, aucun signal rouge en analyse statique. C'est precisement le sujet. La plupart de l'exposition navigateur ne vient pas d'acteurs clairement hostiles. Elle vient de tiers approuves et contractualises dont personne ne gouverne activement le comportement.

Constat 1: l'allowlist CSP est incomplete

Les pages generales de la banque livrent une Content Security Policy qui autorise *.myfeelback.com. Jusque-la, rien d'inhabituel.

Mais le chargeur Skeepers injecte au runtime un sous-script depuis room.cxr.skeepers.io, des feuilles de style depuis actor.cxr.skeepers.io, et un appel GeoIP vers un endpoint AWS Lambda sur c7hn3ry3r4.execute-api.us-east-1.amazonaws.com. Aucun de ces domaines n'est dans le CSP. Le widget est donc partiellement casse en production, ou le CSP est contourne d'une facon que l'equipe securite n'a pas autorisee.

C'est exactement le decalage qu'une revue fournisseur ponctuelle ne voit pas. Le script livre une URL *.myfeelback.com au premier jour. Le comportement runtime tire depuis *.cxr.skeepers.io six mois plus tard, apres un rebranding. Une decouverte de niveau CTEM doit suivre les appels runtime reels, pas le contrat.

Constat 2: un sous-script controle par serveur avec un hash mobile

Le chargeur construit au runtime une URL de cette forme:

https://room.cxr.skeepers.io/lib/frontend/handy/js/libraries/{themeDeployment}-libraries.js

La partie {themeDeployment} est decidee par le serveur du fournisseur. Le hash du chargeur reste stable. Le hash de ce qu'il charge change quand Skeepers le souhaite. Une revue statique du chargeur peut passer le lundi et manquer un remplacement de sous-script le mardi.

C'est le schema classique de supply chain navigateur. Polyfill.io fonctionnait de la meme facon en 2024: un script primaire propre, un payload mutable en deuxieme etape, aucun controle d'integrite depuis la page hote. Quand la deuxieme etape bascule, chaque visiteur de chaque site chargeant le script primaire devient une cible.

Dans ce contexte, la validation CTEM signifie fingerprinting continu du code injecte au runtime, pas seulement du chargeur.

Constat 3: un cookie de suivi de 360 jours etendu au domaine apex

Le widget pose un cookie nomme _MFB_ avec ces proprietes:

• Domaine: tout l'apex de la banque, y compris le sous-domaine d'authentification
• Expiration: 360 jours
• Contenu: un blob Base64 contenant un identifiant visiteur aleatoire persistant de 11 caracteres, des compteurs de visites campagne et deployment, un historique de pages vues, des compteurs de clics, un TTL de session et des selecteurs CSS

En parallele, le widget ecrit 15 cles dans localStorage et les resynchronise vers le cookie a chaque chargement de page.

Il en decoule plusieurs choses:

1. La portee au niveau apex signifie que le cookie voyage avec les requetes vers le sous-domaine d'authentification, meme si le widget n'y est pas charge.
2. Un identifiant pseudonyme de 360 jours sur une propriete bancaire necessite un consentement explicite GDPR / CNIL et une justification documentee de retention. C'est une question de Record of Processing Activities (ROPA), pas seulement de securite.
3. La synchronisation cookie vers localStorage et retour signifie qu'un effacement standard des cookies ne reinitialise pas l'identifiant visiteur.

C'est exactement le type d'exposition vie privee de longue traine que les cadres CTEM doivent faire remonter pendant la priorisation.

Constat 4: aucun CSP sur les pages d'authentification

C'est le constat le plus serieux. Le flux de login de la banque n'envoie aucun en-tete Content Security Policy.

Le script Skeepers n'y est pas charge. Mais ce n'est pas le point. Le point est que tout futur script, tag marketing, outil A/B testing ou fournisseur compromis, s'executerait sur le login sans restriction et avec acces complet au DOM des champs d'identifiants.

La clause PCI DSS 4.0.1 6.4.3 exige un mecanisme pour confirmer et autoriser les scripts sur les pages de paiement. La clause 11.6.1 exige un mecanisme de detection d'alteration sur ces pages. L'absence totale d'en-tete ne satisfait aucune des deux.

L'infrastructure existe. Un endpoint de reporting CSP fonctionne deja pour le site general. Il n'a simplement pas ete etendu aux pages les plus sensibles de la propriete.

Constat 5: l'enquete se rend dans le DOM hote

Quand une enquete se declenche, le widget injecte #mfbIframeOverlay et #mfbIframeBlock directement dans document.body. Cela semble anodin, et ca l'est pour l'enquete elle-meme. Mais cela signifie que le sous-script charge dynamiquement, celui au hash mobile, s'execute dans la meme origine que la page de la banque. Meme acces DOM, memes formulaires, memes cookies.

Un listener keydown est ajoute pour l'accessibilite, afin de pieger le focus avec Tab. Il n'exfiltre rien aujourd'hui. Mais le listener est sur le conteneur de plus haut niveau de l'enquete, et le code qui le possede peut changer chaque fois que le fournisseur pousse un nouveau theme deployment. La priorisation CTEM doit marquer cela comme une dependance de confiance envers le processus de release du fournisseur.

Ce que l'analyse a demande, et ce qu'elle a trouve

Pour donner le contexte de l'effort de decouverte et validation CTEM:

Metrique	Valeur
Scripts analyses	2 (chargeur primaire + sous-script)
Outils appeles	20+ sur script, infra, menaces et comportement
Duree totale	281,9 secondes
Constats de risque	8 (2 HIGH, 3 MEDIUM, 3 INFO)
Hits dans les bases de menaces	0
Hits YARA	0

Zero indicateur de menace existant. Deux constats HIGH. C'est l'asymetrie pour laquelle le CTEM a ete concu: l'exposition navigateur la plus courante n'est pas un script connu comme malveillant. C'est un script approuve qui fait des choses jamais explicitement autorisees.

Pourquoi crawlers et scanners traditionnels ne trouvent pas cela

Une question raisonnable est: pourquoi les outils existants de la banque n'ont-ils rien remonte? La reponse est que presque rien dans le stack securite standard n'execute la page comme un vrai utilisateur.

Voici ce que voit un scanner typique:

• Scanners d'applications web (DAST): ils parcourent des URLs et inspectent les reponses. Ils ne chargent pas la page dans un vrai navigateur, n'executent pas JavaScript et n'attendent pas que des scripts injectes au runtime recuperent leurs payloads de seconde etape. Le chargeur Skeepers renvoie 200 OK avec du JS valide. Termine.
• Crawlers SEO et moteurs de recherche: ils rendent avec un navigateur headless, mais ne scorent pas les scripts tiers pour leurs comportements securite. Ils s'interessent au contenu, pas aux cookies.
• Analyse statique (SAST) et SCA: elles regardent le code dans votre depot. Le script Skeepers n'est pas dans votre depot. Il est charge depuis le CDN de quelqu'un d'autre au runtime.
• CSP en report-only: il peut detecter des violations, mais seulement pour les domaines que vous savez deja autoriser. Il ne peut pas avertir sur des sous-scripts injectes au runtime dont les URLs sont decidees cote serveur apres le chargement.
• Scanners de vulnerabilites: ils associent des CVE a des inventaires logiciels. Il n'existe pas de CVE pour "le widget marketing de votre fournisseur pose un cookie de 360 jours sur votre sous-domaine d'authentification".
• Tests d'intrusion: ils sont ponctuels. Le hash du chargeur Skeepers n'avait aucune histoire d'observation sur 90 jours. Le hash du sous-script change quand le fournisseur pousse un nouveau theme. Un pentest en mars ne dit pas ce qui charge en octobre.

Le site de la banque a une infrastructure CSP, un endpoint de reporting CSP et une equipe securite competente. Rien de cela n'a capture ces constats, car aucun de ces outils ne surveille en continu l'environnement navigateur runtime.

C'est la raison structurelle pour laquelle le navigateur reste dans l'angle mort du CTEM. L'exposition n'est pas dans du code que quelqu'un scanne. Elle est dans du code qui charge, mute et s'execute sur la machine de l'utilisateur, dans un contexte qui disparait quand l'onglet se ferme. La detecter exige d'observer le runtime, pas le depot ni le reseau.

Pourquoi les outils de visibilite seuls ne ferment pas la boucle

Le parcours Skeepers est le type de sortie qu'un outil de visibilite peut produire. Le plus dur vient apres.

Approche	Decouvre les scripts	Score le risque	Detecte le changement	Arrete l'execution
Tag managers	Oui	Non	Partiel	Non
CSP seul	Non	Non	Partiel	Oui, mais grossier
Securite navigateur axee visibilite	Oui	Oui	Oui	Non
Securite navigateur axee enforcement	Oui	Oui	Oui	Oui

Sans la derniere colonne, le seul chemin de mobilisation de l'equipe securite est un ticket vers l'equipe qui possede la relation fournisseur, souvent marketing ou CX. Ce ticket concurrence le travail produit. Le fournisseur pousse un nouveau sous-script avant la fermeture du ticket. Le cycle recommence.

C'est la raison operationnelle pour laquelle le CTEM bloque au navigateur, meme dans des entreprises bien equipees.

Pourquoi les chiffres globaux devraient inquieter les responsables securite

Le cas Skeepers est un script sur un site. L'image agregree est beaucoup plus large.

• La chaine mediane d'inclusion tierce sur le web moderne a 3 niveaux de profondeur, avec une profondeur maximale observee de 2 285 (Web Almanac 2025).
• Les attaques de type skimmer et Magecart ont compromis plus de 23 millions de transactions en ligne en 2025 (Recorded Future via Mastercard).
• La plupart des outils CTEM traitent cette couche comme le probleme de quelqu'un d'autre.

Une banque qui charge deux scripts Skeepers est un petit cas. Un checkout e-commerce qui charge 80 a 200 scripts tiers est normal. L'exposition grandit avec le nombre de scripts, la profondeur de la chaine d'inclusion et la cadence des changements fournisseurs.

Mapper cside a la boucle CTEM avec ce cas

Voici ce que chaque etape CTEM signifie pour ce script quand la plateforme cside est la couche de controle runtime.

Etape CTEM	Ce que cela veut dire dans le navigateur	Exemple Skeepers
Cadrage	Definir quels sites et pages sont couverts	Tous les sous-domaines bancaires, avec plus de rigueur sur l'authentification
Decouverte	Inventorier tous les scripts first-party, third-party et fourth-party	Chargeur + sous-script runtime + Lambda GeoIP + 3 endpoints CSS
Priorisation	Scorer les scripts selon acces aux donnees et comportement	Cookie de 360 jours sur sous-domaine auth, sous-script controle par serveur: HIGH
Validation	Tester ce que les scripts font vraiment, pas ce qu'ils declarent	Confirmer la lacune CSP, confirmer la portee du cookie, fingerprinter le sous-script
Mobilisation	Arreter, restreindre ou autoriser l'execution	Restreindre le widget aux pages non auth, pinner le hash du sous-script, alerter sur changement

Les captures que beaucoup d'equipes renvoient disent la meme chose une fois cside deploye. Elles savaient que le paysage tiers etait large. Elles ne savaient pas que cela pouvait etre 16 000 scripts dans une semaine retail typique. Elles ne savaient pas combien exigeaient une revue PCI. Elles n'avaient pas de chemin rapide entre "nous avons trouve un probleme" et "le probleme ne peut pas s'executer".

Pour l'e-commerce en particulier, c'est une ligne de defense contre les campagnes de protection Magecart et web skimming, qui continuent de fonctionner precisement parce que le script continue de s'executer.

Que demander a un outil d'exposition navigateur

Si vous evaluez des outils avec le cadre CTEM en tete, les questions sont concretes:

• Decouvre-t-il les scripts charges au runtime, pas seulement au chargement initial?
• Suit-il la chaine de dependances jusqu'aux chargements fourth-party?
• Detecte-t-il quand le hash d'un script auparavant propre change?
• Dit-il ce que chaque script lit dans le DOM, les cookies et le stockage?
• Peut-il bloquer ou restreindre un script en production sans redeployer le site?
• Ses preuves se mappent-elles a PCI DSS 6.4.3 et 11.6.1?
• Combien de temps entre detection et enforcement: minutes, heures ou un sprint?

Si la reponse aux trois dernieres n'est pas "oui, vite, oui", l'outil fait de la decouverte CTEM sans mobilisation CTEM.

Le cadrage qui compte

Le CTEM fonctionne parce qu'il traite l'exposition comme continue. Le navigateur n'entre dans ce cadre que si la reponse est continue elle aussi. Les audits trimestriels de scripts ne suivent pas la cadence des changements de code tiers. Les tickets vers l'equipe marketing ne suivent pas la vitesse d'un skimmer Magecart.

Le cas Skeepers est modere. Aucun acteur malveillant, un fournisseur reputé, un schema SaaS connu. Il a pourtant produit deux constats HIGH sur une grande banque internationale, dont un directement lie a PCI DSS 4.0.1 6.4.3.

Si un fournisseur legitime chez un client prudent produit autant d'exposition, la question n'est pas de savoir si la couche navigateur a besoin d'une couverture CTEM. La question est combien de temps les entreprises continueront a la traiter comme hors scope.

Pour voir votre propre exposition avec la meme grille, le monitoring des scripts navigateur sur une propriete active donne la boucle de decouverte, priorisation et enforcement en moins d'une heure.

Si vous comparez aussi une plateforme axee visibilite a une plateforme axee enforcement, la comparaison Reflectiz vs cside detaille les compromis cote a cote.