Maakt het gebruik van Stripe je PCI-compliant?
Nee. Het gebruik van Stripe verkleint je PCI DSS-scope en kan je naar de kortere SAQ A-zelfevaluatie brengen, maar het maakt je niet volledig compliant. Stripe certificeert zijn eigen systemen, niet je website. De eisen 6.4.3 en 11.6.1 van PCI DSS 4.0.1 hebben betrekking op de scripts op je betaalpagina, en die pagina wordt nog steeds in de browser van je klant geladen. Ze blijven jouw verantwoordelijkheid.
E-commerce- en complianceteams zien dit gat vaak over het hoofd. Het uitbesteden van de kaartinvoer aan een verwerker is waardevol: het haalt kaarthoudergegevens van je servers en vermindert het aantal controls dat je zelf moet attesteren. Maar "we gebruiken Stripe" beantwoordt een vraag over waar kaartnummers worden verwerkt. Het beantwoordt niet de vraag die PCI DSS 4.0.1 nu stelt: wat doet elk script in de browser terwijl je klant zijn kaartgegevens intypt?
Wat Stripe daadwerkelijk dekt (en wat niet)
Stripe is een PCI DSS Level 1-serviceprovider, en je kunt Stripe inzetten om je PCI DSS-scope te verkleinen. Wanneer je Stripe Elements, hosted fields of Stripe Checkout gebruikt, wordt het kaartnummer ingevoerd in een iframe dat door Stripe wordt geserveerd en beheerd. De gevoelige gegevens belanden in de omgeving van Stripe, niet in die van jou. Dat is de scopevermindering waarvoor je betaalt, en die is reëel.
Wat Stripe niet doet, is eigenaarschap nemen over de pagina die zijn iframe omringt. Je checkoutpagina wordt nog steeds vanaf jouw domein geserveerd, samengesteld door jouw stack en aangekleed met jouw scripts: analytics, tag managers, session replay, chat, fraude-SDK's en wat een marketingteam afgelopen kwartaal ook maar heeft toegevoegd. Die scripts draaien in dezelfde browser als de betaalflow.
| Aspect | Stripe dekt dit | Jij bent nog steeds verantwoordelijk (6.4.3 / 11.6.1) |
|---|---|---|
| Invoer en opslag van kaartnummer | Ja, binnen Stripe's hosted iframe | Nee |
| Stripe's eigen PCI DSS-attestatie | Ja, als Level 1-serviceprovider | Nee |
| Third-party scripts op de betaalpagina | Nee | Ja, elk script inventariseren en onderbouwen (6.4.3) |
| Integriteit van die scripts (geen manipulatie) | Nee | Ja, integriteit bevestigen (6.4.3) |
| Manipulatie- en wijzigingsdetectie plus waarschuwingen | Nee | Ja, een mechanisme inzetten (11.6.1) |
| Security-relevante HTTP-headers | Nee | Ja, monitoren op ongeautoriseerde wijziging (11.6.1) |
| Je merchant-SAQ en AoC | Nee | Ja, je evalueert en attesteert zelf |
De scheiding is helder. Stripe is eigenaar van de kaartgegevens, jij bent eigenaar van de browseromgeving eromheen. PCI DSS 4.0.1 maakte die tweede kolom expliciet.
Wat eisen 6.4.3 en 11.6.1 daadwerkelijk vereisen
Beide eisen zijn ingevoerd om client-side aanvallen aan te pakken, waarbij kwaadaardige code wordt geïnjecteerd in scripts die in de browser van de klant draaien. Ze werden verplicht op 31 maart 2025 (PCI Security Standards Council, PCI DSS v4.0.1).
Eis 6.4.3: beheer je betaalpaginascripts. Voor elk script dat op de betaalpagina in de browser van de consument wordt geladen en uitgevoerd, moet je:
- Een inventaris bijhouden van alle scripts, met een schriftelijke onderbouwing waarom elk script nodig is.
- Elk script autoriseren voordat het wordt toegevoegd of gewijzigd.
- De integriteit van elk script bevestigen door te verifiëren dat het niet zonder toestemming is gewijzigd.
Eis 11.6.1: detecteer manipulatie en waarschuw. Je moet een mechanisme voor wijzigings- en manipulatiedetectie inzetten dat:
- Medewerkers waarschuwt bij ongeautoriseerde wijziging van de HTTP-headers en de scripts van de betaalpagina, zoals ontvangen door de browser van de consument.
- De ontvangen pagina minstens eenmaal per zeven dagen evalueert, of met een frequentie die is bepaald door je gerichte risicoanalyse.
6.4.3 zegt ken en autoriseer je scripts, en 11.6.1 zegt houd ze in realtime in de gaten en waarschuw wanneer ze veranderen. Aan geen van beide wordt voldaan door je betalingsverwerker, want geen van beide gaat over waar de kaartgegevens naartoe gaan. Ze gaan over wat er in de browser draait. Voor een stapsgewijze uitleg, zie onze praktische gids voor naleving van PCI 6.4.3 en 11.6.1.
Gelden deze eisen voor mij als ik SAQ A ben?
Teams worden hier op het verkeerde been gezet. SAQ A is de kortste zelfevaluatie, voorbehouden aan merchants die de verwerking van kaarthoudergegevens volledig uitbesteden. Het is verleidelijk om "volledig uitbesteed" te lezen als "niets client-side om je zorgen over te maken." Zo behandelt de PCI SSC het niet langer.
De SAQ A van januari 2025 verwijderde 6.4.3 en 11.6.1 uit de vragenlijst zelf, en voegde daarvoor in de plaats een nieuw geschiktheidscriterium toe. Om SAQ A te gebruiken moet je nu bevestigen dat je betaalpagina niet vatbaar is voor aanvallen via scripts die je e-commercesystemen kunnen treffen, en dat elk element dat aan de browser wordt geleverd rechtstreeks afkomstig is van een PCI DSS-compliant verwerker (PCI Security Standards Council, 2025). Merchants die die bevestiging niet kunnen geven, vallen buiten SAQ A en moeten rechtstreeks aan de eisen voor betaalpaginascripts voldoen. Hoe dan ook, browser-side scriptrisico is nu jouw probleem. Controleer je huidige SAQ A-versie en de bijbehorende geschiktheidscriteria tegen de PCI SSC Document Library voordat je ervan uitgaat dat je buiten scope valt.
De wijziging is terug te voeren op een specifieke gebeurtenis. Het Polyfill[.]io-incident van 2024 liet zien hoe één vertrouwd third-party script, ingesloten op meer dan 490.000 sites, van de ene op de andere dag kwaadaardig kan worden gemaakt en skim- of redirectcode aan checkoutpagina's kan serveren (Sansec, 2024). Een merchant op SAQ A met Stripe Checkout was net zo blootgesteld als ieder ander, omdat het kwaadaardige script via de eigen pagina van de merchant binnenkwam, niet via die van Stripe.
Waarom de betaalpagina nog steeds jouw aanvalsoppervlak is
Het kernprobleem is waar code draait. Stripe's iframe isoleert de kaartvelden, maar client-side aanvallen richten zich zelden rechtstreeks op het kaartveld. Ze richten zich op de pagina eromheen.
- Formulieroverlays. Een gecompromitteerd script kan een nep-kaartformulier bovenop, of naast, Stripe's iframe tekenen en gegevens vastleggen voordat ze Stripe bereiken.
- Checkout-omleiding. Geïnjecteerde code kan een klant midden in de flow naar een nagemaakte betaalpagina sturen.
- Data-oogst. Een gemanipuleerd analytics- of chatscript kan naam, e-mailadres, adres en bestelgegevens uit de DOM lezen en deze exfiltreren naar een door een aanvaller beheerd domein.
- Header-verzwakking. Gewijzigde security-relevante HTTP-headers zoals Content-Security-Policy kunnen de deur openzetten voor de bovenstaande scripts, en daarom noemt 11.6.1 headers expliciet.
E-skimming is geen zeldzaam randgeval. Magecart-achtige web skimming heeft duizenden e-commercesites getroffen, en de techniek houdt stand omdat de browser moeilijk vanaf de server te monitoren is. In de Verizon DBIR van 2024 waren betaalkaartgegevens goed voor 25% van de gelekte records in de retailsector, en retail wordt genoemd als het thuisterrein van Magecart-actoren die kwaadaardige code in checkoutpagina's invoegen (Verizon, 2024). Je serverlogs en het Stripe-dashboard zien er beide normaal uit terwijl een skimmer in de browsers van je klanten draait.
Daarom leven de eisen in de browser, niet in de backend. Lees onze gids over client-side beveiliging om te leren hoe deze aanvallen server-side controls omzeilen.
Hoe je in de praktijk aan 6.4.3 en 11.6.1 voldoet
Je kunt aan deze eisen voldoen op handmatige wijze: houd een spreadsheet bij van elk script, onderbouw elk script, hash ze en controleer de gerenderde betaalpagina wekelijks op wijzigingen. Voor een site met een handvol statische scripts houdt dat misschien stand. Voor een echte checkout waar een tag manager scripts dynamisch injecteert, valt de handmatige aanpak snel uit elkaar en levert die bewijs op waar auditors weinig vertrouwen in hebben.
Het operationele antwoord is doorlopende, geautomatiseerde scriptmonitoring die voor de betaalpagina is gebouwd. cside PCI Shield is ontworpen om rechtstreeks aan beide eisen te voldoen:
- Geautomatiseerde inventaris en onderbouwing (6.4.3). cside ontdekt elk script dat op je betaalpagina draait, bouwt de inventaris op en laat je autorisatie en onderbouwing op één plek vastleggen, met één klik en AI-ondersteunde review.
- Realtime integriteits- en manipulatiedetectie (11.6.1). cside monitort scripts en security-relevante HTTP-headers doorlopend en waarschuwt bij ongeautoriseerde wijziging, in plaats van wekelijks te samplen met een cronjob en te hopen dat er tussen de controles niets is doorgeglipt.
- Audit-klaar bewijs. cside archiveert elke scriptversie met volledige historie, zodat je een QSA forensische gegevens overhandigt in plaats van gissingen op basis van gedrag.
Het doel is niet om Stripe te vervangen. Stripe en een laag voor scriptmonitoring lossen verschillende helften van hetzelfde compliancebeeld op: Stripe haalt kaartgegevens uit scope, en cside dekt de browser-side eisen die Stripe bij jou laat.
De conclusie
Stripe gebruiken is een slimme manier om je PCI-scope te verkleinen, en het kan je op SAQ A plaatsen. Het maakt je niet volledig PCI-compliant, want de eisen 6.4.3 en 11.6.1 stellen jou verantwoordelijk voor de scripts en headers op je betaalpagina, waar Stripe's hosted fields geen invloed op hebben. Die eisen zijn verplicht, en de geschiktheid voor SAQ A zelf hangt nu af van het bevestigen dat je betaalpagina beschermd is tegen scriptmanipulatie.
Behandel de betaalpagina als je aanvalsoppervlak, inventariseer en autoriseer elk script en zet realtime manipulatiedetectie in. Voor de operationele kant daarvan, zie cside PCI Shield en client-side beveiliging, of boek een demo om je checkout door te nemen.
