Gratis vs betaalde PCI DSS-naleving: wat werkt echt

Kort samengevat: gratis PCI DSS 6.4.3- en 11.6.1-compliance

• Gratis basis: Je kunt basis 6.4.3 en 11.6.1 halen zonder kosten op een gratis scriptmonitoring-platform. Inventaris, autorisatie-workflow, tamperdetectie, QSA-bewijs.
• Wanneer betaald loont: Betaalde niveaus voegen geautomatiseerd blokkeren, langere retentie, rijkere alerting, RBAC toe. Boven Level 3 verdient dat zich meestal terug.
• Deadline: Beide verplicht sinds 31 maart 2025. Uitstellen is een QSA-faalrisico bij je volgende assessment.

Weinig tijd? Bekijk cside PCI Shield. Dit dekt alles hieronder in één deployment.

Waarom deze vereisten zijn ingevoerd

Sinds JavaScript in 2011 aan browsers werd toegevoegd, heeft client-side uitvoering de deur geopend voor grootschalige card skimming-aanvallen. Geavanceerde aanvallers injecteren tegenwoordig kwaadaardige scripts via dependencies, plugins of supply chain-compromissen, waardoor de beveiliging van betaalkaartgegevens in gevaar komt. Meestal worden betalingsgegevens dynamisch geëxfiltreerd, vaak gericht op slechts een klein percentage van de gebruikers om onder de radar te blijven.

Visa, Mastercard en Amex hebben allemaal gewezen op client-side scriptgebaseerde aanvallen als de leidende bron van creditcarddiefstal. Tokenisatie helpt, maar slechts tot op zekere hoogte. Als de client wordt gekaapt, slaagt de aanval alsnog.

PCI DSS v4.0 verplicht bedrijven dan ook terecht om maatregelen te implementeren voor:

• Het voorkomen dat ongeautoriseerde scripts worden uitgevoerd (6.4.3)
• Het waarborgen van de integriteit van scripts (6.4.3)
• Het bijhouden van een actuele inventaris van scripts met zakelijke onderbouwing (6.4.3)
• Het detecteren van manipulatie of ongeautoriseerde wijzigingen op betaalpagina's (11.6.1)

Hoe je PCI DSS-compliance bereikt zonder een oplossing aan te schaffen

Als je vindingrijk bent, technisch vaardig, en bereid bent de tooling zelf te onderhouden, kun je het als volgt aanpakken.

1. Ongeautoriseerde scripts voorkomen (6.4.3)

Om te voldoen aan de vereiste dat alleen geautoriseerde scripts mogen laden en uitvoeren, heb je een sterke handhavingslaag nodig. Een Content Security Policy (CSP) kan hiervoor dienen, maar moet strak geconfigureerd en actief onderhouden worden.

Wat je kunt doen:

• Implementeer een strikte CSP-header met script-src om toegestane domeinen op een whitelist te zetten.
• Gebruik nonces of hashes om inline of dynamische scripts expliciet toe te staan.
• Controleer je policy regelmatig en werk deze bij bij elke scriptwijziging.

Is dit voldoende voor PCI? Ja, MAAR alleen in formele zin. Dynamische scripts kunnen NIET volledig worden beschermd met CSP.

CSP wordt erkend als een geldig controlemechanisme voor het autoriseren van scripts. CSP alleen houdt echter geen intentie bij. Je hebt ondersteunende documentatie nodig die aantoont waarom elke toegestane bron is geautoriseerd.

MAAR, onthoud de zin van hierboven:

"Om in aanmerking te komen voor SAQ A moeten merchants bevestigen dat hun site niet vatbaar is voor aanvallen via scripts die de e-commercesystemen van de merchant kunnen beïnvloeden".

Lost CSP dit op in deze context? NEE. Als een bron hetzelfde blijft, maar de inhoud van het geleverde script verandert, zou een CSP dit NIET opvangen.

De Polyfill-aanval van 2024 zou NIET worden tegengehouden door een CSP. Dit betekent technisch gezien dat je site WEL vatbaar is voor aanvallen, en je dus een beveiligingstool nodig hebt om volledig compliant te zijn. Je kunt je aanmelden of een demo boeken om met ons te praten.

Houd het volgende in gedachten als onderdeel van je PCI-compliancechecklist:

• Gebruik CSP met script-src-beperkingen en nonces/hashes.
• CSP moet regelmatig worden bijgewerkt en gecontroleerd.
• Beheer CSP zorgvuldig; het is kwetsbaar en kan applicaties breken.

2. Scriptintegriteit verifiëren (6.4.3)

Je wordt geacht te detecteren wanneer een script is gemanipuleerd. Voor statische scripts is Subresource Integrity (SRI) een standaardoplossing. Het controleert of alleen scripts met de verwachte hash succesvol laden.

Wat je kunt doen:

• Voeg integrity- en crossorigin-attributen toe aan elke third-party `` tag.
• Haal scripts periodiek op, hash ze en vergelijk ze met bekende goede hashes.

Is dit voldoende voor PCI? Ja, MAAR alleen voor statische scripts. Dynamische scripts kunnen NIET worden gedekt met SRI alleen.

Dynamische scripts (bijv. analysetools, A/B-testrunners) veranderen vaak bij elk verzoek en zullen SRI breken. PCI verwacht dat je deze beperking erkent en mitigeert, door dynamische scripts te vermijden of een monitoringmethode te implementeren.

Hoe monitor je die? Dat is niet mogelijk zonder tooling. Ofwel een betaalde oplossing (zoals wij hier bij cside 👋) — of een zelfgebouwde oplossing.

Zonder al te diep in te gaan, zo zou je je eigen monitoringtool kunnen bouwen:

1. Maak een lijst van dynamische script-URL's
2. Haal de scriptinhoud op
3. Normaliseer de payload Verwijder tijdstempels, cache-busters of CDN-trackingheaders (indien nodig).
4. Sla een opgeschoonde versie van de inhoud op ter vergelijking.

Hash of diff het resultaat

1. Bij wijziging: log en geef een melding.

Waarschuw bij onverwachte wijzigingen

1. Stuur bijvoorbeeld een e-mail

Documenteer je proces

1. PCI wil bewijs dat je actief de scriptintegriteit monitort.
2. Bewaar logs van deze controles en eventuele vervolgacties.

Maar is dit in de praktijk haalbaar?

Zou je bijvoorbeeld je eigen antivirussoftware bouwen? We durven te stellen dat het antwoord voor de meesten van ons een duidelijk "nee" is. Een engine bouwen die kwaadaardig gedrag in JS signaleert is een lastige opgave en vereist een omvangrijke dataset om succesvol te zijn. Dit is meer dan alleen een kwestie van tijdsinvestering. Het is ook een kwestie van middelen.

Samenvatting:

• SRI werkt alleen voor statische scripts. Gebruik het waar mogelijk.
• SRI werkt NIET met scripts die variabele payloads hebben.
• Het monitoren van daadwerkelijke scriptinhoud is noodzakelijk via tooling.

3. Een scriptinventaris bijhouden (6.4.3)

Je wordt geacht een inventaris bij te houden van alle scripts die op de betaalpagina worden uitgevoerd. Dit omvat zowel statische als dynamische scripts, inline scripts, bronnen van derden (zoals tagmanagers of analysetools) en alles wat via frameworks wordt geladen (zoals React of Vue). PCI wil zien dat elk script is beoordeeld, goedgekeurd en een zakelijke of technische onderbouwing heeft. Dit elke 7 dagen (wekelijks).

Wat je kunt doen:

• Maak een versiebeheerde lijst (spreadsheet of YAML/JSON-bestand).
• Vermeld: scriptbron, verwachte hash (indien statisch), zakelijke/technische onderbouwing, eigenaar/team.
• Werk deze bij bij elke deployment of codewijziging (niet scriptcodewijzigingen) die de betaalpagina beïnvloedt.

Dit moet je opnemen:

• De bron of URL
• Of het statisch of dynamisch is
• Een hash (indien statisch en SRI wordt gebruikt)
• Zakelijke/technische onderbouwing
• Eigenaar of verantwoordelijk team
• Opmerkingen over monitoring (met name voor dynamische scripts)

Verwante gidsen

Verdiep je in het cluster:

• de gedeelde PCI DSS-verantwoordelijkheden van Stripe
• de gedeelde PCI DSS-verantwoordelijkheden van Adyen
• de gedeelde PCI DSS-verantwoordelijkheden van PayPal Braintree
• vergelijking van oplossingen voor PCI DSS 6.4.3 en 11.6.1
• vikingcloud-approves-c-sides-security-platform-for-pci-dss-v4-0-1-requirement-6-4-3-and-11-6-1
• hoe je voldoet aan PCI DSS 6.4.3
• de PCI DSS SAQ A-updates van januari 2025, uitgelegd

Is dit voldoende voor PCI? Ja, PCI vereist hier niets anders. Een handmatige lijst is acceptabel zolang deze nauwkeurig en bijgehouden is. Dynamische scripts moeten nog steeds worden vermeld, ook al kun je ze niet hashen. In die gevallen verwacht PCI dat je uitlegt waarom SRI niet kan worden gebruikt en hoe het script in plaats daarvan wordt gemonitord. LET OP: Dit betekent NIET dat je alleen een inventaris kunt maken en geen actie hoeft te ondernemen op de bovenstaande punten. Het is een iets losser omschreven vereiste die sommigen zien als de ultieme oplossing. Dat is het niet.

4. Detectie van manipulatie en wijzigingen (11.6.1)

PCI wil dat je ongeautoriseerde wijzigingen op de betaalpagina detecteert zoals die in de browser van de gebruiker worden ontvangen. Dit omvat wijzigingen in inhoud en HTTP-headers (zoals CSP, CORS, enz.).

Wat je kunt doen:

• Gebruik een headless browser (bijv. Puppeteer) of curl om de live betaalpagina op te halen. Daar zul je geld aan moeten uitgeven...
• Leg headers en HTML-inhoud vast.
• Vergelijk met een bekende goede baseline en geef een melding bij wijzigingen.
• Normaliseer de uitvoer indien nodig om fout-positieven te vermijden (met name belangrijk voor dynamische inhoud).
• Documenteer welke wijzigingen meldingen activeren, wie reageert en hoe.

Is dit voldoende voor PCI? Ja, ERVAN UITGAANDE dat je het regelmatig uitvoert en hebt gedocumenteerd welke wijzigingen meldingen activeren, wie wordt geïnformeerd en wat je responsplan is. De vereiste frequentie is wekelijks, TENZIJ anders gerechtvaardigd door een risicoanalyse.

Opmerking over dynamische pagina's: Client-rendered frameworks (React, Vue, enz.) laden of muteren de DOM vaak na het laden van de pagina. Als je hier geen rekening mee houdt, zal je monitoring fout-positieven genereren. Voor PCI is dit vermoedelijk prima. ZOLANG je duidelijk definieert wat je wel controleert (bijv. CSP-header, externe scriptdomeinen, belangrijke DOM-selectors) en waarom. Mocht je toch slachtoffer worden van een aanval, dan blijft de vereiste staan: "Om in aanmerking te komen voor SAQ A moeten merchants bevestigen dat hun site niet vatbaar is voor aanvallen via scripts die de e-commercesystemen van de merchant kunnen beïnvloeden".

Samenvatting:

• Gebruik curl of een headless browser om headers en HTML vast te leggen en te vergelijken.
• Normaliseer dynamische inhoud om fout-positieven te verminderen.
• Voer controles wekelijks uit (of vaker op basis van risico).
• Stel meldingen in en documenteer een responsproces.

Wat een PCI DSS 4.0.1 compliance-audit voor 6.4.3 en 11.6.1 controleert

Een PCI DSS 4.0.1 compliance-audit voor e-commerce merchants onderzoekt of het script-inventaris van de betaalpagina compleet is, of elk script een geautoriseerde zakelijke of technische rechtvaardiging heeft, en of de merchant kan aantonen dat er tegen de HTTP-headers van de betaalpagina minstens elke zeven dagen een change-detectiemechanisme draait. Requirements 6.4.3 en 11.6.1 zijn de twee clauses waar een QSA de meeste tijd aan besteedt voor card-not-present flows.

De audit-zichtbare artefacten zijn specifiek: een script-inventarislijst met eigenaar, doel en verwachte hash per entry; gedocumenteerde goedkeuringen; en logbewijs dat het change-detectiemechanisme met de vereiste cadans is uitgevoerd met alerts die naar een gemonitord kanaal stromen. Als één van die artefacten ontbreekt of niet on-demand te reproduceren is, markeert de audit 6.4.3 of 11.6.1 als non-compliant ongeacht de kwaliteit van andere controls.

cside produceert het script-inventaris automatisch uit live betaalpaginadata, onderhoudt hashes en goedkeuringsstatus en draait de 6.4.3 change-detectieloop continu met een bewijsspoor dat een QSA rechtstreeks kan exporteren.

De zakelijke voordelen van PCI DSS-compliance voorbij het vermijden van boetes

De voordelen van PCI DSS-compliance voorbij boete-vermijding zijn concreet: stabiliteit van de acquirer-relatie, vertrouwen van de paymentmerken en materieel lagere incident-response-kosten als er wél een breach plaatsvindt. Continu-compliant merchants houden hun acquirer-relatie buiten de escalatiewachtrij, behouden toegang tot de laagste interchange-bands die hun processor biedt en verminderen het volume forensisch werk dat een incident triggert.

Er is ook een downstream-voordeel voor grote e-commerce-inkopers. Enterprise-inkoopteams eisen steeds vaker PCI DSS-attestation als leveranciersprerequisite. Continue compliance betekent dat de AoC altijd actueel is wanneer een inkoopverzoek binnenkomt, in plaats van een sprint bij elke jaarcyclus.

cside's continue monitoring houdt de 6.4.3- en 11.6.1-bewijsketen realtime actueel, wat betekent dat het venster voor auditvoorbereiding krimpt van weken inhaalslag naar een same-day export.

PCI DSS non-compliance en de boetes die merchants daadwerkelijk krijgen

PCI DSS non-compliance kent drie boeteniveaus die merchants direct raken. Cardnetwerken leggen via de acquirer boetes op, doorgaans beginnend bij een paar duizend dollar per maand voor een eerste overtreding en oplopend tot maandbedragen in vijf of zes cijfers als de merchant meerdere auditcycli non-compliant blijft. De acquirer geeft deze boetes vaak volledig door en voegt een eigen service-toeslag toe.

Het tweede niveau is de transactiekost. Een merchant die op het moment van een breach non-compliant wordt bevonden krijgt hogere interchange-tarieven op volgende transacties en meer chargeback-aansprakelijkheid. PCI DSS non-compliance-boetes stapelen bovenop breach-gerelateerde aansprakelijkheid onder staats- en federale wetgeving.

Het derde niveau is de strategische boete. Aanhoudende non-compliance kan leiden tot verlies van kaartverwerkingsrechten of MATCH-listing, wat het vermogen van de merchant beperkt om betaalverwerking bij andere acquirers te krijgen.

cside verlaagt zowel het non-compliance-risico als de audit-voorbereidingskosten door de 6.4.3- en 11.6.1-controls continu verifieerbaar te houden.

Een beknopte PCI DSS 4.0.1 compliance checklist voor 6.4.3 en 11.6.1

Een PCI DSS 4.0.1 compliance checklist voor betaalpagina-requirements 6.4.3 en 11.6.1 is kort maar streng. Loop hem in volgorde door vóór een audit:

1. Volledig script-inventaris. Elk script dat op de betaalpagina laadt is opgesomd met bron, doel, business owner en verwachte hash wanneer het script statisch is.
2. Gedocumenteerde goedkeuring per script. Elke entry heeft een vastgelegde goedkeuringsbeslissing door een verantwoordelijke persoon en een review-tijdstempel binnen de laatste reviewcyclus.
3. Change-detectiemechanisme geïnstalleerd. Een tool of proces detecteert ongeautoriseerde wijzigingen aan HTTP-headers en scriptinhoud op de betaalpagina en kan bewijs van uitvoeringen produceren.
4. Wekelijkse cadans bewezen. Logbewijs laat zien dat het change-detectiemechanisme minstens elke zeven dagen heeft gedraaid gedurende de volledige auditperiode.
5. Alert-routing geverifieerd. Alerts routeren naar een gemonitord kanaal met een escalatiepad naar security of engineering.
6. Test-fire-bewijs. Een testwijziging op een non-productie-betaalpagina werd binnen het vereiste venster gedetecteerd en gealarmeerd.
7. Compenserende controls gedocumenteerd, indien gebruikt. Elke afwijking van de standaardaanpak is gedocumenteerd met de rationale voor de compenserende control.

cside produceert items 1 tot en met 6 als continu bewijs, zodat de audit een review van het draaiende systeem wordt in plaats van een reconstructie achteraf.

Dus, kun je het "gratis" doen?

Ja, min of meer. Maar het is in de praktijk vrijwel onmogelijk.

Het is technisch mogelijk, maar in de praktijk én qua compatibiliteit kwetsbaar. Het belangrijkste is dat je hoogstwaarschijnlijk meer geld, tijd en middelen kwijt bent dan wanneer je kiest voor een betaalde oplossing.

Je zou het volgende nodig hebben:

• Je eigen tools of scripts schrijven
• Je eigen methode bouwen om scripts te analyseren — dit is kostbaar en als niet-beveiligingsbedrijf heb je waarschijnlijk geen toegang tot de benodigde data of competenties om dit te doen. Zou je je eigen antivirusprogramma bouwen?
• Scriptintegriteit handmatig monitoren
• Een scriptinventaris met discipline bijhouden
• Dynamische pagina's normaliseren en vergelijken zonder te verdrinken in fout-positieven

En het allerbelangrijkste: Je moet aantonen dat je site niet vatbaar is voor client-side aanvallen, zoals expliciet vereist in de PCI DSS-update van januari.

Een CSP stopt geen supply chain-aanvallen. Een SRI is niet compatibel met dynamische scripts. En een eenvoudige curl-controle biedt geen bescherming tegen contextbewuste, selectieve exfiltratie.

Als je de DIY-route kiest: Documenteer alles, automatiseer waar mogelijk en bereid je voor op overhead. En bouw je eigen tooling, indien mogelijk. Maar bereken vooral je tijd en middelen (menselijk of anderszins) en maak de rekensom. De kans is groot dat je beter af bent met een betaalde oplossing.

Als je volledig compliant wilt zijn én veilig wilt blijven, hebben we cside precies daarvoor gebouwd. Je kunt hier een demo boeken of je aanmelden om vandaag nog compliant te zijn.

PCI 11.6.1 specifiek begrijpen

Terwijl 6.4.3 zich richt op scriptinventaris en rechtvaardiging, richt PCI DSS 11.6.1 zich op het detecteren van ongeautoriseerde wijzigingen aan scripts en HTTP-beveiligingsheaders op betaalpagina's.

PCI 11.6.1 vereist dat je:

• De inhoud en configuratie van elk script dat op betaalpagina's draait, monitort
• Manipulatie, injectie of ongeautoriseerde wijziging tijdig detecteert
• Het juiste personeel waarschuwt wanneer ongeautoriseerde wijzigingen worden gedetecteerd

Het woord "tijdig" is bewust overgelaten aan QSA-interpretatie, maar wordt over het algemeen gelezen als detectie binnen minuten tot uren na de wijziging. Wekelijkse of maandelijkse scans voldoen niet aan 11.6.1. cside's continue monitoring triggert waarschuwingen in realtime naarmate wijzigingen optreden, en geeft je beveiligingsteam het responsvenster dat compliance vereist.