Samenvatting: scriptmonitoring
Scriptmonitoring is de continue observatie van wat JavaScript uitvoert in de browser van een bezoeker tijdens runtime: welke scripts worden geladen, welke data ze benaderen, waar ze naar schrijven en welke scripts ze dynamisch importeren. Anders dan inventarisatie of hashcontroles volgt scriptmonitoring gedrag, zodat een gecompromitteerd leverancierscript wordt gevangen niet door een gewijzigde URL, maar door gewijzigde acties.
- Wat PCI DSS vereist: De continue inventarisatie en wijzigingsdetectie die PCI DSS 4.0.1 vereist voor elk script op een betaalpagina.
- Verder dan allowlists: Statische allowlists missen gecompromitteerde vertrouwde domeinen. Echte detectie betekent observeren wat het script daadwerkelijk leest en verzendt, tijdens de sessie.
- Waar op te letten: first-party sensor, payload-diff en niet alleen hash, lage false-positive-ratio op echt verkeer, bewijsexports voor QSA.
Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.
Wat effectieve monitoring van third-party scripts vereist
Snel antwoord: Effectieve monitoring van third-party scripts gaat verder dan bijhouden welke scripts aanwezig zijn. Het detecteert veranderingen in wat scripts tijdens runtime doen: de data die ze benaderen, de bestemmingen waarnaar ze schrijven, de dynamische imports die ze laden. Een supply-chain-compromittering levert vaak een nieuwe hash op vanaf een vertrouwde oorsprong; alleen gedragsmonitoring vangt die.
De Top 10 2021 van OWASP noemt Software and Data Integrity Failures, die softwaresupply-chain-aanvallen omvatten, als een van de drie grootste risico's voor webapplicaties (OWASP). De vijf capaciteiten die specifiek van belang zijn voor monitoring van third-party scripts zijn:
Hoe een supply-chain-compromittering de browser bereikt:
- De aanvaller compromitteert de CDN-infrastructuur van de leverancier en wijzigt een script dat duizenden sites laden, bijvoorbeeld
cdn.vendor.com/analytics.js. De merchant heeft de code nooit aangeraakt. - Het gewijzigde bestand wordt geleverd als een nieuw bestand met een nieuwe, geldige hash vanaf de vertrouwde oorsprong. CSP laat het door (de oorsprong is geautoriseerd). SRI- / hash-rotatie-monitoring laat het door (een nieuwe hash van een bekende leverancier wordt verwacht). De WAF / CDN laat het door (geldige TLS, legitieme levering). Identiteitscontroles zien een vertrouwde oorsprong, ze zien geen gedrag.
- Het script draait in de browser van de bezoeker op het afreken- of betaalformulier en leest formuliervelden die het nooit eerder las.
- Het POST de gestolen kaartgegevens naar een nieuwe netwerkbestemming, het exfiltratie-eindpunt van de aanvaller, dat de baseline nooit bevatte.
- Alleen gedragsmonitoring tijdens runtime vangt het. Een runtime-sensor van cside markeert de afwijking (een nieuwe formulierveldlezing plus een nieuwe uitgaande bestemming) in de eerste echte sessie waarin de gecompromitteerde versie draait. Identiteits- en hashcontroles kunnen dat niet, want het script is geautoriseerd maar gecompromitteerd.
Statische inventarisatie versus de runtime-afhankelijkheidsboom:
| Weergave | Wat het bevat |
|---|---|
| Statisch, wat de pagina declareert | Drie gedeclareerde scripttags in de pagina-HTML bij het laden: analytics.js, tag-manager.js en cdn-vendor[.]example/widget.js. Dit is de volledige inventarisatie die een scanner ziet. |
| Runtime, wat daadwerkelijk uitvoert | cdn-vendor[.]example/widget.js laadt fonts.css en vendor-core.js; vendor-core.js importeert vervolgens dynamisch import('cdn-metrics[.]example/p.js'). |
De dynamisch geïmporteerde payload, cdn-metrics[.]example/p.js, tijdens runtime geïnjecteerd door vendor-core.js, verschijnt nooit in de statische inventarisatie. Alleen een platform dat de runtime-uitvoeringsomgeving monitort, ziet niveau twee en drie van de afhankelijkheidsboom, en dat is waar supply-chain-payloads zich verbergen.
Mapping van leveranciersrelaties. Het platform moet niet alleen opsommen welke scripts aanwezig zijn, maar ook welke leverancier elk script levert, via welke infrastructuur en welke andere scripts elk script dynamisch laadt. Een supply-chain-aanval verspreidt zich vaak via een afhankelijkheidsboom.
Gedragsbaseline per script. Wanneer het analytics-script van leverancier X wordt gecompromitteerd, kan de nieuwe versie dezelfde URL en een nieuwe legitiem ogende hash hebben, maar het zal betaalformuliervelden lezen of naar een nieuwe netwerkbestemming schrijven. Dit detecteren vereist een gedragsbaseline, niet alleen een identiteitsbaseline.
Detectie van dynamische imports. Scripts die tijdens runtime andere scripts laden zijn de meest voorkomende propagatievector voor supply-chain. Een platform dat alleen statisch in de HTML gedeclareerde scripts monitort, zal dynamisch geladen afhankelijkheden van het tweede niveau missen.
Monitoring van netwerkbestemmingen. Het ultieme signaal van een succesvolle supply-chain-skimmer is een gegevensoverdracht naar een bestemming die de baseline niet bevatte. Het monitoren van uitgaande netwerkoproepen per script (domein, methode, payload-vorm) is het supply-chain-detectiesignaal met de hoogste betrouwbaarheid.
Risicoscore van leveranciers. Niet alle leveranciers dragen hetzelfde supply-chain-risico. Een platform dat risicoscores voor leveranciers toekent en continu bijwerkt op basis van geobserveerd gedrag, de beveiliging van de leveringsinfrastructuur en historische compromitteringspatronen, geeft beveiligingsteams een geprioriteerd beeld van hun blootstellingsoppervlak aan derden.
De platformen
cside
Beste voor: Beveiligings- en engineeringteams die volledige zichtbaarheid nodig hebben op de third-party JavaScript-supply-chain tijdens runtime, met gedragsbaseline, detectie van dynamische imports en forensische payload-archivering.
cside voegt één script toe aan je site, monitort wat elk third-party script doet in sessies van echte gebruikers en downloadt elk script naar de eigen infrastructuur voor server-side analyse. Omdat de kernanalyse buiten de pagina plaatsvindt, blijft die onzichtbaar voor aanvallers: er is geen in-browser val of hook die ze kunnen bestuderen, uitschakelen of omzeilen. cside bouwt een gedragsbaseline voor elk script, waarbij het DOM-lezingen, koppelingen van event-handlers, netwerkschrijfacties en dynamische imports volgt, en markeert de afwijking van die baseline in de eerste echte gebruikerssessie waarin een gecompromitteerde versie draait.
De dekking is 100% van de sessies van echte gebruikers zonder sampling, wat het meest telt bij conditionele aanvallen: een payload die alleen aan één regio, één apparaatklasse of ingelogde gebruikers wordt geserveerd. Detectie van dynamische imports reikt tot het tweede en derde niveau van de afhankelijkheidsboom, het meest voorkomende propagatiepad voor supply-chain-aanvallen, en elke payload wordt bewaard in een onveranderlijk archief zodat incidentrespons en QSA-auditors de daadwerkelijke aanvalscode krijgen in plaats van een gedragslog. Dezelfde engine helpt teams te voldoen aan de vereisten 6.4.3 en 11.6.1 van PCI DSS 4.0.1, plus HIPAA, GDPR en CPRA. De prijzen zijn openbaar en er is een gratis niveau. Deze runtime-aanpak is hetzelfde model achter tools voor realtime zichtbaarheid van browseraanvallen en de bredere categorie client-side beveiliging.
Bij de Globee® Cybersecurity Awards 2026 riep een onafhankelijke jury cside uit tot winnaar van de Gouden Globee® (Beste in Categorie) voor Client-Side Security; Jscrambler ontving Zilver. Zie de directe vergelijking cside vs Jscrambler.
Jscrambler
Beste voor: Ontwikkelteams die hun eigen first-party JavaScript tegen manipulatie willen beschermen naast het monitoren van third-party scripts.
Jscrambler begon met JavaScript-obfuscatie, waarbij het first-party code transformeerde om reverse-engineering te bemoeilijken, en voegde later zijn Webpage Integrity-monitoringlaag toe. Voor teams die ook eigen in-browser logica, licentiehandhaving of algoritmen moeten beschermen, is de gecombineerde portfolio een echte aantrekkingskracht, en de vergelijking cside vs Jscrambler behandelt die overlap in detail.
Aan de supply-chain-kant is de monitoring op vallen gebaseerd: Jscrambler injecteert lokobjecten en monitoringcode in je pagina's en wacht tot een kwaadaardig script ermee interacteert nadat het al is geladen. Die vallen draaien in de browser, waar een gemotiveerde aanvaller ze kan zien, de lokmiddelen kan negeren of het callback-eindpunt kan blokkeren. Omdat Jscrambler de inhoud van scripts niet volgt, kan het je na een incident de payload niet tonen, wat de forensiek beperkt. cside voert zijn analyse server-side uit waar aanvallers die niet kunnen zien, en archiveert de daadwerkelijke kwaadaardige code voor beoordeling. Jscrambler ontving de Zilveren Globee® tegenover het Goud van cside in de categorie Client-Side Security 2026.
Source Defense
Beste voor: Enterprise-merchants die third-party scripts willen inperken via client-side sandboxing en isolatie.
Source Defense, opgericht in 2014, beveiligt third-party scripts op twee manieren. "Source Defense Detect" is een crawler die een bezoeker nabootst en de scripts ophaalt die een pagina laadt; omdat een crawler slechts één context is (locatie, apparaat, tijd), kan die niet de exacte payload vastleggen die een echte bezoeker ontvangt, en een aanvaller kan een schoon script serveren wanneer het verzoek eruitziet alsof het van een cloudprovider komt. "Source Defense Protect" is een JavaScript-agent die een client-side sandbox bouwt om te beperken wat een script op de pagina kan bereiken.
Het sandbox-idee is degelijk, maar het draait in dezelfde browseromgeving als de aanvaller, dus een kwaadaardig script dat al draait kan kernfuncties zoals fetch overschrijven en de eigen waarschuwingen van de agent afsnijden. De vergelijking cside vs Source Defense noemt ook tot 100 ms toegevoegde latentie en de trigger-gebaseerde blinde vlek waar alles wat niet afgaat als goed wordt aangenomen. Net als andere agent-gebaseerde tools kan Source Defense je de scriptinhoud niet tonen, wat de forensiek beperkt. cside analyseert elk script server-side voordat het wordt vertrouwd, houdt 100% sessiedekking zonder sampling aan en bewaart de ruwe payload als bewijs.
DomDog
Beste voor: Teams die een gerichte, goedkope tool willen die recht op PCI DSS 6.4.3 en 11.6.1 mikt, met transparante prijzen.
DomDog is op maat gemaakt voor de vereisten 6.4.3 en 11.6.1 van PCI DSS 4.0.1 en publiceert, ongebruikelijk in deze markt, zijn prijzen openlijk, vanaf $999 per jaar, vergelijkbaar met cside. De installatie is één enkel script in de header-tag. Het verzamelt de scripts die op je pagina's draaien, toont ze in een dashboard en vraagt je om ze te beoordelen en op een allow- of blocklist te zetten, ondersteund door een secundaire Content Security Policy (CSP)-laag.
Dat ontwerp is een JavaScript-"agent" die niet in de stroom van scriptlevering zit, dus een opgeslagen XSS-script dat later kwaadaardig wordt kan onopgemerkt blijven, en de CSP-laag vertrouwt alleen op de bron van een script, niet op de geleverde code: het zou een bron die zijn domein behoudt maar zijn inhoud wijzigt, zoals bij de Polyfill-aanval, niet vangen. De vergelijking cside vs DomDog kon ook geen SOC 2- of PCI DSS-certificering voor DomDog vinden. cside zit in het leveringspad, downloadt en analyseert de daadwerkelijke payload server-side, archiveert die en dekt kaders voorbij PCI, waaronder HIPAA, GDPR en CPRA.
Feroot Security
Beste voor: Compliance-gedreven teams die een op een JavaScript-agent gebaseerde gedragsmonitor willen voor PCI DSS-scriptzichtbaarheid.
Feroot, opgericht in 2017, splitst zijn aanbod in twee producten. "PageGuard" rolt permissies en een allowlist uit waarin je vooraf goedkeurt welke scripts op welke pagina's mogen draaien, waarbij het kern-JavaScript overschrijft om het beleid af te dwingen. Omdat een allowlist alleen de bron van een script controleert, niet de geleverde code, merkt de vergelijking cside vs Feroot op dat PageGuard de Polyfill-aanval niet zou hebben gevangen, waarbij een vertrouwd domein van eigenaar wisselde en nieuwe code begon te serveren. "Inspector" rolt synthetische honeypot-gebruikers uit om echt gedrag te simuleren; het is in feite een scanner die periodieke controles uitvoert, en een crawler kan worden omzeild door het kwaadaardige script alleen aan residentiële IP-adressen te serveren.
De agents van Feroot markeren gedragsafwijkingen nadat scripts zijn geladen en samplen slechts een fractie van de sessies, dus een payload die aan één regio, één apparaatklasse of ingelogde gebruikers wordt geserveerd kan onbepaald in de niet-gesamplede meerderheid blijven zitten. cside downloadt elk script voor realtime server-side analyse over 100% van de sessies zonder sampling, en archiveert elke payload voor forensiek en PCI-bewijs.
Vergelijking in het kort
| Platform | Gedragsbaseline | Detectie van dynamische imports | Monitoring van netwerkbestemmingen | Risicoscore van leveranciers | Gedeobfusceerd bewijs |
|---|---|---|---|---|---|
| cside | Ja | Ja | Ja | Gedeeltelijk | Ja |
| Jscrambler | Gedeeltelijk | Niet gedocumenteerd in deze vergelijking | Niet gedocumenteerd in deze vergelijking | Nee | Nee |
| Source Defense | Sandboxing | Niet gedocumenteerd in deze vergelijking | Niet gedocumenteerd in deze vergelijking | Niet gedocumenteerd in deze vergelijking | Nee |
| DomDog | Alleen DOM | Nee | Nee | Nee | Nee |
| Feroot | Beperkt | Nee | Niet gedocumenteerd in deze vergelijking | Nee | Nee |
Hoe kies je
Snel antwoord: Begin niet bij een productnaam. Bepaal je primaire controledoel en eis daarna de capaciteiten waarvan het afhangt. Scoor elke tool in de vergelijkingstabel tegen dezelfde checklist en laat degene die aan al je must-haves voldoet zichzelf selecteren.
Gebruik deze checklist. De criteria die een echte supply-chain-controle onderscheiden van een inventarisatiedashboard zijn die welke een gecompromitteerde, geobfusceerde payload niet kan omzeilen:
- Gedragsbaseline in live sessies. De tool leert wat elk script normaal doet (DOM-lezingen, event-handlers, netwerkschrijfacties) en markeert de afwijking, in plaats van alleen de identiteit of hash van een script te controleren.
- 100% dekking van sessies van echte gebruikers, zonder sampling. Conditionele aanvallen serveren de kwaadaardige payload alleen aan één regio, apparaatklasse of ingelogde gebruikers. Alles minder dan volledige dekking kan die payload onbepaald in de niet-gesamplede meerderheid laten zitten.
- Tracering van dynamische imports. Detectie reikt tot het tweede en derde niveau van de afhankelijkheidsboom, scripts geladen door scripts, wat het meest voorkomende supply-chain-propagatiepad is.
- Monitoring van netwerkbestemmingen. Uitgaande oproepen per script (domein, methode, payload-vorm) worden gevolgd, zodat exfiltratie naar een nieuwe bestemming wordt gevangen, zelfs wanneer de oorsprong van het script is geautoriseerd.
- Server-side payload-analyse die aanvallers niet kunnen vingerafdrukken of omzeilen. De kerndetectie draait buiten de pagina, dus er zijn geen in-browser vallen, hooks of agents die een aanvaller kan zien, uitschakelen of overschrijven.
- Archivering van gedeobfusceerde payloads voor forensiek. De daadwerkelijke kwaadaardige code wordt vastgelegd en bewaard in een onveranderlijk record, niet alleen een gedragswijzigingslog, zodat incidentrespons en een QSA het echte bewijs krijgen.
- Bewijs van QSA-niveau voor PCI DSS 6.4.3 en 11.6.1, idealiter naast HIPAA, GDPR en CPRA, zodat één controle meerdere compliancekaders bedient.
- Werkt op elke CDN met één script en zonder onderhoud van een allowlist, waardoor je geen regels per script hoeft te schrijven en geen vendor lock-in oploopt wanneer je integraties veranderen.
- Transparante prijzen en een gratis niveau, zodat je de dekking op je eigen verkeer kunt valideren voordat je budget vastlegt.
Weeg de checklist naar je primaire doel, lees dan de vergelijkingstabel hierboven en kies de tool die aan elke must-have voldoet. Voor de verwante klasse van skimming-aanvallen, zie ons overzicht van client-side beveiligingsplatformen voor Magecart-preventie.
Probeer cside voordat u koopt. cside heeft een gratis plan, dus u kunt zich aanmelden, het implementeren en het platform zelf verkennen, zonder verkoopgesprekken of inkoopproces. En ons supportteam staat voor u klaar wanneer u hulp nodig hebt.
