PCI DSS 4.0.1 requirements 6.4.3 en 11.6.1 besturen de scripts en HTTP-headers op je betaalpagina's. 6.4.3 laat je elk script inventariseren, autoriseren en op integriteit verzekeren. 11.6.1 laat je ongeautoriseerde wijzigingen aan de scripts en security-headers van die pagina detecteren en erop alerten. Beide zijn verplicht sinds 2025-03-31. Deze gids breekt elke clausule open, wat het betekent voor de pagina in productie, en het specifieke bewijs dat een QSA verwacht dat het produceert.
Deze twee requirements bestaan vanwege e-skimming. Magecart-stijl aanvallers breken je server niet. Ze wijzigen een script dat de browser laadt, en vangen kaarthouderdata rechtstreeks uit het formulier terwijl de gebruiker typt. Een processor-iframe dekt niet de pagina die het framed. cside leeft in precies die kloof: het registreert elk script dat echte browsers op de betaalpagina executyren, legt autorisatie vast, en flagt integriteits- en headerwijzigingen op het moment dat ze gebeuren.
Wat requirement 6.4.3 daadwerkelijk eist
6.4.3 stelt drie verplichtingen voor elk betaalpagina-script. Lees elk als een afzonderlijke clausule, want een QSA zal dat doen:
- Een methode bevestigt dat elk script geautoriseerd is voordat het laadt of executeert.
- Een methode verzekert de integriteit van elk script.
- Er wordt een inventaris van scripts bijgehouden met een schriftelijke justificatie waarom elk nodig is.
"Autorisatie" en "noodzakelijk" zijn de twee woorden waar teams over struikelen. Autorisatie is een vastgelegde beslissing: een genoemde goedkeurder tekende af dat dit script mag draaien op een pagina in kaarthouderdata-scope. Justificatie is de zakelijke reden dat het bestaat. Een tracking-pixel die marketing vorig kwartaal toevoegde heeft doorgaans geen van beide, precies het soort finding dat 6.4.3 aan de oppervlakte brengt.
De scope is breder dan first-party-code. De control dekt elk script dat de browser op de pagina executeert: je eigen bundles, third-party-SDK's, en de fourth-party-scripts die die vendors op runtime meedragen. Een tag-manager die na paginalaad nog drie extra scripts injecteert zijn drie extra entries in je inventaris, en die entries wijzigen zonder een deploy aan jouw kant.
Het PCI SSC noemt Subresource Integrity (SRI)-hashes en Content-Security-Policy als voorbeeld-integriteitsmechanismen. Ze gelden voor statische assets. Ze breken zodra een script dynamisch is. Een analytics-tag of A/B-tool die legitiem updatet invalideert de hash, dus een gepinde SRI blokkeert óf een goede update óf wordt verwijderd en beschermt niets meer. Content Security Policy kent dezelfde beperking: het kan niet instaan voor wat een toegestaan script op runtime doet. Daarom moet integriteit voor echte betaalpagina's beoordeeld worden op wat executeerde, niet op een hash die op build-tijd werd gezet.
Wat requirement 11.6.1 daadwerkelijk eist
11.6.1 is een detectie-control, geen management-control. Het vereist een change-and-tamper-detection-mechanisme dat twee dingen doet:
- Alerteert personeel op ongeautoriseerde wijziging (inclusief indicators of compromise, wijzigingen, toevoegingen en verwijderingen) van de HTTP-headers en de content van betaalpagina's zoals de consumentenbrowser ze ontvangt.
- Evalueert de ontvangen headers en pagina-content op een frequentie die door je targeted risk analysis onder requirement 12.3.1 is gezet, of minstens eens per zeven dagen.
De zin "zoals de consumentenbrowser ze ontvangt" draagt de requirement. 11.6.1 vraagt niet wat je CDN serveerde of wat je repo bevat. Het vraagt wat de browser rendeerde, na elke redirect, injectie en runtime-wijziging. Een skimmer leest navigator.webdriver, ontbrekende automatisering-properties, en de afwezigheid van echte interactie om een scanner te herkennen, en serveert dan schone code eraan en de payload aan een mens. Een control die alleen de gescande versie ziet vuurt nooit.
HTTP-headers vallen in scope omdat ze een aanvalsvlak zijn, geen config-detail. Een verzwakte of gestrippte Content-Security-Policy-header laat een kwaadaardig script laden dat het beleid juist moest blokkeren. 11.6.1 wil dat je opmerkt dat de header überhaupt wijzigde, en dat je het opmerkt op het geleverde antwoord, niet in je origin-config.
Hoe de twee requirements het werk verdelen
6.4.3 bestuurt wat je toestaat; 11.6.1 bestuurt wat er op de pagina gebeurde.
| Vraag | Requirement | Wat het bestuurt | Faalmodus die het vangt |
|---|---|---|---|
| Welke scripts zijn hier toegestaan, en waarom? | 6.4.3 | Autorisatie, justificatie, integriteit, inventaris | Een niet-goedgekeurd of ongedocumenteerd script in scope |
| Wijzigde de pagina of zijn headers zonder goedkeuring? | 11.6.1 | Detectie en alerting op script- en headerwijzigingen | Een live tamper die de inventaris nooit opmerkte |
| Hoe vaak checken we de geleverde pagina? | 11.6.1 + 12.3.1 | Frequentie, met een zeven-dagen-vloer | Verouderde checks die transiente wijzigingen missen |
Behandel ze als één loop, niet twee projecten. Een inventaris zonder live-detectie is een lijst die veroudert zodra een vendor een update pusht. Detectie zonder inventaris produceert alerts die niemand kan triage-ren, omdat er geen baseline is van hoe "geautoriseerd" eruitziet.
Het bewijs dat elke control moet produceren
Een QSA beoordeelt compliance op basis van artefacten. Map elke clausule naar het record dat het genereert zodat je precies kunt overhandigen wat hij vraagt.
| Clausule | Bewijsartefact | Wat het moet tonen |
|---|---|---|
| 6.4.3 inventaris | Scriptinventaris gekoppeld aan in-scope-pagina's | Elke script-URL, owner en laatst-geziene versie |
| 6.4.3 autorisatie | Goedkeuringsrecord per script | Wie het goedkeurde, wanneer, en welke data het aanraakt |
| 6.4.3 justificatie | Business-reason-notitie per script | Waarom het script nodig is op een betaalpagina |
| 6.4.3 integriteit | Integriteitsgeschiedenis | Hoe elk script in de loop der tijd ongewijzigd wordt bevestigd |
| 11.6.1 detectie | Change-log met alerts | Timestamp, diff, pagina en wie genotificeerd werd |
| 11.6.1 header-evaluatie | Header-geschiedenis per pagina | Security-header-waarden en wijzigingen tussen loads |
| 11.6.1 frequentie | Risicoanalyse + check-cadans | De 12.3.1-onderbouwing en bewijs dat checks draaiden |
Het artefact dat teams het vaakst missen is integriteits-geschiedenis en header-geschiedenis in de loop der tijd. Eén snapshot bewijst dat de pagina één keer schoon was. Een QSA die 11.6.1 beoordeelt wil bewijs dat je een wijziging zou hebben gevat: een timestamped record over veel echte paginaladen, niet één screenshot.
Waarom een processor dit niet voor jou sluit
Een veelvoorkomende aanname is dat het hosten van betaalvelden in een Stripe-, Adyen- of Braintree-iframe 6.4.3 en 11.6.1 naar de processor schuift. Dat doet het niet. Het iframe is gesandboxed, maar de merchant-pagina die het framed is dat niet. Je analytics, A/B-tooling, session-replay en chat-widgets draaien allemaal in dezelfde top-level-browser-context, en een script daar kan de DOM lezen, een nep-input-veld bovenop het iframe overlayen, of het formulier bij submit redirecten. De SAQ A-update van januari 2025 verfijnde eligibleheid omdat zo weinig echte betaalpagina's vrij zijn van third-party-scripts, en het voegde een criterium toe dat je bevestigt dat je site niet vatbaar is voor script-gebaseerde aanvallen, wat moeilijk te bewijzen is zonder monitoring. De requirements blijven bij de pagina die je serveert.
Waarom de dreiging steeds moeilijker te scannen wordt
De reden dat 11.6.1 aandringt op de geleverde pagina is dat aanvaller-tooling gebouwd is om alles te verslaan dat niet echt is. Headless- en geïnstrumenteerde browsers lekken: een navigator.webdriver-flag, ontbrekende chrome-runtime-objecten, Chrome DevTools Protocol Runtime-artefacten, en onmogelijke timing markeren een sessie allemaal als niet-menselijk. Skimmers fingerprinten die signalen en blijven slapend voor crawlers en synthetische checks.
Evasie-tooling is ook de andere kant op gegaan. cside's onderzoeksrapport over de toekomst van webbeveiliging vond dat playwright-stealth, automatisering afgesteld om die lekken te onderdrukken, ruwweg tienvoudig breder in gebruik was tegen het einde van 2025. De praktische takeaway voor 6.4.3 en 11.6.1: integriteits- en change-detectie moeten draaien waar de kaarthouderdata daadwerkelijk wordt ingevoerd, in de echte browsersessie, niet vanaf een extern standpunt dat een evasief script kan herkennen en zich voor verbergen.
Hoe cside dit bewijs op de browserlaag produceert
cside instrumenteert de betaalpagina in echte browsers, het oppervlak waar beide requirements op wijzen.
- Voor 6.4.3 legt het de volledige scriptinventaris vast, inclusief de fourth-party-scripts die vendors op runtime meebrengen, registreert autorisatie en justificatie naast elke entry, en bewaart een integriteitsgeschiedenis zodat je kunt bewijzen dat een script tussen versies intact bleef.
- Voor 11.6.1 monitort het script-content en HTTP-security-headers op de geleverde pagina, diff't ze over loads, en alerteert op ongeautoriseerde wijziging, met een timestamped record dat de 12.3.1-frequentievraag beantwoordt zonder een handmatige wekelijkse pull.
- Het brengt ook de runtime-payload van elk script aan de oppervlakte en koppelt script-gedrag aan apparaat-, echt-IP- en VPN/proxy-signalen, zodat een gemarkeerde wijziging met context komt in plaats van een kale hash-mismatch.
Omdat het kijkt naar wat executeerde in plaats van wat een scanner te zien kreeg, vangt cside hetzelfde browser-bewijs dat een e-skimming-aanvaller probeert te verbergen. Dat lijnt de compliance-workflow uit met de echte dreiging. Voor de operationele rollout en de QSA-reporting-weergave gaan de gidsen hieronder dieper.
Verder lezen op cside
- Hoe voldoe je aan PCI 6.4.3 en 11.6.1
- Waar QSAs op letten bij de beoordeling van 6.4.3 en 11.6.1
- Solution-comparison voor PCI DSS 6.4.3 en 11.6.1
- Wat is client-side security
- cside PCI Shield
- De snelste manier om aan PCI DSS 6.4.3 en 11.6.1 te voldoen
- PCI SSF of PCI DSS: welke standaard is van toepassing
Met ingang van 2026-06-18, behandel dit als operationele richtlijn, niet als juridisch advies. Bevestig de exacte control-tekst met je QSA, juridisch adviseur of risk-owner.
