Geschreven door Mike Kutlu, cside. De cijfers over betaalpagina's komen uit cside's productie-browsertelemetrie over de 14 dagen tot en met 2026-07-22, op PCI-relevante pagina's. De aanvalscontext komt uit openbare incidentrapportage en cside's eigen gepubliceerde analyse. Methodologie en beperkingen staan achteraan. Laatst beoordeeld in juli 2026.
TL;DR
- De mediane PCI-relevante betaalpagina laadt 3 unieke externe scripthostnamen. Het 90e percentiel laadt er 9, het 99e 22.
- Ongeveer 48% van de unieke scripts op die pagina's werd door een ander script geladen en niet door de eigen HTML van de pagina, en ruwweg 65% van de pagina's draagt een afhankelijkheidsketen van minstens drie stappen diep.
- Het oppervlak is gefragmenteerd. De tien grootste hostnamen dekken ongeveer 41% van de aanwezigheid op gemonitorde pagina's, maar voor 80% zijn er zo'n 100 nodig, en de staart loopt door tot voorbij 9.000.
- 91,6% van de pagina's serveerde in het venster minstens één script dat ze nooit eerder had geserveerd, met een mediaan van 8 nieuwe scripts per pagina.
- In juni 2026 zette een gecompromitteerde externe leverancier een wallet-drainer-script in de frontend van Polymarket en haalde daarmee zo'n $3 miljoen uit de wallets van gebruikers, zonder een server te hacken of een smart contract aan te raken.
Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.
Managementsamenvatting
Merchants kunnen doorgaans wel de derde partijen noemen die ze zelf aan een checkout hebben toegevoegd. Wat ze niet kunnen noemen, is de code die die derde partijen meebrengen, en dat is wat dit rapport meet.
Over de PCI-relevante checkouts die cside monitort laadt de mediane pagina 3 unieke externe scripthostnamen, wat beheersbaar klinkt. Maar 48% van de unieke scripts die op die pagina's werden waargenomen, kwam binnen via een ander script in plaats van via de eigen HTML van de pagina, en ongeveer 65% van de pagina's draagt een laadketen die minstens drie stappen van de pagina af loopt. De merchant koos de eerste stap; een leverancier, of de leverancier van een leverancier, koos de rest.
PCI DSS 6.4.3 vraagt om een inventaris van elk script op de betaalpagina, met een zakelijke rechtvaardiging per script. Aan de mediaan zijn dat zo'n 12 scripts, waar een complianceteam in een middag doorheen komt. Op het 99e percentiel zijn het er ruwweg 259, grotendeels via een keten geladen, en niemand bij de merchant is in de positie om het merendeel van die lijst te verantwoorden.
De inventaris blijft ook niet stilstaan. Over twee weken serveerde 91,6% van de gemonitorde betaalpagina's minstens één script dat ze niet eerder had geserveerd, met een mediaan van 8 nieuwe scripts per pagina. Requirement 11.6.1 vraagt om wijzigingsdetectie die minstens elke zeven dagen draait; dat is het volume waar zo'n control mee moet meekomen.
In juni 2026 injecteerde een gecompromitteerde externe leverancier een wallet-drainer in de frontend van Polymarket en haalde daarmee zo'n $3 miljoen uit de wallets van gebruikers. Serverzijdig werd niets gehackt en de contracten bleven onaangeroerd; de hele compromittering vond plaats in de browser.
| Metriek (14 dagen tot en met 2026-07-22) | Waarde |
|---|---|
| Externe scripthostnamen per pagina (mediaan / p90 / p99) | 3 / 9 / 22 |
| Unieke scripts per pagina (mediaan / p90 / p99) | 12 / 46 / 259 |
| Scripts geladen door een ander script | 48% |
| Pagina's met een keten van 3+ stappen | 65% |
| Pagina's die in het venster een nieuw script zagen | 91,6% |
Elke telling betreft een echte derde partij. De eigen first-party scripts van de merchant en cside's eigen infrastructuur zijn uitgesloten.
Wat een betaalpagina daadwerkelijk laadt
De inventaris die 6.4.3 verlangt begint bij een keuze van eenheid, en de twee beschikbare eenheden geven heel verschillende antwoorden.
Gemeten op hostnaamniveau is de mediane pagina bescheiden: 3 unieke externe scripthostnamen, 9 op het 90e percentiel, 22 op het 99e. Gemeten als losse scripts dragen dezelfde pagina's een mediaan van 12, een 90e percentiel van 46 en een 99e percentiel rond de 259. Een hostnaamtelling vertelt je met hoeveel verschillende partijen de pagina praat; de scripttelling is wat een assessor je zal vragen op te sommen.
De kop van de verdeling is vertrouwd en overweldigend Google:
| Rang | Externe hostnaam | Aandeel van gemonitorde betaalpaginaconfiguraties |
|---|---|---|
| 1 | www.googletagmanager.com (Google Tag Manager) | 39,7% |
| 2 | www.gstatic.com (statische content van Google) | 19,4% |
| 3 | www.google.com (reCAPTCHA, accounts, andere Google-diensten) | 17,1% |
| 4 | connect.facebook.net (Meta Pixel) | 13,0% |
| 5 | pagead2.googlesyndication.com (Google Ads) | 11,4% |
| 6 | www.google-analytics.com (Google Analytics) | 10,6% |
| 7 | googleads.g.doubleclick.net (Google Ads / DoubleClick) | 9,5% |
| 8 | static.cloudflareinsights.com (Cloudflare) | 9,2% |
| 9 | www.blogger.com (Google) | 9,2% |
| 10 | apis.google.com (Google API's) | 7,9% |
Die tien hostnamen zijn samen goed voor ongeveer 41% van de aanwezigheid op gemonitorde pagina's. Om 80% te halen zijn ruwweg 100 hostnamen nodig, en daarachter ligt een staart van meer dan 9.000 unieke externe hostnamen. Op een Herfindahl-Hirschman-index scoort het oppervlak ongeveer 0,023 op een schaal van 0 tot 1, en dat is een gefragmenteerde markt.
Voorbij de kop lijken checkouts niet langer op elkaar, en er bestaat geen gedeelde lijst met bekende verdachten waar een assessor of een leveranciersrisicoteam mee uit de voeten kan.
De helft ervan werd door een ander script geladen
De tellingen hierboven zeggen niets over wie de code op de pagina heeft gezet, en precies daar begint het complianceprobleem.
Wanneer cside de unieke scripts op gemonitorde betaalpagina's indeelt naar de manier waarop ze zijn geladen, blijkt 48% aantoonbaar door een ander script te zijn binnengehaald. De overige 52% dook op zonder geregistreerde ouder, wat betekent dat ze door de eigen HTML van de pagina zijn geladen of dat hun oudermetadata ontbrak.
Gemeten in stappen vanaf de pagina naar buiten haalt ongeveer 65% van de pagina's een keten van drie stappen: de pagina laadt een script, dat script laadt een tweede, en de tweede laadt een derde. Die meting is afgetopt op drie stappen, dus de werkelijke ketens op die pagina's kunnen dieper lopen. Slechts zo'n 31% van de pagina's stopt bij één stap.
| Stap | Contactpunt | Vangt | Mist | Samenvatting |
|---|---|---|---|---|
| HTML van de pagina | Merchant | Scripts die het team toevoegde; Leveranciers met contract; Zichtbaar in de tag manager | Wat die scripts daarna laden | Slechts 31% van de pagina's stopt bij deze stap |
| Eerste stap | Leverancier | De leverancier met wie je tekende | Wat die leverancier daarna laadt; Updates zonder aankondiging | 48% van de scripts komt via een ander script |
| Tweede stap+ | Subleverancier | — | In geen enkele inventaris; Geen contract met de merchant; Geen wijzigingsmelding | 65% van de pagina's komt minstens tot hier |
Een tag manager toevoegen is één beslissing van de merchant. Alles wat die container daarna laadt, is de beslissing van iemand anders, genomen zonder aankondiging, op de pagina die kaartgegevens verwerkt.
Google Tag Manager is de meest voorkomende injector, en injecteert vooral Google
Google Tag Manager is veruit de meest voorkomende derde partij op betaalpagina's, aanwezig op ongeveer 40% van de gemonitorde PCI-configuraties en ruwweg 38% van de registreerbare domeinen. Het is ook de meest voorkomende injector.
Zulke concentratie leest als supply-chain-risico, tot je kijkt naar wat GTM eigenlijk laadt. Van alles wat GTM waarneembaar op betaalpagina's injecteerde, was ongeveer 93% Google's eigen advertentie- en analyticsstack. Ongeveer 7% wees naar een werkelijk niet-Google derde partij.
Het grootste deel van de blootstelling is dus een Google-op-Google-afhankelijkheid. Dat blijft blootstelling, maar dan aan een partij waarmee de merchant al een contract heeft. De 7% is het onvoorspelbare deel: willekeurige code van derden die via een vertrouwde container op een betaalpagina belandt, gekozen door wie toegang heeft tot die container en niet door wie verantwoordelijk is voor PCI-compliance.
Server-side tagging zou dit afzwakken, en vrijwel niemand gebruikt het. Minder dan vijf op elke honderdduizend GTM-verzoeken op gemonitorde betaalpagina's droeg een server-side prefix.
Juni 2026: de wallet-drainer bij Polymarket
In juni 2026 compromitteerden aanvallers een externe leverancier en injecteerden ze een wallet-drainer-script in de frontend van voorspellingsmarktplatform Polymarket. Het script haalde ruwweg $3 miljoen uit de wallets van een klein aantal gebruikers. De smart contracts en de onderliggende blockchain kwamen er niet aan te pas: de diefstal werd uitgevoerd in de browser, via een extern script dat het platform al maanden vertrouwde.
Er was geen betaalformulier om af te tappen, dus gedroeg de geïnjecteerde code zich niet als een kaartskimmer. Ze opereerde binnen de interface en stuurde wallet-goedkeuringsverzoeken via Polymarkets eigen UI. Gebruikers keurden die goed omdat er niets aan de interface verkeerd oogde.
De crypto-details zijn bijzaak. Wat overblijft is een vertrouwd extern script, meerdere stappen verwijderd van alles wat het platform bewust heeft gekozen, dat in de browser kwaadaardig werd, en hetzelfde mechanisme werkt net zo goed tegen kaartvelden op een checkout. cside's volledige technische analyse staat in Binnen de client-side supply-chain-aanval van $3M op Polymarket.
De meeste meldingen gaan over verouderde bibliotheken
Wanneer cside's scriptmonitoring afgaat op een PCI-relevante pagina, is de verdeling scheef.
| Meldingscategorie | Aandeel |
|---|---|
| Bekende kwetsbaarheden in JavaScript-bibliotheken (CVE-gematchte dependencies) | 88% |
| Bekend kwaadaardige scripts en malware | 9% |
| Overige of niet-gecategoriseerde meldingen over scriptintegriteit | 3% |
Ruwweg negen op de tien meldingen zijn verouderde bibliotheken met gepubliceerde CVE's: een patch- en inventarisprobleem, en daar zit het meeste dagelijkse werk. De 9% die bekend kwaadaardig is, heeft een kritieke ernst, en die meldingen komen binnen via hetzelfde monitoringkanaal als de ruis uit de bibliotheken. Elk filter dat breed genoeg is om de andere 91% stil te krijgen, verbergt ook die 9%.
Wat je eraan kunt doen
- Inventariseer wat je tags laden. Een lijst van wat je team heeft toegevoegd is geen 6.4.3-inventaris wanneer 48% van wat er draait door iets anders is geladen. Vraag je directe leveranciers wat zij verderop binnenhalen, en beschouw elke pagina waar je dat niet kunt beantwoorden als ongemeten.
- Reken op het 99e percentiel. Een inventaris van twaalf scripts past in een spreadsheet; bij 259 heb je tooling en een aangewezen eigenaar nodig. Zoek uit welke van je checkoutpagina's de uitschieter is voordat een assessor dat doet.
- Dimensioneer wijzigingsdetectie op het werkelijke tempo. Negen op de tien pagina's zien binnen twee weken een nieuw script, met een mediaan van 8. Een control die elke zeven dagen draait en voor elke wijziging een handmatige review aanmaakt, loopt al in de eerste cyclus achter, dus bepaal vooraf wat automatisch wordt afgehandeld.
- Bewaak gedrag tijdens uitvoering. Een drainer of skimmer die drie stappen diep in een keten zit, duikt niet op in een statische scan van wat je dacht te installeren, en in het geval van Polymarket viel er serverzijdig sowieso niets te melden.
Methodologie en notities over datahygiëne
- Venster en populatie. Alle cijfers over betaalpagina's komen uit de 14 dagen tot en met 2026-07-22, afkomstig van pagina's die in cside's monitoringconfiguratie als PCI-relevant zijn aangemerkt. De populatie is cside's gemonitorde klantenbestand in e-commerce, ticketing, non-profits, horeca en financiële dienstverlening. Het is geen willekeurige steekproef van het web, dus de verdeling kan afwijken ten opzichte van het internet als geheel. De richting van die afwijking wordt hier niet gekarakteriseerd.
- Definitie van derde partij. "Derde partij" sluit elke resource uit die wordt geserveerd vanaf het eigen registreerbare domein van de betaalpagina, en sluit cside's eigen infrastructuur uit (
csidetm.com,csidefd.com,cside.com,cside.dev,client-side.dev). - Hostnamen zijn geen leveranciers. De tellingen per pagina in dit rapport zijn unieke externe scripthostnamen en unieke scripts, geen genormaliseerde leveranciersbedrijven. Eén leverancier serveert doorgaans vanaf meerdere hostnamen, dus hostnaamtellingen liggen hoger dan leverancierstellingen. Waar leveranciersentiteiten apart worden geteld, is het oppervlak kopzwaarder: de tien grootste leveranciersentiteiten dekken ongeveer 51% van de waarnemingen op tenant- en domeinniveau, tegen 41% voor de tien grootste hostnamen.
- Bereik wordt per configuratie gemeten. De tabel met hostnaambereik telt unieke gemonitorde betaalpaginaconfiguraties, een niveau dat dicht bij het registreerbare domein ligt maar er niet gelijk aan is. Gemeten per registreerbaar domein is het bereik van Google Tag Manager ongeveer 38% in plaats van 39,7%. De 41% van de top tien is weer een andere eenheid: het aandeel in de aanwezigheid op gemonitorde pagina's.
- Classificatie van de lader. Een uniek script telt als kettinggeladen wanneer het is waargenomen met een niet-lege ouder. De resterende bucket combineert scripts die via de HTML van de pagina zijn geladen met scripts waarvan de oudermetadata ontbrak; die twee zijn met de beschikbare velden niet te scheiden, dus 52% is een bovengrens voor scripts die werkelijk door de pagina zijn geladen.
- Ketendiepte is afgetopt. De diepte wordt gemeten in stappen vanaf de pagina en is afgetopt op drie. Pagina's in de bucket "3+" kunnen diepere ketens dragen die niet zijn gemeten, dus de dieptecijfers zijn een ondergrens. De diepte is verankerd op pagina's die minstens één laadverbinding vanaf de paginaroot blootgeven; pagina's zonder zo'n verbinding zijn uitgesloten.
- Benaderende tellers. Tellingen van unieke entiteiten gebruiken een benaderende cardinaliteitsschatting met ruwweg een halve procent foutmarge. Aandelen en indexwaarden erven die foutmarge.
- Meldingscategorieën. De aandelen per categorie komen uit cside's pijplijn voor scriptmeldingen over hetzelfde venster, gegroepeerd naar kwetsbaarheidsklasse. Absolute aantallen meldingen en sites worden bewust niet gepubliceerd.
- k-anonimiteit. Elke uitsplitsing met minder dan 10 tenants in een bucket wordt onderdrukt om onbedoelde onthulling van één enkele merchant te voorkomen.
- Aanvalscontext. De Polymarket-casus is gebaseerd op openbare incidentrapportage en cside's eigen gepubliceerde analyse. Het is geen interne detectietelling.
- Bevestigende bronnen. Sansec publiceert Magecart-onderzoek met benoemde families, Verizon's DBIR volgt patronen van betaalkaartlekken, de PCI Security Standards Council publiceert de huidige PCI DSS 4.0.1-vereisten, en OWASP en MITRE ATT&CK leveren de taxonomie waarnaar de categorieën van dit rapport verwijzen.
Rapportgegevens actueel per juli 2026. cside is een client-side beveiligingsplatform dat JavaScript monitort op de webproperties van klanten. Voor meer, zie cside.com.
