TL;DR: Magento PCI-compliance
- Magento regelt requirements 6.4.3 en 11.6.1 niet voor je. Elk script op je betaalpagina heeft een inventarisregel, een zakelijke onderbouwing en doorlopende integriteitsmonitoring nodig.
- ASV-scans dekken requirement 11.3.2. Ze detecteren geen JavaScript-dreigingen op betaalpagina's. Merchants die de ASV-scan als hun voornaamste beveiligingscontrole zien, missen precies de controls die PCI DSS 4.0.1 vraagt voor client-side risico.
- De meest voorkomende aanvalsroute tegen Magento in 2024 en 2025 is exfiltratie via WebSockets vanuit gecompromitteerde extensies. Die omzeilt CSP, omzeilt netwerkmonitoring en is alleen zichtbaar voor een tool die de browserruntime rechtstreeks observeert.
Wat is Magento PCI-compliance?
Magento-webshops zijn niet automatisch PCI DSS-compliant. Magento Commerce Cloud regelt een deel van de controls op infrastructuurniveau, maar de merchant blijft verantwoordelijk voor het beveiligen van betaalpagina's tegen client-side aanvallen. Requirements 6.4.3 en 11.6.1 van PCI DSS 4.0.1 eisen dat alle scripts op betaalpagina's worden geïnventariseerd, geautoriseerd en gemonitord op integriteitswijzigingen. Die controls levert Magento niet standaard, welke betaalextensie je ook gebruikt.
Het gangbare misverstand: merchants gaan ervan uit dat een gecertificeerde betaalextensie, of het uitbesteden van de betaalverwerking aan een gehoste betaalpagina, genoeg is voor PCI DSS. Het verkleint de scope, maar heft die niet op. Elke Magento-pagina die checkoutfunctionaliteit laadt, of die in de cardholder data environment terechtkomt doordat ze scripts van derden laadt, valt binnen de scope van requirements 6.4.3 en 11.6.1.
Een typische Magento-checkout laadt trackingpixels, analytics-tags, A/B-testtools, affiliate-scripts, chatwidgets en betaalbibliotheken. Elk daarvan valt binnen de scope. Elk daarvan heeft een inventarisregel met zakelijke onderbouwing nodig. Elk daarvan moet tussen assessments door worden gemonitord op integriteitswijzigingen.
PCI DSS-requirements die Magento-merchants vaak missen
Requirement 6.4.3: scriptinventaris en autorisatie. Elk script dat op een betaalpagina wordt geladen, moet geïnventariseerd zijn. De inventaris moet de zakelijke onderbouwing van elk script vastleggen, bevestigen dat het script geautoriseerd is en een methode bevatten om te controleren of de integriteit ervan niet is veranderd. Een statische lijst in een spreadsheet voldoet niet: de inventaris moet de actuele staat van de betaalpagina weerspiegelen, want scripts veranderen.
Requirement 11.6.1: detectie van manipulatie op de betaalpagina. De merchant moet een mechanisme hebben dat ongeautoriseerde wijzigingen in HTTP-headers en in de inhoud van de betaalpagina detecteert, en dat het verantwoordelijke team binnen een vastgestelde termijn waarschuwt. Een periodieke handmatige review voldoet niet. Het mechanisme moet in staat zijn om een nieuw script, een gewijzigd bestaand script of een aangepaste HTTP-header tussen twee reviewrondes te detecteren.
Beide requirements werden verplicht op 2025-03-31 en worden inmiddels actief getoetst. Heeft je Magento-webshop geen tool die doorlopend bewijs voor deze requirements produceert, dan loopt je volgende PCI DSS-assessment risico.
Wat is een Approved Scanning Vendor (ASV)?
Een Approved Scanning Vendor (ASV) is een bedrijf dat door de PCI SSC gecertificeerd is om externe vulnerability scans uit te voeren, zoals PCI DSS requirement 11.3.2 vraagt. ASV-scans testen netwerkcomponenten die vanaf internet bereikbaar zijn op bekende kwetsbaarheden. Ze detecteren geen client-side JavaScript-dreigingen op betaalpagina's, geen ongeautoriseerde scripts van derden en niet de gedragsafwijkingen waar requirements 6.4.3 en 11.6.1 over gaan. Een geslaagde ASV-scan betekent niet dat je Magento-checkout beschermd is tegen Magecart-achtige aanvallen.
Wat ASV-scans wel doen: je publieke IP-adressen en domeinen aftasten op bekende CVE's, open poorten, verkeerd geconfigureerde services en kwetsbaarheden op netwerkniveau. Een schoon ASV-rapport bevestigt dat de perimeter van je servers geen bekende, van buitenaf detecteerbare exploiteerbare kwetsbaarheden heeft.
Wat ASV-scans niet doen: JavaScript analyseren dat op je betaalpagina's draait, scripts opsporen die er bij de vorige scan nog niet waren, controleren of scripts van derden zijn gewijzigd sinds hun laatste goedkeuring, of observeren welke data scripts naar externe endpoints sturen tijdens een echte bezoekerssessie.
Dat gat is geen kritiek op ASV-scans. Het beschrijft waar de tool voor bedoeld is. De compliance-controls die client-side JavaScript-dreigingen afdekken zijn 6.4.3 en 11.6.1, niet 11.3.2. Een Magento-webshop kan elke kwartaalscan doorstaan terwijl er een gecompromitteerd script draait dat op datzelfde moment kaarthoudergegevens weglekt.
De Magento-aanvalsroute die ASV-scans niet kunnen zien
cside volgt de actieve TTP's tegen Magento-merchants. Het meest verfijnde aanvalspatroon dat we in 2024 en 2025 zagen, gebruikt WebSocket-verbindingen voor exfiltratie in plaats van gewone HTTP-requests.
Waarom WebSockets langs traditionele verdediging glippen:
Klassieke Magecart-aanvallen lekken data weg via HTTP POST-requests naar domeinen van de aanvaller. CSP-directives als connect-src kunnen die blokkeren zolang het domein van de aanvaller niet op de allowlist staat. Netwerkmonitoring ziet de uitgaande POST en kan die markeren.
WebSocket-verbindingen via het wss://-protocol werken anders. Veel CSP-configuraties beperken WebSocket-origins niet apart van HTTP-origins. Monitoringtools die op HTTP-verkeer gericht zijn, zien wss://-verbindingen soms helemaal niet. De aanvaller houdt een permanent tweerichtingskanaal open naar de browser van het slachtoffer, kan geïnjecteerde scripts onderweg aanpassen zonder een nieuwe pagelaad te veroorzaken, en kan kaarthoudergegevens continu wegsluizen in plaats van in losse POST-requests.
De toegangsweg: CosmicSting (CVE-2024-34102), openbaar gemaakt in juni 2024, liet ongeauthenticeerde aanvallers serverbestanden lezen op Adobe Commerce- en Magento-installaties, inclusief configuratiebestanden met databasegegevens en API-sleutels. Met die gegevens in handen injecteerden aanvallers de WebSocket-skimmer rechtstreeks in Magento-betaalpagina's. De patch voor CVE-2024-34102 sluit de eerste toegangsweg. Hij verwijdert geen scripts die al geïnjecteerd zijn. Merchants die de CVE patchten maar hun betaalpagina-scripts niet controleerden op sporen van na de exploitatie, serveren de skimmer mogelijk nog steeds.
De enige detectielaag die deze aanval oppikt, is een laag die de browserruntime rechtstreeks instrumenteert: zien welke scripts draaien in echte bezoekerssessies, welke API-calls ze doen en waar ze data naartoe sturen, in real time, bij elke sessie.
Hoe cside Magento-checkouts beschermt
cside wordt uitgerold als één first-party JavaScript-snippet op je Magento-betaalpagina's. Het monitort de browserruntime van elke echte bezoekerssessie en produceert doorlopend bewijs voor requirements 6.4.3 en 11.6.1.
Voor requirement 6.4.3: cside houdt een levende scriptinventaris bij van elk script dat op een gemonitorde pagina laadt, inclusief het veld voor zakelijke onderbouwing, de autorisatiestatus en de integriteitshash bij elke laadbeurt. Zodra er een nieuw script verschijnt of een bestaand script verandert, werkt de inventaris zich bij en gaat er een alert af.
Voor requirement 11.6.1: cside detecteert wijzigingen in scripts en HTTP-headers van betaalpagina's in real time, in echte bezoekerssessies, en legt een bewijsspoor met tijdstempels vast dat QSA's voor dit requirement accepteren.
Voor WebSocket-aanvallen: omdat cside de JavaScript-runtime rechtstreeks instrumenteert, ziet het de WebSocket-verbindingen die scripts op de pagina opzetten, of die nu wel of niet zichtbaar zijn in HTTP-verkeerslogs en of ze nu wel of niet door CSP gedekt worden.
Lees hoe je voldoet aan PCI 6.4.3 en 11.6.1 voor de uitgewerkte implementatie.
