PCI DSS 6.4.3 en 11.6.1 zijn client-side aangelegenheden, en de meeste organisaties hebben hier nooit eerder op dit niveau van nauwkeurigheid mee te maken gehad.
Kun je PCI-compliance voor beide vereisten bereiken zonder een betaalde oplossing? Het antwoord is: Nee, min of meer. Maar je verspilt veel meer geld aan loonkosten dan je aan een oplossing zou betalen.
Houd deze belangrijke zin in gedachten terwijl je dit artikel leest. Hij werd toegevoegd in de januariupdate met betrekking tot vereisten 6.4.3 en 11.6.1.
"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".
| Vereiste | Gratis uitvoerbaar? | Opmerkingen |
|---|---|---|
| 6.4.3 – Ongeautoriseerde scripts voorkomen | Ja, MAAR | CSP werkt formeel gezien, maar detecteert geen kwaadaardige inhoud van vertrouwde bronnen. Niet voldoende om te garanderen dat je "niet vatbaar bent voor aanvallen." |
| 6.4.3 – Scriptintegriteit verifiëren | Nee | SRI werkt alleen voor statische scripts. Het monitoren van dynamische scripts vereist eigen tooling. Je mist inzicht in actieve dreigingen. Je bouwt in feite een eigen antivirusprogramma. |
| 6.4.3 – Scriptinventaris bijhouden | Ja | Een handmatige lijst (spreadsheet of versioned config) is volledig compliant, mits nauwkeurig bijgehouden en up-to-date. |
| 11.6.1 – Detectie van manipulatie en wijzigingen | Nee | Je kunt scriptwijzigingen detecteren, maar beoordelen of er sprake is van manipulatie of een legitieme wijziging is erg lastig. |
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 belangrijkste 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-srcom 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- encrossorigin-attributen toe aan elke<script>-tag van derden. - 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:
- Maak een lijst van dynamische script-URL's
- Haal de scriptinhoud op
- Normaliseer de payload — verwijder tijdstempels, cache-busters of CDN-trackingheaders (indien nodig).
- Sla een opgeschoonde versie van de inhoud op ter vergelijking.
- Bij wijziging: log en geef een melding.
- Stuur bijvoorbeeld een e-mail.
- PCI wil bewijs dat je actief de scriptintegriteit monitort.
- Bewaar logs van deze controles en eventuele vervolgacties.
Maar is dit in de praktijk haalbaar?
Zou je bijvoorbeeld je eigen antivirussoftware bouwen? Voor de meesten van ons is het antwoord een duidelijk "nee". Een engine bouwen die kwaadaardig gedrag in JS signaleert is een complexe 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 versioned 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)
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. Hier zijn wel kosten aan verbonden...
- 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, MITS 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 verdedigbaar, 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, houd dan de belangrijke zin in gedachten: "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.
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. 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. 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.
