In deze blog:
- Wat auditors verwachten bij PCI 6.4.3 & 11.6.1
- Voorbeelden van aanvallen en boetes
- Vergelijking van leveranciersoplossingen
- Bronnen voor je team (checklists, beoordelingen)
PCI 6.4.3 & 11.6.1 draait om één ding: controle en zichtbaarheid over wat er in de browser van je gebruiker wordt uitgevoerd. Specifiek op betaalpagina's. Deze vereisten dwingen bedrijven eindelijk te begrijpen wat er aan de client-side gebeurt: welke scripts worden geladen? Zijn ze goedgekeurd? Gedragen ze zich verdacht? Verrassend genoeg hebben de meeste teams geen antwoord op die vragen. Ze hoefden dat ook nooit echt te hebben. En nu haasten diezelfde teams zich om te voldoen aan de PCI DSS 4.0.1-audits. Volgens het Verizon 2024 Payment Security Report is het percentage organisaties dat volledige compliance handhaaft gestaag gedaald, tot 33% in 2023.
We hebben samengewerkt met diverse securityleiders in eCommerce, Retail en FinTech om PCI-conforme oplossingen te implementeren voor pagina's die gevoelige gebruikersgegevens verwerken (zoals betaalkaarten). Op basis van de veelgemaakte fouten en best practices die we hebben gezien, hebben we een gids samengesteld om jouw complianceproces te vereenvoudigen.
"De technische stappen om PCI 6.4.3 & 11.6.1 te bereiken is iets wat ik regelmatig wordt gevraagd uit te leggen aan complianceteams. De documenten zijn duidelijk over wat er vereist is, maar hoe je de mechanismen implementeert blijft een grijs gebied dat securityteams zelf moeten uitzoeken."
— Simon Wijckmans, Oprichter, cside
Wat zijn de PCI DSS 6.4.3-vereisten?
Als onderdeel van de PCI DSS 4.0.1-toevoegingen die op 31 maart 2025 verplicht werden, vereist eis 6.4.3 dat bedrijven:
- Een overzicht bijhouden van elk script dat op betaalpagina's wordt uitgevoerd.
- Documenteren waarom elk script nodig is (zakelijke rechtvaardiging).
- De integriteit van elk script verifiëren (om te garanderen dat het niet is gewijzigd).
- Ongeautoriseerde scriptwijzigingen detecteren en melden.
Wat dit in gewone taal betekent: Op pagina's die gevoelige gebruikersinformatie verwerken (betaalkaarten, gezondheidsinformatie, PII) moet je een mechanisme hebben om third-party scripts te monitoren, te zien wat ze doen in de browsers van je gebruikers, en securityteams te waarschuwen wanneer scripts zich verdacht gedragen.
*Definities gebaseerd op PCI DSS v4.0.1 - jun. 2024. Dit is de meest actuele versie per september 2025. Bezoek de PCI SSC-bibliotheek voor officiële documenten.
Wat zijn de PCI DSS 11.6.1-vereisten?
Als onderdeel van de PCI DSS 4.0.1-toevoegingen die op 31 maart 2025 verplicht werden, vereist eis 11.6.1 dat bedrijven:
- Personeel waarschuwen bij ongeautoriseerde wijzigingen in HTTP-headers en scripts op betaalpagina's.
- Ontvangen HTTP-headers en betaalpagina's evalueren.
- Dit minimaal wekelijks uitvoeren of conform de risicoanalyse van de entiteit (Eis 12.3.1).
Wat dit in gewone taal betekent: HTTP-headers zijn regels die de browser van een gebruiker vertellen hoe content op een pagina moet worden verwerkt. Het aanpassen van die headers (bijvoorbeeld door een kwaadaardig script) kan beveiligingsmaatregelen verzwakken. PCI DSS 11.6.1 vereist dat bedrijven een mechanisme hebben dat regelmatig (minimaal eens per zeven dagen) controleert op ongeautoriseerde headerwijzigingen en het securityteam waarschuwt wanneer die optreden.
Methoden om te voldoen aan 6.4.3 & 11.6.1 (kopen of zelf bouwen):
- Een interne oplossing bouwen: Ontwikkel eigen tooling om betaalpagina's te scrapen, scripts te loggen, scriptpayloads te analyseren en bij wijzigingen te waarschuwen. Deze aanpak vereist doorlopende engineeringtijd van gespecialiseerd personeel.
- Een kant-en-klare tool gebruiken: Een client-side intelligence platform houdt automatisch een live scriptoverzicht bij, biedt rechtvaardigingen en stuurt meldingen bij ongeautoriseerde wijzigingen. Rapportagefuncties zijn vaak specifiek gebouwd voor PCI DSS-audits.
"Wat betreft de vraag of je het intern moet bouwen of een tool moet kopen: dat is een individuele beslissing voor elk bedrijf. Maar ik heb nog geen enkele klant gehad die dit goed intern heeft gedaan. In ons hele bedrijf heb ik slechts één klant gezien die dit succesvol intern heeft gerealiseerd. En dat na het werken met honderden klanten. Een leverancierstool neemt het giswerk echt weg."
- Marc Jackson, QSA & Compliance Advisor, MegaplanIT
PCI DSS 6.4.3 uitgelegd en compliancestappen
Wie verantwoordelijk is voor 6.4.3 & 11.6.1-compliance:
- Ontwikkelaars beheren welke scripts worden ingezet en houden het overzicht actueel.
- Securityteams monitoren op verdachte wijzigingen en onderzoeken meldingen.
- Complianceteams zorgen dat documentatie, goedkeuringen en audittrails voldoen aan de PCI-normen.
Hoe QSA-goedgekeurde rapportage voor 6.4.3 & 11.6.1 eruitziet:
Sommige goedkope of gratis tools exporteren rommelige dashboards of CSV-bestanden. Die zijn moeilijk te interpreteren voor auditors en nog moeilijker te operationaliseren voor interne teams. In de praktijk zoeken QSA's naar gestructureerde, overzichtelijke rapporten die het scriptoverzicht, de autorisatiestatus en wijzigingsdetectie in de loop van de tijd tonen. Heldere rapportage maakt het ook eenvoudiger voor je team om snel te handelen bij verdacht gedrag.
Deze video laat de rapporten zien die we gebruiken, zowel als onafhankelijk geauditeerd SAQ-D-bedrijf als als leverancier met door VikingCloud gevalideerde maatregelen.
<a
class="pci-video-card__cta"
href="https://cside.com/landing/pci-demo-video"
target="_blank"
rel="noopener noreferrer"
>
<span class="pci-video-card__icon" aria-hidden="true">
<svg viewBox="0 0 48 48" fill="none" xmlns="http://www.w3.org/2000/svg">
<circle cx="24" cy="24" r="20.5" stroke="currentColor" stroke-width="2"/>
<path d="M20 16.5L31 24L20 31.5V16.5Z" stroke="currentColor" stroke-width="2" stroke-linejoin="round"/>
</svg>
</span>
<span>Video bekijken</span>
</a>
Wat auditors verwachten bij PCI 6.4.3-compliance
1. Een overzicht bijhouden van elk script dat op betaalpagina's wordt uitgevoerd
"Ik gebruik zoveel third-party scripts: analysetools, supportwidgets, polyfills, animatiebibliotheken, CDN's. Elk van deze kan malafide worden en de legitieme content vervangen door een keylogger of erger." - Edgardo C., Ontwikkelaar (Citaat afkomstig uit een cside-review)
De meeste websites hebben tussen de 5 en 100+ scripts op hun site. Een client-side intelligence platform houdt een overzicht bij van alle pagina's (inclusief betaalpagina's op je domein) en toont de payload van het script bij elk verzoek. Zo kun je codewijzigingen, updates en mogelijk kwaadaardige acties zien. Deze worden overzichtelijk weergegeven in een dashboard zodat stakeholders inzicht krijgen. Hoewel niet vereist door PCI DSS 4.0.1, blokkeren en melden sommige platforms ook (kwaadaardige) wijzigingen.
2. Documenteer waarom elk script nodig is met een zakelijke rechtvaardiging (PCI 6.4.3)
Handmatig voldoen aan deze eis volgt doorgaans dit proces:
-
- Exporteer een lijst met scripts via een webcrawler of browsertool, 2. Identificeer de eigenaar van elk script (intern, leverancier), 3. Log alles in een centraal document (bijv. een spreadsheet), 4. Voeg een tekstveld toe met een rechtvaardiging waarom het script noodzakelijk is, 5. Werk het document bij wanneer scripts worden toegevoegd, verwijderd of gewijzigd.
Een client-side intelligence platform:
- Slaat elke rechtvaardiging direct op naast het script in je overzicht, zodat de context altijd actueel is op één centrale locatie.
- Genereert AI-gestuurde rechtvaardigingen voor elk script. Dit geeft teams een kant-en-klaar startpunt dat ze kunnen beoordelen, goedkeuren of aanpassen.
3. Verifieer de integriteit van elk script om te garanderen dat het niet is gewijzigd (PCI 6.4.3)
Kwaadwillenden kunnen scripts aanpassen zodat ze zich anders gedragen dan oorspronkelijk bedoeld. Bijvoorbeeld:
- Betaalformulieren aanpassen om gegevens naar een door de aanvaller beheerde server te sturen (data-exfiltratie)
- Verborgen invoervelden of keyloggers toevoegen om kaarthoudergegevens te onderscheppen
Daarom zijn meerlaagse oplossingen die JavaScript analyseren tijdens elke live sessie cruciaal. Ze zien elk script precies zoals het wordt uitgevoerd in de browser van de gebruiker. Dit maakt het voor engineers eenvoudig te begrijpen wat het script doet. AI filtert ook de wijzigingen eruit en geeft inzicht in wat de toegevoegde of gewijzigde functionaliteit mogelijk doet.
4. Detecteer en meld ongeautoriseerde scriptwijzigingen (PCI 6.4.3)
Je moet auditors kunnen laten zien hoe scripts in de loop van de tijd zijn veranderd. Een populaire aanvalstechniek is het aanbrengen van kleine aanpassingen in bestaande scripts. Deze aanpassingen worden vaak niet opgemerkt omdat securityteams niet (en realistisch gezien ook niet kunnen) elke codewijziging in elk script continu handmatig beoordelen. Een geautomatiseerde monitoringtool volgt deze wijzigingen en logt tijdstempels, zodat je een duidelijk historisch overzicht hebt om op terug te vallen.
PCI DSS 11.6.1 uitgelegd en compliancestappen
Eis 11.6.1 is iets technischer van aard. Het stelt dat personeel gewaarschuwd moet worden wanneer de HTTP-headers en scripts op betaalpagina's wijzigen. Dit is vrijwel onmogelijk handmatig te doen. Third-party JavaScript is niet ontworpen om stilte te staan. Het wordt bijgewerkt op basis van de locatie van de gebruiker, het browsertype en het tijdstip van de dag. Sommige scripts moeten om functionele redenen verschillende versies serveren. Hoe kun je deze wijzigingen dan zien, laat staan begrijpen?
Wat auditors verwachten bij PCI 11.6.1-compliance
1. Personeel waarschuwen bij ongeautoriseerde wijzigingen in HTTP-headers en scripts op betaalpagina's (PCI 11.6.1)
HTTP-headers zijn regels die de browser van een gebruiker vertellen hoe content op een pagina moet worden verwerkt. Als ze worden gewijzigd, vormt dit een beveiligingsrisico. Een client-side webbeveiliging oplossing monitort scriptdata om gedragsverschillen tussen afzonderlijke sessies te detecteren.
2. Ontvangen HTTP-headers en betaalpagina's evalueren (PCI 11.6.1)
HTTP-headers evalueren betekent onder andere het in de gaten houden van zaken zoals content security policies. Dit handmatig pagina voor pagina doen leidt onvermijdelijk tot gemiste signalen. Een client-side beveiligingstool doet dit automatisch, zodat elke header wordt gevalideerd en het evaluatieproces minder arbeidsintensief is voor je team.
3. Minimaal wekelijks uitvoeren of conform de risicoanalyse van de entiteit (PCI 11.6.1 & 12.3.1)
PCI DSS biedt hier twee opties. Voer je controles minimaal eens per week uit. Of voer ze vaker uit als je eigen risicoanalyse dat vereist. Bij handmatige uitvoering moet iemand de betaalpagina laden, de HTTP-headers ophalen, deze vergelijken met de kopie van de vorige week, en hetzelfde doen voor de pagina-inhoud. Vervolgens alles documenteren, elke week of vaker als je risicoprofiel dat vereist.
cside logt de headers elke keer dat je pagina wordt geladen, zodat je niet vastzit aan handmatige vergelijkingen. Rapporten worden regelmatig (bijv. wekelijks) naar je inbox gestuurd en opgeslagen in het platform. Dit creëert een volledig papieren spoor voor compliance.
Waarom PCI-compliance belangrijk is (voorbeelden van aanvallen en boetes)
PCI DSS bestaat om internetgebruikers te beschermen tegen diefstal van betalingsinformatie. Meer dan 72.000 websites werden alleen al in het tweede kwartaal van 2025 gecompromitteerd. Als hackers toegang krijgen om code te bewerken die in een browser wordt geladen, kunnen ze meer stelen dan creditcardgegevens. Ze stelen identiteiten. Ze plunderen bankrekeningen. Ze laten mensen achter met een puinhoop die maanden kan duren om op te lossen. Het naleven van PCI-regels helpt je boetes te vermijden die variëren van $5.000 tot $100.000. Het beschermt je ook tegen client-side datalekken die bedrijven $20 miljoen of meer kosten, naast het verlies van waardevol consumentenvertrouwen.
Vergelijking van tools voor PCI 6.4.3 & 11.6.1
Veel PCI-oplossingen zijn erop gericht het compliance-vakje aan te vinken zonder echte bescherming te bieden aan je gebruikers. Andere oplossingen gebruiken verouderde technologie, waardoor klanten verrast worden wanneer ze de PCI-audits niet halen na een implementatie van meerdere maanden. Zorg ervoor dat de oplossing van je leverancier is beoordeeld en goedgekeurd door een geaccrediteerde QSA (Qualified Security Assessor).
Verschillende technische benaderingen voor PCI 6.4.3 & 11.6.1
De volgende uitsplitsing is afkomstig uit de Client-Side Security Technology Comparison:
Op crawlers gebaseerde benaderingen scannen de pagina achteraf, en vaak slechts periodiek. Ze slagen er niet in echt gebruikersgedrag na te bootsen en aanvallers kunnen detectie eenvoudig omzeilen door schone scripts aan crawlers te serveren terwijl ze echte gebruikers aanvallen met kwaadaardige payloads.
Content Security Policies (CSP's) zijn beperkt in reikwijdte. Ze richten zich op de bron van het script in plaats van de payload. Wanneer de bron wordt gecompromitteerd, blijft dat onopgemerkt. Wanneer een dynamisch script wordt gebruikt, heeft een Content Security Policy geen manier om te weten wat dat script daadwerkelijk serveert.
Client-side JS-detectie (ook wel Agents genoemd) injecteert monitoringscripts in browsers. Ze zetten vallen op om kwaadaardige JavaScript te proberen te detecteren. Maar deze vallen zijn doorgaans gemakkelijk te vinden en daardoor te omzeilen.
cside pakt alle bovengenoemde problemen aan met een meerlaagse oplossing die JS-agents, scanners, CSP's, threat feeds en meer omvat. Het cside-platform haalt scripts ook asynchroon op naar zijn eigen servers voor uitgebreide inspectie zonder wrijving te introduceren in gebruikersstromen.
Populaire tools voor PCI 6.4.3 en 11.6.1
| Naam | Aanpak | Beoordelingen | Meer informatie |
|---|---|---|---|
| cside | Meerlaagse aanpak met JavaScript Agent | ★★★★★ (4,9 sterren) op G2 | cside-oplossingsbeoordeling |
| Feroot | JavaScript-gebaseerde detectie | ★★★★★ (4,8 sterren) op G2 | Feroot-oplossingsbeoordeling |
| Imperva | Content Security Policy (CSP) | ★★★★☆ (4,5 sterren) op G2 | Imperva-oplossingsbeoordeling |
| DataDome | JavaScript Agent | ★★★★★ (4,8 sterren) op G2 | DataDome-oplossingsbeoordeling |
| JScrambler | JavaScript Agent | ★★★★☆ (4,3 sterren) op G2 | JScrambler-oplossingsbeoordeling |
"De detectiemogelijkheden die we kregen met cside waren anders dan alles wat we eerder hadden getest. We raden het product zeker aan voor PCI en meer." - Mark D., (Citaat uit G2-review van cside)
Sub Resource Integrity (SRI) voor PCI DSS-compliance
In het PCI DSS v4.0.1-document noemt de PCI SSC SRI (sub-resource integrity) als een geldig mechanisme om scriptintegriteit te verifiëren en te voldoen aan eis 6.4.3. Je kunt meer lezen over Sub Resource Integrity om te begrijpen hoe het werkt.
Waarom SRI alleen tekortschiet voor PCI DSS 6.4.3 in de praktijk
Sub Resource Integrity werkt goed voor statische scripts, maar schiet tekort bij dynamische scripts. Veel third-party webscripts zijn dynamisch en worden regelmatig bijgewerkt. Elke legitieme wijziging vereist opnieuw hashen en opnieuw deployen, wat snel onbeheersbaar wordt. Als je site een marketingteam heeft, heb je waarschijnlijk dynamische scripts — denk aan analysetags, A/B-testtools of trackingpixels.
SRI is dus geen haalbare PCI DSS-compliance- of beveiligingsmethode voor een webomgeving met dynamische scripts.
SRI combineren met een CSP-directive (script-src) versterkt de bescherming wel, maar ook deze aanpak faalt wanneer scripts regelmatig worden bijgewerkt. Elke legitieme inhoudswijziging maakt de hash ongeldig, waardoor het script stopt met laden en mogelijk de functionaliteit op je site verstoort.
Alternatief voor SRI om scriptintegriteit te verifiëren:
In plaats van handmatig CSP en SRI te onderhouden voor PCI DSS-compliance, kun je een tool voor scriptintegriteitsmonitoring inzetten. Moderne oplossingen zoals cside scannen continu op verdachte wijzigingen en waarschuwen bij veranderingen op basis van diverse datapunten:
- Continue AI-analyse: Evalueert hoe scripts zich gedragen in de browser om afwijkingen of geïnjecteerde code te signaleren.
- Historische hashvergelijking: Volgt wijzigingen over eerdere scriptversies voor nauwkeurige forensische analyse van manipulatie of updates.
- Threat intelligence: Vergelijkt scripts met bekende blootstellingen in de webtoeleveringsketen die van invloed zijn op scripts op je site.
Hulp van ons team
Heb je verduidelijking nodig over PCI 6.4.3 of 11.6.1? Ons team kan blinde vlekken in je huidige infrastructuur beoordelen en laten zien hoe cside compliance eenvoudiger maakt.
cside geeft je alles wat je nodig hebt om PCI 6.4.3 en 11.6.1 te halen.
✓ Inventariseer automatisch elk script op je betaalpagina's en volg wijzigingen in realtime.
✓ Sla rechtvaardigingen op en bespaar uren tijd met AI-gegenereerde rechtvaardigingen die je kunt goedkeuren of bewerken.
✓ Monitor HTTP-headers en detecteer ongeautoriseerde wijzigingen, met directe meldingen aan je team.
Verkorte checklist voor PCI DSS 6.4.3 & 11.6.1
Voor 6.4.3 en 11.6.1 is dit de verkorte checklist die we doorlopen in ons eerste gesprek met securityteams:
| ◯ | Heb je een mechanisme waarmee je kwaadaardige scripts kunt detecteren? |
| ◯ | Heb je een mechanisme waarmee je kwaadaardige scripts tegenhoudt (en kun je aantonen dat het de code daadwerkelijk heeft gecontroleerd)? |
| ◯ | Houd je een lijst bij van de scripts met zakelijke en technische rechtvaardiging? |
| ◯ | Monitor je HTTP-headers op een webpagina? |
| ◯ | Begrijp je de verschillende technische benaderingen voor client-side beveiliging? (CSP, JS Agent, Proxy)? |
| ◯ | Ben je van plan te voldoen aan de nieuwe vereisten met een zelfgebouwde oplossing of met kant-en-klare tools? |
Veelgestelde vragen over PCI DSS 6.4.3 & 11.6.1
Ben je vrijgesteld van PCI 6.4.3 & 11.6.1? (Zelfevaluatie voor SAQ A)
De update van PCI DSS in januari 2025 voor SAQ A introduceerde mogelijke vrijstellingen van 6.4.3 en 11.6.1, maar de criteria zijn vaag en op hoog niveau geformuleerd. In de praktijk moet je aantonen dat je betaalpagina's geen third-party scripts of andere dynamische content bevatten. Dit scenario is voor de meeste merchants zeldzaam. Een vrijstelling is uiterst moeilijk te verkrijgen. Voor een gedetailleerde uitleg van de criteria en een visuele beslisboom waarmee je je eigen situatie kunt beoordelen, lees ons artikel "Wat is een SAQ A en hoe pas je het toe".
Hoe voldoe je gratis aan PCI DSS 6.4.3
Er zijn geen leverancierstools die je volledig PCI-compliant maken zonder kosten. Sommige bieden een gratis proefperiode of een beperkte gratis laag, maar bij enig significant webverkeer betaal je gebruiksgebaseerde kosten. De andere optie is het bouwen van een eigen oplossing in huis. Zelfs als je de benodigde technische kennis in huis hebt, kost dit uiteindelijk veel meer dan het aanschaffen van een kant-en-klare oplossing. Als je de technische details wilt weten van wat een zelfgebouwde aanpak inhoudt, lees dan ons artikel: PCI-compliance bereiken zonder een oplossing te kopen.
