PCI DSS 4.0.1

PCI DSS 4.0.1 voor webshops: van eis naar werkende checkout

Sinds 31 maart 2025 zijn de eisen 6.4.3 en 11.6.1 verplicht. Die gaan over één ding: welke scripts draaien er op je betaalpagina, en merk je het als dat verandert. Wij vertalen de eisen naar techniek en bouwen het in je webshop.

  • Scope verkleinen waar het kan
  • CSP en SRI op de checkout
  • Script-inventaris en change-detectie
Plan een vrijblijvend gesprekAlles over webshop security

PCI is geen papierwerk meer voor webshops

Jarenlang was PCI DSS voor de meeste webshops een jaarlijkse vragenlijst. Je betaalprovider regelde de kaartdata, jij vinkte wat aan. Magecart-aanvallen hebben dat veranderd. Skimmers draaien in de browser van je klant, op jouw pagina, en lezen daar kaartgegevens mee voordat ze bij de PSP aankomen.

PCI DSS 4.0 heeft daar twee eisen voor toegevoegd. Eis 6.4.3 vraagt dat je weet welke scripts er op je betaalpagina laden, waarom, en dat je hun integriteit bewaakt. Eis 11.6.1 vraagt dat je ongeautoriseerde wijzigingen aan de betaalpagina detecteert. Sinds 31 maart 2025 zijn ze verplicht. De geldende versie van de standaard is 4.0.1.

Belangrijk vooraf: wij geven geen juridisch advies en zijn geen QSA. Welke SAQ op jou van toepassing is en hoe je die invult, bepaal je met je betaalprovider of een QSA. Wat wij doen is de techniek: de scope zo klein mogelijk maken en de eisen die op je webshop landen ook echt bouwen en bewijsbaar maken.

SAQ A, A-EP of D: in grote lijnen

Welke Self-Assessment Questionnaire bij je past, hangt vooral af van hoe de betaalpagina technisch werkt. Hieronder de hoofdlijnen. Voor jouw situatie is je PSP of QSA leidend.

SituatieTypische SAQWat het technisch betekent
Klant wordt doorgestuurd naar de betaalpagina van de PSP (redirect)SAQ AKaartdata komt nooit op jouw server of pagina. Jouw site bepaalt wel waar de klant heen gaat, dus die moet beschermd blijven tegen manipulatie.
Betaalformulier volledig in een iframe van de PSPSAQ ADe kaartvelden komen van het PSP-domein. Je pagina eromheen moet nog steeds vrij blijven van scripts die het iframe kunnen vervangen of overlappen.
Jouw pagina bouwt het formulier of post zelf naar de PSP (direct post, eigen JavaScript)SAQ A-EPJouw pagina beïnvloedt hoe kaartdata verzonden wordt. Veel meer eisen, waaronder de volledige 6.4.3 en 11.6.1 op je eigen pagina's.
Kaartdata gaat via of wordt opgeslagen op jouw serversSAQ DDe volledige standaard is van toepassing. Voor vrijwel elke webshop is dit te vermijden en ook niet nodig.

Eis 6.4.3 en 11.6.1: wat ze vragen

Beide eisen gaan over de betaalpagina zoals die in de browser van je klant aankomt. Dat is precies waar een skimmer zit.

6.4.3: script-inventaris en autorisatie

Elk script op de betaalpagina staat op een lijst, met een reden waarom het nodig is. Er is een methode om te bevestigen dat het geautoriseerd is, en een methode om de integriteit te bewaken. Content Security Policy en Subresource Integrity zijn de gangbare technische invulling.

Lees verder →

11.6.1: wijzigingen en manipulatie detecteren

Een mechanisme dat je waarschuwt bij ongeautoriseerde wijzigingen aan HTTP-headers en inhoud van de betaalpagina, zoals de browser die ontvangt. Dat draait periodiek, op een frequentie die je onderbouwt.

Lees verder →

Wijziging voor SAQ A in 4.0.1

In 4.0.1 zijn 6.4.3 en 11.6.1 voor SAQ A-merchants vervangen door een voorwaarde dat de site niet vatbaar is voor scriptaanvallen die de betaaloplossing raken. Hoe je dat aantoont, stem je af met je PSP of QSA. Technisch komt het op hetzelfde neer: controle over scripts.

Wat het niet vraagt

Geen dure tool per se. Een goed ingestelde CSP met rapportage, SRI op eigen en externe scripts, en monitoring van de checkout dekken een groot deel. Een commerciële monitoringdienst kan, maar is niet altijd nodig.

Magento 2.4.7: CSP en SRI zitten in de core

Magento 2.4.7 zet Content Security Policy standaard in restrict mode op betaalpagina's, zoals de checkout. Op de overige pagina's staat CSP in report-only. Daarnaast voegt 2.4.7 Subresource Integrity toe voor alle JavaScript op betaalpagina's, uit te breiden naar andere pagina's. Dit is expliciet gericht op PCI DSS 4.0 eis 6.4.3 en ondersteunt 11.6.1.

De CSP-module kun je in 2.4.7 niet meer uitzetten. Dat is goed, maar het heeft een keerzijde. Strikte CSP breekt vaak extensies die inline scripts injecteren of scripts laden van domeinen die niet op de whitelist staan. Denk aan tracking, chat, review-widgets en oudere betaalmodules. Je merkt dat aan een checkout die half laadt of een betaalmethode die niet verschijnt.

Wij lossen dat op door per script te kiezen: whitelisten via csp_whitelist.xml met een duidelijke reden, omzetten naar een nonce of hash, of verwijderen van de betaalpagina. Dat laatste is vaak de beste keuze. Een chatwidget hoort niet op de stap waar iemand een kaartnummer typt.

Draai je nog op een oudere 2.4-versie, dan is upgraden de meest robuuste route. Waar dat niet direct kan, bouwen we CSP en SRI zo goed mogelijk na en zorgen we dat het upgradepad duidelijk is. Let ook op het end-of-support van je versie: zonder security-patches wordt elke PCI-verklaring lastig te onderbouwen.

Scope verkleinen: de grootste winst

Hoe minder van je webshop met kaartdata te maken heeft, hoe minder eisen er op je landen. Daar begint elk traject.

Betaalmethode en integratie

  • Kies waar mogelijk voor redirect of een volledig iframe of hosted fields van de PSP
  • Vermijd eigen JavaScript dat kaartdata leest, formatteert of doorpost
  • Controleer of oude betaalmodules nog direct-post gebruiken en vervang ze
  • Laat 3-D Secure en wallets via de PSP-componenten lopen

Betaalpagina opschonen

  • Haal tag managers, chat, A/B-testing en review-widgets van de betaalstap
  • Laad alleen scripts die nodig zijn om de betaling af te ronden
  • Gebruik SRI-hashes op elk script, ook die van externe domeinen waar dat kan
  • Zet CSP-rapportage aan en lees de rapporten echt

Omgeving en toegang

  • Admin achter 2FA en bij voorkeur IP-beperking of VPN
  • Patches binnen een vaste termijn, zeker voor kritieke Magento-bulletins
  • Geen kaartdata in logs, e-mails, notities of support-tickets
  • Duidelijk wie wijzigingen aan de checkout mag deployen

Shopify, Hyvä en headless

Shopify

Shopify is zelf PCI DSS-compliant voor de checkout. Met checkout extensibility heb je minder ruimte voor eigen scripts op de betaalstap, wat voor 6.4.3 juist gunstig is. Jouw verantwoordelijkheid zit in apps, thema-scripts en staff-accounts.

Lees verder →

Hyvä

Hyvä werkt met Alpine.js en heeft een CSP-compatibele aanpak zonder unsafe-eval. Minder third-party JavaScript betekent een kleinere inventaris en minder breuk bij strikte CSP.

Lees verder →

Headless en maatwerk

Bij een eigen frontend of Laravel-checkout ben jij verantwoordelijk voor de CSP-headers en script-integriteit. Wij bouwen dat in de applicatie en de deploy-pipeline in, zodat een release niet ongemerkt nieuwe scripts toevoegt.

Lees verder →

Zo werken we

We beginnen bij de vraag welke eisen technisch op je webshop landen, niet bij een vragenlijst.

  1. 1

    1. Betaalflow in kaart

    We bekijken hoe de betaling technisch loopt: redirect, iframe, hosted fields of eigen formulier. Daarmee kun je met je PSP of QSA de juiste SAQ bepalen.

  2. 2

    2. Script-inventaris

    We leggen vast welke scripts op je betaalpagina's laden, waar ze vandaan komen en waarom. Alles zonder goede reden gaat eraf.

  3. 3

    3. CSP en SRI inrichten

    In Magento 2.4.7+ zetten we de ingebouwde CSP en SRI goed neer en lossen we breuk in extensies op. Op andere platforms bouwen we het equivalent.

  4. 4

    4. Detectie en alerts

    We richten CSP-rapportage en monitoring van de betaalpagina in, zodat een gewijzigd script of header een melding geeft bij iemand die erop reageert.

  5. 5

    5. Documentatie en borging

    Je krijgt de inventaris, de onderbouwing en een beschrijving van de controles. Bruikbaar als technisch bewijs richting je PSP of QSA, en bij elke release te actualiseren.

Wat je krijgt

  • Technische beschrijving van je betaalflow als basis voor de SAQ-keuze
  • Script-inventaris van je betaalpagina's met reden per script
  • Werkende CSP in restrict mode op de checkout, zonder kapotte betaalmethodes
  • SRI op JavaScript op betaalpagina's
  • CSP-rapportage en change-detectie met alerts
  • Advies om de scope te verkleinen, op volgorde van impact
  • Documentatie die je bij elke release kunt bijwerken

Waarom Coding.nl

We bouwen het zelf

Geen rapport dat je daarna zelf moet laten uitvoeren. Hetzelfde vaste team analyseert, bouwt en test de checkout.

Diep in Magento en Hyvä

Hyvä Silver Partner en Hyvä Certified. We kennen de CSP- en SRI-implementatie van Magento 2.4.7 en weten welke extensies erop breken.

Eerlijk over scope

Vaak is de beste PCI-maatregel minder bouwen, niet meer. Een iframe of redirect kan een hoop werk schelen. Dat zeggen we ook als het ons minder uren oplevert.

15+ jaar e-commerce

We hebben betaalmodules zien komen en gaan, en weten waar oude integraties nog kaartdata aanraken die daar niets te zoeken heeft.

Hyvä Silver PartnerHypernode Silver Partner

Verder lezen

Veelgestelde vragen

Ja. Elke merchant die kaartbetalingen accepteert valt onder PCI DSS, ook als de PSP de kaartdata verwerkt. Wel bepaalt de manier van integreren hoeveel eisen op jou landen. Met een redirect of volledig iframe is dat veel minder dan met een eigen formulier. Welke SAQ precies past, stem je af met je betaalprovider of een QSA. Wij leveren de technische beschrijving van je betaalflow.

Meer over security

Security-overzichtMagento securityOWASP Top 10 voor webshopsPentest webshopSecurity audit webshopWebshop gehacktShopify securityLaravel & Filament securityHyväMagento support

Checkout PCI-proof maken zonder gedoe?

Stuur ons je URL en welke betaalprovider je gebruikt. We kijken hoe je betaalflow technisch loopt, wat er op de betaalpagina laadt en waar de grootste winst zit. Direct contact met het team dat het bouwt.

Neem contact op