De term 'script integrity' wordt gebruikt in compliancevereisten zoals PCI DSS 4.0.1, ISO 27001, HIPAA en andere frameworks — maar wat betekent deze term precies en wat wordt er van je 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 wereld 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, kan gevoelige data worden onderschept via geïnjecteerde iframes over betaalelementen (web skimming), gedwongen omleidingsketens, affiliate cookie hijacking, malware-levering op apparaatniveau, of zelfs exploitatie van browser zero-days.
Script Integrity: Voor Compliancevereisten
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 te voldoen aan PCI DSS 6.4.3 & 11.6.1)
Script Integrity: Om Client-side Aanvallen te Voorkomen
Volgens Mastercard is e-skimming de voornaamste oorzaak van creditcardfraude, 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 aantrekkelijk 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 grote 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 zelfstandig begrip kan echter tot verwarring leiden en is vatbaar voor interpretatie.
Wanneer heeft een Script (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.
In de kern richt SRI 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 — dat het niet actief interageert met scriptinhoud — leidde echter tot de logische volgende stap: het overwegen van het toevoegen van hashes aan de specificatie.
Een tijdlang vertrouwde CSP uitsluitend op bronnen, wat 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 op basis van het afzenderadres zeggen welke welke is?
Het argument hier is: vertrouw niet op bronnen, maar verifieer de geserveerde inhoud. Het is terecht om te stellen dat zodra kwaadaardige inhoud afkomstig is van een bron, die bron niet langer als betrouwbaar wordt beschouwd. Maar om daar actie op te ondernemen, moet je nog steeds controleren wat de bron doet.
Subresource Integrity Werkt Niet op het Dynamische Web van Vandaag
Voor het garanderen 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 in 2025 zijn 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 worden anders geserveerd op basis van User Agents, verzoek-IP's, landen, tijdstip van de dag, enzovoort — alles in een verzoekheader 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 veelgehoord bezwaar tegen SRI was dat als een scripthash niet overeenkwam en het script werd geblokkeerd, er geen reporting API beschikbaar was. Dit resulteerde in een kapotte pagina zonder melding aan de website-eigenaar.
Met de bijgewerkte Integrity Policy-specificatie is dit nu echter wel 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 naar het verifiëren van script integrity. 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 duidelijk: de standaardaanbeveling voor organisaties die de script integrity-vereisten van PCI DSS 6.4.3 & 11.6.1 willen naleven, is het adopteren van een gevalideerde vendoroplossing.
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 compliancevereisten. Of het nu gaat om privacystandaarden zoals GDPR en 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 stimuleren eenvoudigere en robuustere beveiligingsmechanismen in browsers mogelijk te maken. We zijn open over beperkingen en zetten ons in om de wereld veiliger te maken. Onze motivatie: voorkomen dat vrienden en familie online beveiligingsangst ervaren en merchants behoeden voor de noodzaak om prijzen te verhogen vanwege fraude.
