Kort samengevat: praktische PCI DSS 6.4.3 compliance-checklist voor betaalscripts
- De meeste teams nemen Subresource Integrity als het antwoord op 6.4.3. Op zichzelf is het niet genoeg: SRI inventariseert niet automatisch alle scripts, geldt niet voor dynamisch geladen scripts en detecteert geen gedragsverandering in een geautoriseerd script, wat de primaire Magecart-aanvalsvector is.
- 6.4.3 is verplicht sinds 31 maart 2025 en dekt eigen bundles, third-party tags, analytics-pixels, chat-widgets en CDN-bibliotheken. cside PCI Shield rolt uit als een enkele script-tag op de betaalpagina, en de meeste teams ronden de technische integratie af in minder dan 30 minuten.
- Draait je checkout op een handvol statische scripts, dan kan SRI plus CSP standhouden als basisscontroles. Injecteert een tagmanager dynamisch scripts, voeg dan runtime-integriteitsmonitoring toe, cside is door VikingCloud gevalideerd voor zowel 6.4.3 als 11.6.1.
PCI DSS 4.0.1 Vereiste 6.4.3 vraagt je om drie dingen te doen voor elk script dat op een betaalpagina draait: bevestigen dat het geautoriseerd is, een schriftelijke rechtvaardiging bijhouden waarom het daar thuishoort, en het beschermen met een integriteitscontrole die ongeautoriseerde wijzigingen opvangt. De vereiste is verplicht sinds 31 maart 2025 en geldt voor first-party code, third-party tags, analytics-pixels, chatwidgets en al het andere dat in de context van een betaalpagina wordt uitgevoerd.
De vereiste bestaat om betaalpaginaskimming aan te pakken, de Magecart-achtige aanvallen waarbij kwaadaardige JavaScript in een checkoutpagina wordt geschoven om kaartgegevens te oogsten terwijl klanten die intypen. Vereiste 6.4.3 is een van de twee nieuwe client-side maatregelen in PCI DSS 4.0.1, en de bijbehorende vereiste, 11.6.1, verzorgt de monitoringkant. Deze checklist behandelt wat 6.4.3 vereist en hoe je daar komt.
Wat Vereiste 6.4.3 echt vereist
De PCI Security Standards Council definieert drie specifieke maatregelen onder Vereiste 6.4.3:
1. Een methode om te bevestigen dat elk script geautoriseerd is. Je hebt gedocumenteerde autorisatie nodig voor elk script dat op betaalpagina's aanwezig is. Dat betekent niet alleen de scripts die je team heeft geschreven, maar elke third-party tag, analytics-pixel, chatwidget, A/B-testtool en via een CDN geladen bibliotheek die in de context van een betaalpagina draait. Autorisatie betekent dat je weet dat het script er is en dat je er een zakelijke reden voor hebt.
2. Een methode om de integriteit van elk script te waarborgen. Elk script moet worden beschermd tegen ongeautoriseerde wijziging. Dat kan met Subresource Integrity (SRI)-hashes voor extern geladen scripts, Content Security Policy-maatregelen, of een runtime-monitoringtool die waarschuwt wanneer de inhoud of het gedrag van een script verandert. SRI op zichzelf dekt geen scripts die dynamisch worden geladen of worden geserveerd vanaf CDN's waarvan de inhoud roteert zonder dat de URL verandert.
3. Een schriftelijke rechtvaardiging voor elk script. Elk geautoriseerd script heeft een gedocumenteerde zakelijke reden nodig om op de betaalpagina te staan. Een tag die er alleen staat omdat marketing die drie jaar geleden heeft toegevoegd en niemand die heeft verwijderd, heeft geen rechtvaardiging. Je assessor zal om deze documentatie vragen.
De bijbehorende vereiste, 11.6.1, voegt wijzigings- en manipulatiedetectie toe: een geautomatiseerd mechanisme dat waarschuwt wanneer scripts op betaalpagina's of HTTP-headers worden gewijzigd. Samen vereisen 6.4.3 en 11.6.1 zowel een statische inventaris met integriteitscontroles als een live monitoringcapaciteit.
Stap 1: Inventariseer elk script op je betaalpagina's
Begin met een volledige audit van elk script dat op de betaalpagina wordt geladen. Die lijst omvat:
- First-party scripts die je team beheert
- Third-party tags die via tagmanagers worden geladen (Google Tag Manager, Tealium, Segment)
- Analytics-pixels (Google Analytics, Meta Pixel, alle marketingattributietags)
- Chat- en supportwidgets (Intercom, Drift, Zendesk)
- A/B-test- en personalisatiescripts
- Fraudedetectietools
- Alle via een CDN geladen bibliotheken
De meeste teams zijn verrast door hoeveel scripts er daadwerkelijk op betaalpagina's draaien. Tagmanagers zijn meestal de boosdoener: ze laden extra scripts die nooit door een security-review zijn gegaan. Een monitoringtool die elk aanwezig script ontdekt en oplijst, is de snelste manier om een nauwkeurige inventaris op te bouwen.
Stap 2: Autoriseer en rechtvaardig elk script
Leg voor elk script in de inventaris het volgende vast:
- Wie het script op deze pagina heeft geautoriseerd
- Welk zakelijk doel het dient
- Of de betaalpagina de juiste scope ervoor is (veel analytics-scripts hoeven niet op betaalpagina's te draaien en zouden moeten worden uitgesloten)
Elk script dat geen duidelijke zakelijke rechtvaardiging kan opleveren, hoort van de betaalpagina te worden gehaald. Minder scripts betekent een kleinere compliancelast en een kleiner aanvalsoppervlak.
Stap 3: Implementeer integriteitscontroles
Zorg voor elk geautoriseerd script voor een integriteitsmechanisme. Je opties:
Subresource Integrity (SRI). Voor scripts die vanaf externe URL's worden geladen, vertelt een SRI-hash in de scripttag de browser om het script te weigeren als de inhoud is veranderd. SRI werkt goed voor scripts die vanaf stabiele, geversioneerde CDN-URL's worden geserveerd. Het helpt niet bij scripts die dynamisch worden geladen, scripts waarvan de inhoud verandert zonder dat de URL verandert, of inline scripts.
Content Security Policy. Een CSP-allowlist voorkomt dat ongeautoriseerde scripts worden geladen. Het vangt geen gedragsveranderingen op in een script dat al op de allowlist staat.
Runtime-integriteitsmonitoring. Een tool die scriptgedrag in real time bewaakt, vangt het geval op waarin een geautoriseerd script iets nieuws begint te doen, zoals het uitlezen van een formulierveld dat het nooit eerder heeft aangeraakt of het aanroepen van een endpoint dat het nooit heeft aangeroepen. Die gedragsverandering is de Magecart-vector, en het is degene die SRI en CSP missen.
Voor volledige dekking van 6.4.3 en 11.6.1 is runtime-monitoring de laag die het werk doet. SRI en CSP zijn fundamentele maatregelen die eronder liggen.
Hoe cside aan zowel 6.4.3 als 11.6.1 voldoet
cside PCI Shield gebruikt één scripttag op de betaalpagina en vervolgens:
- Ontdekt en inventariseert elk aanwezig script, continu bijgewerkt
- Bewaakt het gedrag van elk script in real time en waarschuwt wanneer dat gedrag verandert
- Levert het bewijs dat een PCI-assessment nodig heeft: een scriptinventaris met autorisatiestatus, plus manipulatiedetectie-events met tijdstempels
cside is gevalideerd door VikingCloud voor PCI DSS 4.0.1 Vereisten 6.4.3 en 11.6.1. Die validatie betekent dat een gekwalificeerde security assessor de tool heeft beoordeeld en heeft bevestigd dat deze voldoet aan de specifieke bewijsvereisten van beide maatregelen, en niet alleen aan hun algemene bedoeling.
Verder lezen
- cside PCI Shield: continue scriptinventaris en runtime-monitoring voor betaalpagina's
- Waarom crawlers niet kunnen helpen bij PCI-compliance (op zichzelf)
- Waarom CSP niet werkt
- Overzicht PCI DSS-compliance
