La journalisation de l'activité des scripts au niveau du navigateur est l'enregistrement en temps réel de ce qu'exécute JavaScript dans le navigateur d'un utilisateur: chaque lecture du DOM, accès aux champs de formulaire, requête réseau, écriture de cookies et injection dynamique de scripts effectués par du code propriétaire et tiers pendant une session active. C'est la couche de journalisation que les outils SIEM, EDR et WAF ne peuvent pas atteindre, et où le skimming Magecart, les compromissions de la chaîne d'approvisionnement et les scripts de détournement de session s'exécutent.
La plupart des équipes de sécurité disposent d'une solide journalisation au niveau des serveurs, du réseau et des endpoints. Le runtime du navigateur, où les scripts tiers s'exécutent avec les mêmes privilèges que le code propriétaire, est presque toujours non surveillé. Ce guide couvre ce que capture un journal d'activité des scripts du navigateur, pourquoi la lacune est importante et à quoi ressemble une réponse efficace aux incidents lorsqu'un script de votre site est compromis.
La lacune de journalisation que la plupart des stacks laissent ouverte
Une stack de sécurité d'entreprise typique journalise les couches suivantes:
| Couche | Ce qu'elle journalise | Outils typiques |
|---|---|---|
| Réseau | Trafic HTTP/S, DNS, événements de pare-feu | WAF, NGFW, NDR |
| Endpoint | Appels système, exécution de processus, écritures de fichiers | EDR, XDR |
| Serveur | Journaux d'application, événements d'authentification, appels API | SIEM (via agents/connecteurs) |
| Runtime du navigateur | Exécution JavaScript, lectures du DOM, comportement des scripts | Absent de la plupart des stacks |
Le runtime du navigateur est l'endroit où opèrent les attaques côté client. Un script Magecart lit la valeur d'un champ de carte de paiement et l'envoie à un serveur distant. Cette lecture se produit entièrement dans le navigateur. La couche réseau voit un POST HTTPS après que les données ont déjà quitté le système. L'EDR ne détecte aucun processus anormal. Le SIEM n'a aucune entrée. L'attaque se termine avec des journaux propres partout, ce qui explique pourquoi les équipes qui veulent détecter Magecart en temps réel instrumentent le navigateur lui-même.
Pour un seul GET /pricing depuis une unique IP, les deux couches rendent des verdicts opposés :
| Ce que voit la couche réseau/serveur | Ce que voit la couche de session de navigateur |
|---|---|
| IP : proxy résidentiel | Pointeur : 0 px déplacé |
| TLS : empreinte Chrome 124 | Présence : 0,2 s par page |
| Cookie : session valide | Navigation : strictement séquentielle |
| User-Agent : Chrome 124 | Défilement : aucun |
| Verdict : aucune anomalie, chargement propre | Verdict : classée automatisée, session limitée en débit |
Les en-têtes paraissent humains, donc le WAF, la CDN et l'inspection de l'IP laissent passer la requête. La même session, lue à la couche navigateur, ne bouge jamais le pointeur, reste 0,2 seconde par page et parcourt les pages dans un ordre strict sans défiler : l'angle mort du réseau est exactement là où cside la repère.
La compromission de la chaîne d'approvisionnement de Polyfill[.]io en juin 2024 a démontré cela à grande échelle. Un script hébergé sur CDN largement utilisé a été modifié pour servir des payloads malveillants à plus de 490 000 sites web. Le WAF, SIEM et EDR de chaque site affecté avaient des journaux propres. Les seuls outils capables de détecter l'anomalie étaient ceux opérant au niveau de la couche d'exécution du navigateur.
Ce que capture un journal complet d'activité des scripts du navigateur
Un journal d'activité utile au niveau du navigateur enregistre six catégories de comportements de scripts:
1. Accès au DOM et mutations
Quels éléments un script lit ou écrit, avec une attention particulière aux champs de saisie, aux éléments de formulaire et aux champs de mot de passe. Un script sur une page de paiement qui n'avait jamais lu le champ du numéro de carte auparavant mais le fait dans un nouveau déploiement est une anomalie comportementale qui mérite d'être signalée immédiatement.
2. Requêtes réseau
Chaque fetch(), XMLHttpRequest, navigator.sendBeacon(), pixel image et connexion WebSocket initiée par un script, incluant le domaine de destination, la méthode de requête et si la destination est nouvelle ou déjà connue. Les nouvelles destinations sortantes sont l'indicateur principal d'exfiltration de données.
3. Accès aux cookies et au stockage
Quels scripts lisent ou écrivent des cookies, localStorage et sessionStorage. Les scripts d'analyse légitimes ont rarement besoin de tokens de session. Si l'un d'eux commence à les lire, le comportement doit être signalé.
4. Injection dynamique de scripts
Scripts qui créent de nouveaux éléments <script> ou utilisent eval(), Function() ou document.write() pour exécuter du nouveau code au moment de l'exécution. C'est ainsi que les malwares de deuxième étape se chargent dans les attaques de la chaîne d'approvisionnement: le premier script est propre et il récupère et exécute le payload réel de manière dynamique.
5. Requêtes de sous-ressources et dépendances de quatrième partie
Scripts qui chargent des ressources externes supplémentaires, créant une chaîne depuis votre tiers approuvé vers un domaine de quatrième partie non approuvé. L'attaque Polyfill[.]io a utilisé ce modèle: le script CDN compromis chargeait du code contrôlé par l'attaquant depuis un domaine séparé.
6. Déviations de la ligne de base comportementale
Le signal le plus exploitable n'est pas un événement unique mais une déviation par rapport au comportement établi. Un script qui s'exécute sur votre page de paiement depuis six mois et n'a jamais accédé aux champs de formulaire, qui commence soudainement à lire les valeurs de saisie de carte dans une session sur mille: c'est l'événement de détection.
Réponse aux incidents pour les attaques de scripts du navigateur
La réponse efficace aux incidents pour la compromission d'un script de la couche navigateur suit un flux de travail distinct des incidents côté serveur. Le calendrier est compressé car les données peuvent être exfiltrées en millisecondes et la surface d'attaque est chaque session utilisateur exécutant le script compromis.
Détecter
La détection repose sur des alertes d'anomalies comportementales, pas sur la correspondance de signatures. La détection basée sur les signatures échoue contre les payloads polymorphiques et obfusqués décrits en détail ici. Le déclencheur pour un incident de la couche navigateur doit être: un script connu accédant à des types de données auxquels il n'avait jamais accédé auparavant, ou un script effectuant des requêtes réseau vers une destination en dehors de son profil comportemental établi.
Une alerte en temps réel, pas un lot SIEM du lendemain, est le standard minimum. Le temps qu'une révision quotidienne des journaux détecte un script Magecart, des dizaines de milliers de sessions peuvent avoir été exposées.
Contenir
La contention au niveau de la couche navigateur se produit différemment de la contention au niveau de l'endpoint. Les options incluent:
- Bloquer la requête réseau spécifique: empêcher l'appel d'exfiltration de se terminer en interceptant la requête sortante que fait le script malveillant.
- Bloquer le script lui-même: empêcher le script compromis de se charger lors des chargements de page suivants, réduisant immédiatement la surface d'attaque.
- Alerter sans bloquer: utiliser pour les détections de moindre confiance où le risque de faux positifs est élevé. Enregistre l'événement et alerte l'équipe sans impact visible pour l'utilisateur.
La capacité de bloquer sans déploiement de code, directement depuis une plateforme de surveillance sans toucher le code source du site, est critique pour la rapidité de contention. Les déploiements de code prennent des heures; le blocage au niveau du navigateur peut être quasi-instantané.
Enquêter
L'étape d'enquête nécessite un journal de ce qui s'est passé dans les sessions affectées. Sans journal d'activité du navigateur, cette étape est quasi impossible. Avec un tel journal, l'enquête peut répondre aux questions suivantes:
- Quelles sessions ont exécuté la version compromise du script?
- Pendant ces sessions, à quels champs de données le script a-t-il accédé?
- Vers où les requêtes réseau ont-elles été envoyées?
- L'exfiltration s'est-elle terminée (la destination a-t-elle répondu) ou a-t-elle été interrompue?
Ce journal est également le dossier probatoire pour les décisions de notification de violation en vertu de l'Article 33 du RGPD (seuil de notification de 72 heures) et des exigences PCI DSS. Sans lui, l'hypothèse par défaut dans la plupart des cadres est que toutes les sessions exposées ont été compromises.
Remédier
La remédiation pour la compromission d'un script du navigateur comprend: supprimer ou rétablir la version compromise du script, confirmer que le point d'exfiltration de l'attaquant est bloqué au niveau réseau, évaluer quelles sessions utilisateur nécessitent une notification, et mettre à jour la ligne de base comportementale du script afin que la prochaine déviation soit détectée plus rapidement.
La révision post-incident doit évaluer si la fenêtre de détection à contention a respecté un seuil acceptable. Pour les scripts de pages de paiement en vertu des exigences PCI DSS 6.4.3 et 11.6.1, l'attente est la détection des modifications non autorisées de scripts en temps réel, et non des heures ou des jours plus tard.
Comment évaluer les plateformes pour la journalisation de l'activité des scripts du navigateur
Tous les outils de surveillance qui prétendent avoir une visibilité au niveau du navigateur n'instrumentent pas réellement le runtime du navigateur. Questions à poser lors de l'évaluation d'un produit:
| Domaine d'évaluation | Ce qu'il faut rechercher | Signal d'alarme |
|---|---|---|
| Méthode de journalisation | Agent ou SDK qui s'exécute dans le navigateur et observe l'exécution | Crawler qui simule des sessions en externe |
| Couverture | Toutes les sessions, pas un sous-ensemble échantillonné | L'échantillonnage signifie que la plupart des attaques ne sont pas journalisées |
| Apprentissage de la ligne de base | Profilage comportemental automatique par script par page | Nécessite une configuration manuelle des seuils |
| Capacité de blocage | Peut bloquer les requêtes réseau des scripts sans déploiement de code | Détection uniquement sans voie d'application |
| Rétention des journaux | Journaux indexés au niveau de la session disponibles pour enquête | Métriques agrégées uniquement, pas de replay de session |
| Preuves de conformité | Journaux exportables mappés à PCI DSS 6.4.3/11.6.1 et Article 32 du RGPD | Pas de sortie de conformité structurée |
La distinction clé est la méthode d'instrumentation. Un scanner externe visite votre page depuis un navigateur sans tête et enregistre ce qu'il observe pendant cette session artificielle. Un attaquant qui ne s'active que contre de vrais utilisateurs, une technique d'évasion courante, est invisible pour un scanner. L'instrumentation en temps d'exécution qui s'exécute dans chaque session d'utilisateur réel capture ce que les scanners manquent.
Où se positionne cside
cside est la journalisation native de l'activité des scripts du navigateur et l'application construite spécifiquement pour le risque JavaScript tiers. Elle instrumente la couche d'exécution du navigateur dans chaque session d'utilisateur réel et enregistre les six catégories décrites ci-dessus: accès au DOM, requêtes réseau, lectures de cookies et de stockage, injection dynamique de scripts, chaînes de sous-ressources et déviations comportementales par rapport aux lignes de base établies.
Lorsqu'une anomalie est détectée, cside peut bloquer les requêtes réseau du script ou le script lui-même sans nécessiter de déploiement de code. Le journal d'activité qu'elle produit est structuré à la fois pour l'enquête sur les incidents et pour les preuves de conformité en vertu de PCI DSS 6.4.3, 11.6.1 et Article 32 du RGPD.
Pour les équipes qui s'appuient actuellement sur la couverture SIEM, EDR et WAF et supposent que ces trois couches couvrent l'ensemble de la surface d'attaque: elles ne couvrent pas le runtime du navigateur. C'est la couche où opèrent Magecart, le formjacking et le skimming numérique, les compromissions de la chaîne d'approvisionnement et les scripts de détournement de session, et c'est la couche où la journalisation de l'activité des scripts et la réponse aux incidents présentent la plus grande lacune dans la plupart des stacks d'entreprise.
