Definitie van client-side beveiliging
In de context van webbeveiliging beschermt 'client-side beveiliging' uw gebruikers tegen kwaadaardige code die via uw website aan hun browser wordt aangeboden. Kwaadaardige code-injecties omvatten creditcardskimmers, visuele overlays die gebruikers doorsturen naar phishingpagina's, of geavanceerde fraudeconstructies zoals affiliate link-fraude.
Websites serveren niet opzettelijk kwaadaardige code aan hun gebruikers. Maar 'client-side aanvallen' injecteren code via verborgen toegangspunten: third-party scripts van tools die u op uw website integreert (analyticstags, lettertypebibliotheken, open-sourcetools, plugins) en first-party scripts waarbij aanvallers geobfusceerde code plaatsen die uw beveiligingsteam niet onderschept.
'Client-side beveiliging' in verschillende contexten
| Client-side beveiligingsvector | Doel | Beschermt tegen | Gebruikt door |
|---|---|---|---|
| 1. Een stukje code installeren op uw eigen website | Gebruikers beschermen tegen aanvallen zoals web skimming. Voldoen aan kaders zoals PCI DSS of AVG. | Code-injecties die vanuit uw website aan gebruikersbrowsers worden aangeboden. | E-commercesites, SaaS-platforms en elk bedrijf dat betalingen verwerkt of persoonsgegevens verzamelt op het web. |
| 2. Software installeren op een eindgebruikersbrowser (browserextensie) | Klantgericht: Waarschuwt consumenten voor phishingsites of onveilige downloads. Medewerkersgericht: Handhaaft beleid voor het voorkomen van gegevensverlies en beheert wat medewerkers via de browser kunnen delen. | Bedreigingen die de gebruiker tegenkomt tijdens het browsen. Ongeautoriseerd gegevensverlies vanuit de browser. | Consumentenbeveiligingsleveranciers bieden veilige browserextensies aan. Bedrijven zetten ze in om browseractiviteit van medewerkers te beheren en gegevensverlies te voorkomen. |
| 3. Software installeren op een eindgebruikersapparaat | Klantgericht: Beveiligt sessies door malware op het apparaat van de klant te detecteren. Medewerkersgericht: Monitort bedrijfsbeheerde apparaten op malware. | Keyloggers, trojans en andere malware die lokaal op het apparaat van de gebruiker wordt uitgevoerd. | Banken bieden klanten gratis endpointbeveiliging aan om online banksessies te beschermen tegen lokale malware. Werkgevers zetten EDR-agents in op bedrijfsapparaten om bedreigingen te detecteren. |
Wanneer we cybersecurityconferenties bijwonen, roept het ter sprake brengen van 'client-side beveiliging' een andere perceptie op, afhankelijk van het beveiligingsdomein waarin iemand werkzaam is. De gemeenschappelijke noemer is dat 'client-side beveiliging' zich richt op het monitoren van een omgeving die draait op het apparaat van een eindgebruiker. Niet uw eigen servers, API's of netwerkverkeer.
cside opereert binnen de eerste client-side beveiligingsvector in de bovenstaande tabel. Merchants en softwareplatforms implementeren een stukje code op hun website, waarmee wij de browser-runtime van bezoekerssessies kunnen monitoren. Als vereenvoudigd voorbeeld werkt dit vergelijkbaar met analytictools die u op uw site installeert. Maar wij monitoren op tekenen van beveiligingsinbreuken en fraude, in plaats van voor marketingdoeleinden.
Waarom de client-side beveiligen?
Bij cside is ons team diep betrokken bij client-side beveiliging (de bedrijfsnaam is afgeleid van client-side). Het bedrijf is opgericht omdat we zagen dat traditionele webbeveiligingstools beperkt zicht hadden op de browser-runtime van gebruikers, waardoor een enorme blinde vlek ontstond. Als co-voorzitters van de W3C Anti-Fraud Browser Security-gemeenschap is onze missie het beschermen van consumenten en merchants tegen websitefraude.
Er wordt veel aandacht besteed aan het beveiligen van de supply chain. Ontwikkelaars scannen NPM-pakketten. Infrastructuur wordt vergrendeld. Firewalls en WAF's worden als basisvereiste beschouwd. En cloudbeveiliging is een hele categorie op zich geworden. Maar een van de grootste en snelst groeiende aanvalsoppervlakken wordt nog steeds over het hoofd gezien: de client-side. Mastercard wees erop dat bijna driekwart van de openbaar gemaakte inbreuken digitale skimming omvat.
Client-side beveiliging omvat alles wat wordt uitgevoerd in de browser van uw gebruiker. Dat omvat third-party JavaScript, pixels, iFrames, formulieren, SDK's en alle code die wordt opgehaald en uitgevoerd nadat de pagina is geladen. Dit deel van de stack wordt tijdens audits bijna altijd genegeerd, maar is verantwoordelijk voor enkele van de meest schadelijke aanvallen.
Third-party scripts worden rechtstreeks in de browser geladen en uitgevoerd met volledige toegang tot de DOM. Deze scripts kunnen formulieren scannen, gebruikersgedrag registreren, pagina-inhoud aanpassen en gegevens exfiltreren zonder ooit uw server te raken. Dit is waar client-side beveiliging het meest van belang is. Niet alleen monitoren waar de scripts vandaan komen, maar ook wat ze daadwerkelijk doen.
En het gaat mis. Regelmatig. De Polyfill supply chain-aanval trof meer dan 490.000 websites door kwaadaardige code te injecteren in een voorheen vertrouwde open-sourcebibliotheek. Daarvoor lekte Kaiser Permanente de gegevens van 13,4 miljoen patiënten doordat ingebedde client-side scripts gegevens naar ongeautoriseerde bestemmingen stuurden.
Als u geen actieve client-side scanning uitvoert, beschermt u uw gebruikers niet. Want als er iets misgaat, valt de verantwoordelijkheid op u, niet noodzakelijkerwijs op de leverancier die het script heeft aangeboden.
Client-side beveiliging is niet langer optioneel. Als uw site betalingen verwerkt, persoonsgegevens verzamelt of gebruikers vraagt in te loggen, bent u een doelwit. En de browser is waar die aanvallen plaatsvinden.
Client-side beveiligingsbedreigingen en soorten aanvallen
1. Gebrekkige client-side toegangscontrole
Toegangscontrole wordt vaak gezien als een server-side aangelegenheid. Maar client-side toegangscontroleproblemen zijn reëel en worden vaak over het hoofd gezien. JavaScript in de browser kan worden gebruikt om de DOM te manipuleren en toegang te krijgen tot gegevens of functies die nooit bedoeld waren om blootgesteld te worden. Als een script niet goed geïsoleerd is (of als tokens bijvoorbeeld in het geheugen worden bewaard), wordt het voor aanvallers eenvoudig om toegang te krijgen zonder backend-controles te activeren.
Dit is een van de stillere vormen van client-side kwetsbaarheden. En omdat het in de browser plaatsvindt, mist traditionele logging het.
2. DOM-gebaseerde Cross-Site Scripting (XSS)
DOM-gebaseerde XSS is een veelvoorkomende en hardnekkige aanval. Het treedt op wanneer JavaScript niet-vertrouwde invoer leest (zoals URL-parameters) en deze zonder sanitatie terugschrijft naar de pagina. Deze vorm van injectie is niet afhankelijk van serverreacties, waardoor het moeilijk te onderscheppen is met traditionele web application firewalls.
Client-side scantools zijn vaak de enige manier om dit in realtime te detecteren. Zonder deze tools kunnen aanvallers willekeurige scripts injecteren en de browsersessie van de gebruiker volledig compromitteren.
3. Verlopen domeinen
Wanneer een domein waarnaar in uw code wordt verwezen verloopt, kan iedereen het kopen. Als uw JavaScript nog steeds naar dat domein verwijst voor een script, stylesheet of zelfs een hardgecodeerde link, bepaalt de nieuwe eigenaar wat er wordt aangeboden. Aanvallers scannen actief naar deze kansen, omdat het domein al een vertrouwensrelatie heeft met uw site en uw gebruikers.
Ons beveiligingsonderzoeksteam ontdekte een kwetsbaarheid door een verlopen domein op de website van Oracle, waarbij een JavaScript-bestand verwees naar een domein dat was verlopen en beschikbaar was voor aankoop.
4. Lekkage van gevoelige gegevens
Client-side gegevenslekkage is een van de duurste risico's in JavaScript-beveiliging. Het treedt op wanneer scripts gevoelige informatie verzamelen (zoals namen, e-mailadressen of creditcardgegevens) en deze doorsturen naar externe domeinen. Soms is dit opzettelijk. Vaak niet.
Toen Kaiser Permanente meer dan 13,4 miljoen records lekte, was dat omdat ingebedde client-side code gegevens naar derden stuurde zonder toestemming van de gebruiker. Client-side monitoring had de exfil-pogingen gemarkeerd voordat de gegevens de pagina hadden verlaten.
5. Kwetsbare en verouderde componenten
Verouderde JavaScript-bibliotheken zijn een van de meest misbruikte toegangspunten bij client-side aanvallen. Ze worden vaak opgehaald van CDN's of third-party providers en daarna nooit meer beoordeeld. Als die bibliotheek een bekende CVE heeft en uw site laadt hem, bent u kwetsbaar.
Dit is precies wat de Polyfill-aanval zo effectief maakte. Een veelgebruikt script werd aan de bron gecompromitteerd, en de meeste bedrijven wisten niet eens dat ze het laadden. Client-side beveiliging moet bibliotheekversietracking omvatten om dit soort risico's voor te blijven.
6. Gebrek aan controle over third-party origins
De meeste client-side aanvallen beginnen niet vanuit uw eigen code. Ze komen van een third-party origin die u zonder verificatie heeft vertrouwd. Deze scripts worden geladen met volledige rechten binnen uw browseromgeving, waardoor ze toegang hebben tot alles wat de gebruiker ziet en doet.
Wanneer third-party JavaScript vrij mag worden uitgevoerd, geeft u de controle op. Tenzij u een sterk Content Security Policy (CSP) en realtime client-side scanning gebruikt, heeft u geen idee wat dat script doet. Zonder de realtime client-side scanning is een CSP in de meeste gevallen onvoldoende om het te stoppen.
De AppsFlyer Web SDK supply-chain-compromittering is een recent voorbeeld. Aanvallers kaapten DNS voor een vertrouwde marketing-SDK en serveerden een crypto-stelende payload aan duizenden sites die geen idee hadden dat hun scripts waren veranderd.
7. JavaScript drift
JavaScript drift treedt op wanneer de inhoud van een script in de loop van de tijd verandert, maar niemand het opmerkt. Een script dat vorige week veilig was, kan zich nu volledig anders gedragen. Zeker als het wordt aangeboden vanuit een externe bron. Sommige aanvallers maken hier misbruik van door geleidelijk kwaadaardig gedrag te introduceren om detectie te vermijden.
Bij cside volgen we niet alleen de URL. We registreren en analyseren de volledige payload van elk script, elke keer opnieuw. Zo detecteren we nieuwe client-side kwetsbaarheden voordat ze inbreuken worden.
8. Gevoelige gegevens opgeslagen aan de client-side
Wanneer JavaScript gegevens opslaat in localStorage, sessionStorage of cookies, zijn die gegevens toegankelijk voor elk script op de pagina, inclusief third-party scripts. Dit creëert een enorm aanvalsoppervlak voor sessiekaping, tokendiefstal en cross-site lekkage.
Als u iets gevoeligs opslaat aan de client-side (zie bovenstaande voorbeelden), heeft u strikte scoping, verlooplogica en realtime monitoring nodig om misbruik te onderscheppen. De meeste websites slaan dit volledig over.
9. Fouten in client-side logging en monitoring
U kunt niet beveiligen wat u niet observeert. De meeste organisaties behandelen logging nog steeds als een server-side verantwoordelijkheid. Maar wanneer scripts worden uitgevoerd in de browser en aanvallen in realtime plaatsvinden, heeft u ook client-side monitoring nodig.
Dit omvat inzicht in formulierinteracties, scriptgedrag, onverwachte uitgaande verzoeken en JavaScript-fouten. Zonder dit vliegt u blind.
10. Geen gebruik van standaard browserbeveiligingscontroles
Browsereigen verdedigingsmechanismen bestaan. Maar veel sites negeren ze. Content Security Policy (CSP), Subresource Integrity (SRI), iframe-sandboxing, ... dit zijn allemaal manieren om het risico van malafide scripts en geïnjecteerde inhoud te verminderen. Maar de meeste teams configureren ze verkeerd of schakelen ze volledig uit om te voorkomen dat dingen stukgaan.
Als u echte client-side beveiliging wilt, begin dan met het handhaven van de controls die de browser al ondersteunt.
11. Bedrijfseigen logica opnemen in de client
Uw frontend is zichtbaar voor iedereen. Dat omvat bedrijfslogica, prijsalgoritmen, interne routeringsregels en alles wat u naar de browser stuurt. Het is gebruikelijk om gevoelige processen hardgecodeerd in JavaScript aan te treffen, waar ze kunnen worden teruggeëngineered of misbruikt.
Dit is niet alleen een privacyrisico, het is ook een IP-risico. Als het client-side wordt uitgevoerd, is het blootgesteld. Als het blootgesteld is, moet het worden gemonitord.
"Ontwikkelaars zeggen vaak 'vertrouw de client-side nooit'—en toch injecteren we routinematig tientallen third-party client-side fetches. De realiteit is dat de client-side het primaire oppervlak voor stille aanvallen is geworden. Het is waar kwetsbaarheden gedijen, juist omdat het zo eenvoudig is om detectie te ontwijken."
— Simon Wijckmans, CEO van Cside
Waarom client-side detectie niet alleen op threat feeds kan vertrouwen
De meeste tools die beweren client-side beveiliging te bieden, vertrouwen op twee dingen:
- Allowlists
- Vooraf samengestelde threat intelligence feeds.
Aanvallers ontwerpen client-side payloads nu specifiek om deze detectiemethoden te omzeilen. Ze veranderen de scriptinhoud dynamisch. Ze richten zich alleen op specifieke websites. Ze serveren kwaadaardige code slechts één keer.
Als uw detectiemethode alleen let op bekende domeinen of eerdere aanvalshandtekeningen, ziet u niet wat er aankomt. Het script kan al gecompromitteerd zijn, maar uw tool weet het niet omdat niemand het nog heeft gemeld.
Daarom is realtime JavaScript-payload-inspectie de enige betrouwbare aanpak voor client-side scanning.
Compliancekaders die client-side beveiligingscontroles verplichten
PCI DSS 4.0.1
PCI DSS 4.0.1 verplicht bedrijven om alle client-side scripts te monitoren en te autoriseren. Vereisten 6.4.3 & 11.6.1 werden verplicht in maart 2025 en worden nu actief gehandhaafd. Als uw site betalingen verwerkt, betekent dit realtime inzicht in wat er in de browser wordt uitgevoerd. Niet alleen een statische lijst van goedgekeurde domeinen.
We hebben een handleiding over de exacte client-side mechanismen die aan deze verplichting voldoen.
AVG, CCPA en andere privacygerelateerde kaders
Als persoonsgegevens worden verzameld of doorgegeven via third-party scripts zonder toestemming of toezicht, bent u kwetsbaar. Het maakt niet uit of het script afkomstig is van een vertrouwde leverancier. U bent nog steeds verantwoordelijk.
AVG-artikelen 25, 28, 30 en 32 beschrijven onder andere de noodzaak van client-side controls, zoals inzicht in de verzamelactiviteiten van derden en waarborgen tegen gegevenslekken.
HIPAA, SOC 2 en DORA bewegen in dezelfde richting. Echte client-side beveiliging is niet langer alleen een beveiligingskwestie. Het is ook een compliancekwestie. En de handhaving neemt toe.
Verschillende benaderingen van client-side beveiliging
1. Content Security Policies (CSP's)
CSP's zijn browsercontroles die beperken welke domeinen scripts op uw pagina's mogen aanbieden. Ze zijn een goed startpunt, maar hebben echte tekortkomingen:
- Ze valideren alleen waar een script vandaan komt, niet wat het doet zodra het wordt uitgevoerd.
- Ze kunnen scripts niet onderscheppen die hun gedrag aanpassen op basis van de gebruiker, sessie of geografie.
- CSP-schendingen genereren consolefouten die ontwikkelaars ertoe aanzetten het beleid te versoepelen of volledig uit te schakelen.
De Polyfill supply chain-aanval liet precies zien wat er gebeurt als u een bron-URL vertrouwt die wordt gecompromitteerd. Het domein was toegestaan door CSP, en de kwaadaardige code werd vrijelijk uitgevoerd.
2. Crawler-gebaseerde of 'scanner'-benaderingen
Crawlertools bezoeken uw site op een schema en controleren op kwaadaardige scripts. Het probleem is dat detectie vertraagd is en eenvoudig te omzeilen:
- Aanvallers kunnen crawlers identificeren en hen schone code aanbieden terwijl ze kwaadaardige payloads leveren aan echte gebruikers.
- De meeste crawlers nemen een fractie van het verkeer als steekproef, waardoor aanvallen die gericht zijn op specifieke gebruikers of regio's erdoorheen glippen.
- Ze zien nooit het daadwerkelijke script dat de browser van een echte gebruiker ontvangt tijdens een live sessie.
3. JS-gebaseerde client-side detectie
JavaScript-gebaseerde tools draaien in de browser om scriptactiviteit in realtime te observeren. Maar ze hebben aanzienlijke zwakheden:
- Ze fungeren als vallen, maar omdat ze in dezelfde omgeving leven als de scripts die ze monitoren, kunnen aanvallers ze detecteren en vermijden.
- Ze hebben geen historische context, waardoor ze niet kunnen bijhouden hoe een script in de loop van de tijd is veranderd of forensisch onderzoek na een incident kunnen ondersteunen.
Met regelgeving zoals PCI DSS die nu client-side scriptcontroles vereist, worden deze benaderingen vaak gebruikt om snel aan de compliancevereisten te voldoen. Maar ze bieden geen echte bescherming. Ze laten bedrijven blootgesteld aan aanvallen die zich sneller aanpassen dan deze tools kunnen bijhouden.
Lees hier een uitgebreide vergelijking en selectiegids.
Hoe cside de client-side beveiligt
We hebben cside gebouwd om realtime client-side monitoring en JavaScript-bedreigingsbeveiliging te bieden zonder uw site te vertragen.
- Payload-inspectie: We leggen volledige scriptpayloads vast en vergelijken deze bij elk fetch- en laadverzoek, niet alleen het domein of de hash.
- Beheer van third-party scripts: Monitor, versiebeheer en vergrendel third-party scripts zodat ze niet stilletjes in productie kunnen veranderen.
- Detectie van gegevensblootstelling: We onderscheppen gegevens die worden gelekt naar onverwachte endpoints voordat het een complianceprobleem wordt.
- Compliancegereedheid: Of u zich nu voorbereidt op PCI DSS 4.0 of AVG-risico's beheert, wij helpen u auditklaar te blijven.
