Kort samengevat: SRI-hashes voor dynamische scripts van derden
- SRI pint statisch vast: SRI pint een hash aan een statisch bestand. Moderne derde partijen leveren code die bij elke load verandert. Merchants trekken er tientallen binnen per checkout. Iets vastpinnen dat niet stilstaat is een vinkje voor compliance, geen controle.
- De audittrail: Mastercard noemt e-skimming als de belangrijkste bron van creditcardskimming, en cside's Client-side Attack Report telde in 2025 meer dan 380.000 getroffen sites. cside genereert SRI-hashes voor de statische scripts, houdt het gedrag van de dynamische scripts in de gaten, en levert je het audittrail dat PCI DSS 6.4.3 en 11.6.1 daadwerkelijk vereisen.
- SRI is één laag: Behandel SRI niet als het doel, maar als één laag. Eindigt jouw integriteitsverhaal bij hashes, dan kan een verlopen vendor-domein of een gekaapte CI/CD-pipeline volgende week dinsdag nog steeds het betaalgedrag in de browser herschrijven.
Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.
De term 'script integrity' wordt gebruikt in complianceverplichtingen zoals PCI DSS 4.0.1, ISO 27001, HIPAA en andere frameworks - maar wat betekent deze term precies en wat wordt er verwacht?
Waarom Script Integrity Belangrijk is voor Merchants & e-commerce Bedrijven
Assets die van derden worden opgehaald, zijn afkomstig van een externe bron. Een bron onvoorwaardelijk vertrouwen is niet veilig in de snel veranderende ruimte van het internet. SaaS-bedrijven komen en gaan, en helaas hebben veel van hen geen noodplan voor de domeinen die werden gebruikt in de productieomgevingen van hun klanten.
In het verleden zijn er diverse incidenten geweest die nietsvermoedende consumenten wereldwijd hebben getroffen.
Injecties via het kapen van een externe bron kunnen op verschillende manieren plaatsvinden.
- Social engineering
- Aanvallen gericht op CI/CD
- Kwaadaardige open source-afhankelijkheden
- Malware-injecties op machineniveau op de apparaten van ontwikkelaars
- Het overnemen van een verlopen domein
Het hoeft geen geavanceerde supply-chain-aanval te zijn; het kan beginnen met een vrij alledaags toegangspunt (zoals een verlopen domein) dat aanvallers een stille opening biedt om code op je site te manipuleren zonder dat iemand het merkt.
De volgende keer dat je gebruikers informatie invoeren op je pagina's, wordt gevoelige data geoogst via geïnjecteerde iframes over betaalelementen (web skimming), gedwongen omleidingsketens, affiliate cookie hijacking, malwarelevering op apparaatniveau, of zelfs exploitatie van browser zero-days.
Script Integrity: Voor Complianceverplichtingen
Complianceframeworks verwachten steeds vaker dat bedrijven de integriteit en wijzigingsgeschiedenis van client-side scripts monitoren.
- Voor PCI DSS 4.0.1: Validatie van script integrity is vereist om te voldoen aan de vereisten voor wijzigingsdetectie in 6.4.3 & 11.6.1 (Hoe voldoe je aan PCI DSS 6.4.3 & 11.6.1)
Script Integrity: Om Client-side Aanvallen te Voorkomen
Volgens Mastercard is e-skimming de belangrijkste bron van creditcardskimming, en dit vindt plaats aan de client-side. Gecompromitteerde scripts zijn een open deur voor aanvallers om het volgende uit te voeren:
- Formjacking, Magecart-aanvallen, web skimming, kwaadaardige omleidingen voor phishing, en andere aanvalstypen die in 2025 meer dan 380.000 websites hebben getroffen (Client-side Attack Report 2025).
Script Integrity Management: Voor e-commerce Bedrijven
Elke merchant die een groot volume aan online transacties verwerkt, is een prooi-doelwit voor client-side exploitatie.
- Moderne e-commerce sites laden tientallen scripts van derden. Merchants hebben inzicht nodig in wat die scripts doen, wanneer ze veranderen, en of die wijzigingen overeenkomen met het beoogde gedrag.
Wat is Script Integrity
Misvattingen over de Term
De term script integrity wordt waarschijnlijk gebruikt als gevolg van Lexical Priming op de 'Subresource Integrity'-beheermethode waarnaar in belangrijke complianceframeworks wordt verwezen. Lexical Priming is het hergebruiken van woorden die je onlangs bent tegengekomen - we doen het allemaal.
Het gebruik van het woord 'integrity' als op zichzelf staand begrip kan echter tot verwarring leiden en is vatbaar voor interpretatie.
Wanneer heeft een Script Wel (of Geen) Integrity?
Gedrag Monitoren voor Script Integrity
Integrity kan in deze context betekenen: "zorg ervoor dat scripts zich niet kwaadaardig gedragen." Het probleem hiermee is dat data-exfiltratie op zichzelf geen kwaadaardig gedrag is, en omleiden evenmin. Veel scripts van derden doen dit om legitieme redenen, wat het zeer moeilijk maakt om wijzigingen te handhaven.
Scriptwijzigingen Monitoren voor Script Integrity
De wijzigingsfactor is waar complianceframeworks vaker naar verwijzen: zorg ervoor dat wanneer een script verandert, die wijzigingen overeenkomen met het verwachte gebruik van het script.
Wat is Subresource Integrity (SRI)?
Subresource Integrity (SRI) is een native beveiligingstool in browsers waarmee een website-eigenaar een hash kan toevoegen aan een scriptdirectief in een webapplicatie. SRI bestaat al sinds 2015, toen Google en Mozilla het in hun browsers adopteerden, en werd later in 2016 erkend door de w3c.
Doel van Sub Resource Integrity (SRI)
Het doel van SRI was om te voorkomen dat client-side opgehaalde statische resources, zoals versiegestuurde assets, plotseling dynamisch gedrag gaan vertonen. Voorbeeld: jQuery versie x.
SRI richt zich op de "wijzigingsfactor" door te verifiëren dat de inhoud van een script identiek blijft aan de bekende, vertrouwde versie.
Waarom SRI aan CSP is Toegevoegd
In de loop der jaren zijn steeds meer functionaliteiten van SRI toegevoegd aan Content Security Policies (CSP). Dit riep de vraag op: waarom beide? Beveiliging draait om gelaagdheid, dus het is goed om keuzemogelijkheden te hebben. De beperking van CSP, namelijk dat het niet actief interageert met scriptinhoud, leidde echter tot de logische volgende stap: overwegen om hashes toe te voegen aan de specificatie.
Een tijdlang vertrouwde CSP alleen op bronnen, en dat leidde tot het onderstaande probleem. Stel je voor dat er 2 dozen op je stoep worden bezorgd. Beide van dezelfde afzender, maar de ene bevat een schattig hondje en de andere een glitterbom.
Kun je aan het adres van de afzender zien welke welke is?
Het argument hier is: vertrouw niet op bronnen, maar verifieer de geleverde inhoud. Het is redelijk om te stellen dat zodra kwaadaardige inhoud van een bron afkomstig is, die bron niet langer als betrouwbaar wordt beschouwd. Maar om daar iets mee te kunnen doen, moet je nog steeds controleren wat de bron doet.
Subresource Integrity Faalt op het Dynamische Web van Vandaag
Voor het doel van voorspelbare scriptinhoud is SRI een enorme stap voorwaarts geweest. Subresource Integrity is effectief voor statische, versiegestuurde scripts, maar schiet tekort bij dynamische scripts.
De meeste client-side opgehaalde scripts zijn in 2025 dynamisch, en daar zijn goede redenen voor. Ze passen inhoud aan op basis van de geografische locatie van de gebruiker, het apparaattype, browserfuncties of personalisatievereisten. Elk van deze legitieme wijzigingen kan de hash die door SRI wordt gebruikt, ongeldig maken.
SRI Combineren met een Tool voor het Monitoren van Dynamische Scripts
Met cside kan SRI effectiever worden afgedwongen. cside detecteert statische scripts en helpt je de SRI-headers daarvoor te genereren. Dynamische scripts worden anders behandeld, met andere beveiligingsprotocollen zoals een AI-gedreven script-inspectie-engine.
Scannertools Kunnen Script Integrity Niet Verifiëren
Client-side scripts serveren verschillende inhoud op basis van User Agents, aanvraag-IP's, landen, tijdstip van de dag, enzovoort - alles binnen een request header kan leiden tot een andere server-side respons. Het is niet ongebruikelijk dat een client-side script willekeurig verschillende inhoud serveert.
Vanwege deze variabiliteit zijn op scanners gebaseerde benaderingen geen betrouwbare methode om script integrity te verifiëren. Aanvallers kunnen eenvoudig detecteren wanneer een crawler of geautomatiseerde tool het bestand opvraagt. Ze serveren simpelweg een schone versie aan de scanner en leveren de kwaadaardige payload aan een gerichte subset van echte gebruikers.
Updates voor Sub Resource Integrity
Sinds de eerste release van SRI zijn er diverse verbeteringen doorgevoerd. Een veelgehoorde zorg over SRI was dat als een scripthash niet overeenkwam, het script werd geblokkeerd, maar er geen reporting API beschikbaar was, wat resulteerde in een kapotte pagina zonder melding aan de website-eigenaar.
Met de bijgewerkte Integrity Policy-specificatie is dit nu echter mogelijk.
cside draagt bij aan SRI-verbeteringen
Er worden meer specificaties voorgesteld voor SRI, waaraan cside heeft bijgedragen. Als actief lid van de w3c (de belangrijkste organisatie die standaarden voor het web ontwikkelt) heeft cside voorstellen ingediend voor betere specificaties voor het dynamisch beheren van scripthashes.
In de huidige staat brengen hardgecodeerde scripthashes uitdagingen met zich mee die de meeste bedrijven zich niet kunnen veroorloven. Tot die tijd kan SRI een nuttig hulpmiddel zijn voor statische of voorspelbare scripts, maar het is niet de volledige oplossing voor gegarandeerde script integrity.
Hoe Script Integrity te Verifiëren voor Compliance
Gebruik een Client-side Beveiligingstool
Hoewel de exacte definitie van "script integrity" per framework anders wordt geïnterpreteerd, is er brede overeenstemming over één punt: kant-en-klare vendoroplossingen zijn de meest praktische weg om script integrity te verifiëren. Een interne ontwikkeling van deze mogelijkheden zou maanden in beslag nemen en moet continu worden onderhouden naarmate aanvallers hun technieken aanpassen.
Tijdens ons recente webinar met BARR Advisory zei compliance-consultant Kyle Kofsky het onomwonden: de standaardaanbeveling voor organisaties die de script integrity-vereisten van PCI DSS 6.4.3 & 11.6.1 aanpakken, is om een gevalideerde vendoroplossing te adopteren.
Gebruik cside om Script Integrity te Verifiëren
Met de scriptbeveiligingsoplossing van cside voeg je eenvoudig een script toe aan je website, en monitoren wij het gedrag van elk script op je site. Je krijgt een dashboard om inzicht te krijgen in de data die elk script benadert, waar het die data naartoe stuurt, hoe dit gedrag in de loop van de tijd is veranderd, alsmede waar het script vandaan komt en of er prestatieverbeteringen mogelijk zijn.
Deze informatie wordt automatisch gedocumenteerd in het vereiste formaat voor jouw complianceverplichtingen. Of het nu gaat om privacystandaarden zoals GDPR, CCPA, of beveiligingsstandaarden gericht op het bestrijden van kwaadaardige scripts zoals PCI DSS 4.0.1, ISO 27001 en HIPAA. Onze oplossing voldoet aan en overtreft deze vereisten en is gevalideerd door de toonaangevende assessors in de branche. Bekijk ons White Paper met Vikingcloud hier.
cside wil het web veiliger maken. Door onze oplossing te gebruiken, stel je het team in staat om brancheorganisaties te bewegen tot eenvoudigere en robuustere beveiligingsmechanismen in browsers. We zijn open over beperkingen en zetten ons in om de wereld veiliger te maken. Onze motivatie: voorkomen dat onze vrienden en familie online beveiligingsangst ervaren, en merchants behoeden voor de noodzaak om prijzen te verhogen vanwege fraude.
