Third-party scripts worden vaak sitebreed ingezet, doorgaans geïnjecteerd in de head-tags van webframeworks zoals Next.js via het _document.js-bestand. Deze wijdverspreide implementatie, hoewel handig voor ontwikkelaars en vaak aanbevolen door onboardinghandleidingen, betekent dat deze scripts op de hele site worden uitgevoerd. Dit is eenvoudiger te implementeren, maar introduceert ook beveiligingsrisico's en prestatieproblemen die vaak over het hoofd worden gezien.
Het recente datalek bij Kaiser Permanente toont de gevaren aan van slecht beheerde third-party scripts. Zoals we schreven in onze volledige analyse van het incident:
Op 29 april maakte zorgverzekeringsreus Kaiser Permanente een datalek bekend dat 13,4 miljoen huidige en voormalige verzekeringsleden trof. Het incident was het gevolg van onzorgvuldig beheerde third-party scripts. Kaiser Permanente gebruikte trackingcodes om te monitoren hoe leden door de website en mobiele applicaties navigeerden. Sommige van deze pagina's bevatten gevoelige zorggegevens, waardoor de third-party scripts onbedoeld informatie doorgaven aan externe leveranciers die daar geen toegang toe hadden mogen hebben. Hoewel het lek niet het gevolg was van een script-hijack, benadrukt het een ernstig gebrek aan toezicht op het beheer van third-party scripts.
Maar het probleem reikt verder dan het lekken van mogelijk gevoelige informatie naar externe leveranciers. Het weerspiegelt hoe third-party scripts veelvuldig worden gebruikt, maar zelden worden onderzocht of gemonitord. Laat staan beveiligd.
De risico's van sitebreed inzetten van third-party scripts
Nu we de redenen hebben besproken waarom mensen scripts vaak globaal inzetten, kijken we naar de problemen die dit met zich meebrengt.
1. Ongecontroleerde toegang tot gegevens
Dit is wat er gebeurde bij het Kaiser Permanente-incident. Third-party scripts hebben bij globale inzet vaak toegang tot gevoelige gegevens op webpagina's. Dit kan gebruikersinvoer, sessie-informatie en andere vertrouwelijke gegevens omvatten. Zonder strikte controles kunnen deze scripts gegevens onbedoeld of kwaadwillig lekken naar onbevoegde partijen. In het geval van Kaiser Permanente en andere zorgpartijen voldoen third-party scripts vaak niet aan de Health Insurance Portability and Accountability Act (HIPAA), waardoor een datalek naar deze leveranciers een ernstig incident is.
2. Supply chain-aanvallen
Aanvallers kunnen de webtoeleveringsketen compromitteren door third-party diensten aan te vallen en kwaadaardige code in scripts te injecteren. Deze gecompromitteerde scripts kunnen vervolgens malware verspreiden, gegevens stelen of andere schadelijke acties uitvoeren op elke site waar ze zijn ingezet. Dit is op zichzelf al ernstig, maar nog erger wanneer scripts globaal worden ingezet en toegang hebben tot meer gegevens en gebruikers.
cside beschermt hier uiteraard tegen.
3. Single Page Web Applications (SPA's)
SPA's gaan helemaal niet goed om met scripts. Tenzij een ontwikkelaar een harde verversing uitvoert bij het navigeren naar een gevoelige pagina, blijven alle eerder geladen scripts aanwezig. Elk third-party script dat initieel is geladen, blijft actief en heeft gedurende de hele sessie van de gebruiker potentieel toegang tot gevoelige gegevens — tenzij de pagina volledig wordt ververst. Dit vergroot het risico op datalekken en ongeautoriseerde toegang.
4. Compliance- en regelgevingsrisico's
Organisaties moeten voldoen aan diverse gegevensbeschermingsregelgeving, zoals de AVG, HIPAA en PCI DSS 4.0. Ontoereikend beheer van third-party scripts kan leiden tot niet-naleving, met hoge boetes en juridische gevolgen als resultaat.
Nu PCI DSS 4.0 vereist dat third-party scripts vóór maart 2025 worden gemonitord, is het moment aangebroken om aan de slag te gaan en cside in te zetten. Het maakt je niet alleen compliant, maar gaat verder door autonome blokkering te introduceren voor betere bescherming.
5. Prestatie- en stabiliteitsproblemen
Misschien minder ingrijpend, maar zeker merkbaar: slecht geoptimaliseerde third-party scripts vertragen websites. Uitval of problemen bij de externe dienst kunnen direct van invloed zijn op de functionaliteit en beschikbaarheid van de hostwebsite. Een site die in 1 seconde laadt, heeft een 3x hogere conversieratio dan een site die 5 seconden nodig heeft.
Bescherm jezelf tegen deze risico's
Net als de PCI DSS 4.0-richtlijnen zijn wij voorstanders van continue beveiligingsmonitoring en moedigen we alle site-eigenaren aan dit toe te passen. Wij geloven dat het toepassen op alle pagina's de meest effectieve aanpak is.
Dit kun je doen via onze gratis versie. Zelfbediening, zodat je binnen enkele minuten compliant en veilig bent. Uiteraard staan we altijd klaar om te helpen indien nodig.
Ons script herschrijft de bronnen van andere scripts op je site om ze via de cside-proxy te leiden. Het voert ook een aantal detecties aan de browserzijde uit. Hierdoor kan cside de verzoekstroom tussen de gebruiker en het third-party script bemiddelen zonder latentie toe te voegen. In sommige gevallen kan het de prestaties zelfs verbeteren door statische scripts te cachen.
Dit biedt volledig inzicht in de aangeboden scripts, 100% van de sessies, en op alle pagina's.
Voor meer informatie over hoe onze aanpak verschilt, lees je dat hier.
