De PCI SSC heeft een FAQ gepubliceerd over de geschiktheid voor SAQ A-bedrijven, met betrekking tot scripts op hun site, verwijzend naar vereisten 6.4.3 en 11.6.1 in PCI DSS 4.0.1.
Deze update zorgde voor verwarring bij assessors, onze klanten en prospects.
SAQ A is bedoeld voor merchants die de betalingsverwerking volledig uitbesteden aan PCI DSS-gecertificeerde externe dienstverleners. Er mogen geen kaarthoudergegevens worden verwerkt, opgeslagen of verzonden via de systemen van de merchant.
Een veelvoorkomend misverstand is dat het gebruik van een iframe of redirect voldoende is. Dat is het niet.
De kernvereiste is dat de merchant geen scripts mag laden die interactie hebben met de betaalpagina. Als er scripts van het domein van de merchant of van derden aanwezig zijn, is SAQ A niet van toepassing.
De rol van scripts in SAQ A-compliance
- Het betaalformulier moet volledig worden gehost en beheerd door een PCI-conforme aanbieder.
- De merchant mag geen scripts laden die het betaalformulier op enige wijze wijzigen, monitoren of ermee interacteren.
- De enige toegestane scripts moeten rechtstreeks worden beheerd door de gecertificeerde betalingsaanbieder.
Als je checkout-pagina JavaScript bevat — voor analytics, UI-verbeteringen of externe tools in het algemeen — kom je mogelijk niet in aanmerking voor SAQ A. Zelfs als een script de betaalvelden niet aanraakt, kan het toch risico's introduceren, zoals:
- Formjacking-aanvallen die gebruikersinvoer onderscheppen voordat deze de betalingsaanbieder bereikt.
- Ongeautoriseerde DOM-wijzigingen die het betalingsproces beïnvloeden.
- Supply chain-aanvallen via scripts van derden.
Één zin wakkert discussie aan
De merchant heeft bevestigd dat hun site niet vatbaar is voor aanvallen van scripts die de e-commercesystemen van de merchant kunnen beïnvloeden.
Dit werd toegevoegd in de update van januari met betrekking tot SAQ A-bedrijven.
Hoewel PCI DSS van toepassing is op betalingen en betaalpagina's, stelt deze zin duidelijk dat de gehele site niet vatbaar is voor aanvallen van scripts. Dat is logisch. Als bijvoorbeeld een link naar een betaalpagina niet beveiligd of gemonitord is, kan een kwaadaardig JavaScript van een derde partij de link omleiden en de gebruiker alsnog compromitteren.
Hoe dat aangetoond moet worden, is onduidelijk, wat leidt tot verwarring.
De PCI SSC verwijst naar de meest recente versie van de PCI DSS SAQ A-lijst voor de volledige lijst van geschiktheidscriteria, maar deze bevat geen specifieke informatie die direct gekoppeld is aan de bovenstaande quote.
In de SAQ A-lijst verwijst deze quote rechtstreeks naar scripts die gemonitord en/of beveiligd moeten worden:
In 6.4.3 (pagina 7):
Alle scripts op de betaalpagina die worden geladen en uitgevoerd in de browser van de consument worden als volgt beheerd: Er is een methode geïmplementeerd om te bevestigen dat elk script geautoriseerd is. Er is een methode geïmplementeerd om de integriteit van elk script te waarborgen. Er wordt een inventaris bijgehouden van alle scripts met een schriftelijke onderbouwing waarom elk script noodzakelijk is.
In dit gedeelte wordt uitsluitend gesproken over alle scripts op de betaalpagina. Toch staat in de toepassingsnotities hieronder:
Deze vereiste is van toepassing op alle scripts die worden geladen vanuit de omgeving van de entiteit en scripts die worden geladen van derde en vierde partijen.
De omgeving van de entiteit vervaagt de grenzen en opent de deur naar "hun site" als geheel, zoals gebruikt in de zin die deze discussie aanwakkerde.
Omdat sites scripts dynamisch laden, kan een script van elke pagina doorlopen tot aan de checkout en zo betalingen beïnvloeden. Scripts van derden, ook als ze niets met betalingen te maken hebben of op pagina's vóór de betaalpagina worden geladen, kunnen kwetsbaarheden introduceren.
Bij Single Page Apps (SPA's) blijven scripts actief over alle weergaven heen, wat betekent dat een script dat op een willekeurige pagina is geladen nog steeds actief kan zijn tijdens de checkout. Ook bij Progressive Web Apps (PWA's) draaien scripts continu terwijl gebruikers navigeren, wat het risico op onbedoelde interacties met de betaalstroom vergroot.
In 11.6.1 (pagina 16), toepassingsnotities:
De bedoeling van deze vereiste is niet dat een entiteit software installeert in de systemen of browsers van haar consumenten, maar dat de entiteit technieken gebruikt zoals beschreven onder Voorbeelden in de PCI DSS-richtlijnenkolom (van PCI DSS-vereisten en testprocedures) om onverwachte scriptactiviteiten te voorkomen en te detecteren.
Dit brengt ons bij die voorbeelden, te vinden in de SAQ A-lijst op pagina vi. In het gedeelte "Not Applicable" staat:
De vereiste is niet van toepassing op de omgeving van de merchant. (Zie "Richtlijnen voor niet-toepasselijke vereisten" hieronder voor voorbeelden.) Alle antwoorden in deze kolom vereisen een ondersteunende toelichting in Bijlage D van deze SAQ.
Er wordt slechts één voorbeeld gegeven in "Richtlijnen voor niet-toepasselijke vereisten":
Vereisten voor het beveiligen van alle media met kaarthoudergegevens (Vereisten 9.4.1 - 9.4.6) zijn alleen van toepassing als een merchant papieren media met kaarthoudergegevens opslaat; als er geen papieren media worden opgeslagen, kan de merchant Niet van toepassing selecteren voor die vereisten.
"Bijlage D" verwijst slechts naar een ruimte waar het bedrijf dat SAQ A-status aanvraagt, of assessors die deze bedrijven beoordelen, hun bevindingen en conclusies over dit onderwerp kunnen invullen.
Hoe voldoe je aan de vereisten?
Naast alle andere SAQ A-vereisten moeten bedrijven aantonen dat hun website beschermd is tegen ongeautoriseerde scriptgebaseerde aanvallen. Hoe ze dat aantonen, is niet vastgelegd. Wij bij cside hebben een tool ontwikkeld die dit doet en bedrijven in staat stelt het vakje aan te vinken voor vereisten 6.4.3 en 11.6.1. Afhankelijk van de website-inrichting zijn er echter ook andere manieren, mits deze voldoen aan de overige vereisten die nodig zijn voor SAQ A-geschiktheid.
Moet je voldoen aan 6.4.3 en 11.6.1?
Als je in aanmerking komt voor SAQ A, ben je technisch gezien vrijgesteld van zowel vereiste 6.4.3 als 11.6.1.
SAQ A-geschiktheid vereist echter dat je bevestigt dat je gehele site niet vatbaar is voor scriptgebaseerde aanvallen die je e-commercesysteem kunnen compromitteren. Hoewel de PCI SSC niet expliciet definieert hoe je dit valideert, betekent het dat je moet waarborgen dat:
- Er geen ongeautoriseerde scripts op je site actief zijn.
- Je checkout-proces beschermd is tegen manipulaties (bijv. redirect-kaping).
- Je alle integraties van derden monitort en beveiligt.
Als je niet in aanmerking komt voor SAQ A, moet je voldoen aan zowel 6.4.3 als 11.6.1, omdat je omgeving valt onder een hogere compliancecategorie waarvoor aanvullende beveiligingsmaatregelen vereist zijn.
En dit alles geldt voor de gehele site, zoals de zin — "De merchant heeft bevestigd dat hun site niet vatbaar is voor aanvallen van scripts die de e-commercesystemen van de merchant kunnen beïnvloeden." — stelt.
Voorbeelden die niet in aanmerking komen (SAQ A niet toegestaan)
- Op maat gebouwde checkout met directe API-aanroepen naar een verwerker (SAQ D vereist).
- Een checkout-pagina die onbeveiligde scripts bevat die betaalvelden beïnvloeden.
- Gebruik van door derden gehoste velden maar deze aanpassen via JavaScript.
- Niet bevestigen dat de site niet vatbaar is voor aanvallen van scripts die de e-commercesystemen van de merchant kunnen beïnvloeden.
Conclusie
SAQ A biedt een vereenvoudigd compliancetraject voor merchants die de betalingsverwerking volledig kunnen uitbesteden, maar de meest recente verduidelijkingen benadrukken een cruciale verschuiving: beveiligingsverantwoordelijkheden stoppen niet bij de betaalpagina.
Hoewel 6.4.3 en 11.6.1 niet van toepassing zijn op SAQ A-merchants, is het waarborgen dat de gehele site beschermd is tegen scriptgebaseerde aanvallen nu een vereiste.
Dit betekent dat merchants proactieve beveiligingsmaatregelen moeten nemen — niet alleen om compliant te blijven, maar ook om bedreigingen te voorkomen die hun e-commerce-ecosysteem kunnen compromitteren. CSP, SRI en scriptintegriteitsmonitoring zullen waarschijnlijk basisverwachtingen worden in plaats van optionele beveiligingsmaatregelen.
Met cside ben je automatisch compliant met 6.4.3 en 11.6.1.
Wij helpen merchants bij het detecteren, monitoren en beperken van scriptgebaseerde risico's. Als je twijfelt over je compliance, kunnen wij je helpen het vakje aan te vinken en veilig te blijven.
Neem contact met ons op om je client-side omgeving te beveiligen en SAQ A-compliance met vertrouwen te handhaven.
