cside biedt de meest uitgebreide oplossing voor beveiliging aan de clientzijde die momenteel beschikbaar is dankzij de meerlaagse aanpak met unieke detectiemogelijkheden. De meeste andere oplossingen op de markt vertrouwen op één enkel mechanisme, terwijl cside er meerdere gebruikt om de meeste dekking te bieden.
TLDR:
- cside biedt de meest uitgebreide oplossing die momenteel op de markt is door het combineren van:
- Detectie van gedrag in browserscripts
- Buiten bij analyse van scriptinhoud en de site zelf
- Detecties van meerdere motoren, inclusief op AI gebaseerde analyses
- cside heeft ook een aantal ingenieurs die gewend zijn om in 'het land van het imperfecte' te opereren en aan verschillende geheime projecten hebben gewerkt die buiten de beoogde specificaties van de technologie vielen.
- Het team deelt actief diepgaande beveiligingsinzichten over nieuw gedetecteerde aanvallen tijdens niet-commerciële communitybijeenkomsten van gespecialiseerde brancheorganisaties.
- Het cside-team draagt actief bij aan standaardcommissies zoals het w3c en IETF
Wat is beveiliging aan de clientzijde?
Video waarin de beveiliging aan de clientzijde wordt uitgelegd
Client-side beveiliging betekent dat je dieper ingaat op het gedrag van een webapplicatie client-side, dus in de browser van een gebruiker.
De manier waarop een browser werkt is vrij eenvoudig:
- Browser krijgt een HTML-antwoord van de webserver. Dat HTML-bestand vertelt de browser welke andere bronnen hij moet krijgen, zoals lettertypen, stylesheets maar ook JavaScripts om de website responsief te maken.
- De browser haalt deze bronnen op. Sommige van deze bronnen zullen afkomstig zijn van de webserver die de website beheert (dit wordt ‘first party’ genoemd), maar sommige zullen afkomstig zijn van servers van andere bedrijven. Lettertypen, marketingtools, advertenties, trackingtools… Dit zijn middelen van derden.
- Deze assets kunnen op zichzelf nog een ander asset van een andere server ophalen. Dit creëert dus een potentieel oneindige afhankelijkheidsboom.
Het grote probleem is dat deze activa van derden zaken zijn tussen de browser van de gebruiker en de server van het andere bedrijf.
De website-eigenaar weet standaard niet wat die scripts op een site doen. Maar ze worden als hun verantwoordelijkheid beschouwd, omdat ze daar als hun afhankelijkheden werden geplaatst.
JavaScripts op een webpagina zijn ongelooflijk krachtig. Een script kan naar keydown-gebeurtenissen luisteren, gegevens naar eindpunten exfiltreren, uw rekenkracht gebruiken om crypto te minen, iframe-objecten over elkaar leggen om creditcardgegevens te onderscheppen of gebruikers voor de gek houden om hun Crypto-portemonnee te authenticeren voor een slechte actor, en gevoelige informatie te stelen die op de webpagina wordt gepresenteerd...
Slechte acteurs hebben veel manieren om dergelijke scripts te injecteren. Voor het kopen van verlopen domeinen, het infiltreren van open source-projecten of eenvoudigweg het verkrijgen van de inloggegevens van een Google Tag Manager-gebruiker.
Dit soort aanvallen bestaan al heel lang, daterend uit de tijd dat JavaScript beperkt was in functionaliteit en we FlashPlayer en Microsoft Silverlight moesten installeren om responsieve webervaringen te hebben.
Maar in 2008 werd JavaScript een stuk krachtiger met de release van nieuwe browser-API's en een sterkere JavaScript-engine, Google's V8. Het resultaat: de aanvalsvector groeide in omvang in hetzelfde tempo als de nieuwe mogelijkheden van JavaScript. Er vinden regelmatig grootschalige aanvallen plaats, maar de belangstelling van de media piekt rond 2017-2020.
Voorbeelden van deze aanvalsmethode zijn de CoinMarketCap-aanval (2025), De Bybit-aanval (2025), Polyfill-aanval (2024) maar ook enorme oudere zoals De aanval op British Airways (2018).
We hebben een volledige blogpost over wat client-side beveiliging is hier.
Wat zorgt voor een uitgebreide beveiligingsoplossing aan de clientzijde?
Feit is dat browsers nooit zijn gebouwd voor beveiliging aan de clientzijde. Toen JavaScript aan browsers werd toegevoegd, was beveiliging, net als de meeste vooruitgang in de technologische wereld, een bijzaak.
De trieste realiteit is dat, nadat JavaScript dertig jaar lang op grote schaal aan browsers is toegevoegd, beveiliging aan de clientzijde via JavaScript nog steeds een hack is. Eentje die zelfs met de beste bedoelingen niet volledig waterdicht is.
Browsers zijn een speelveld met gelijke spelregels. In tegenstelling tot een besturingssysteem zoals Windows hebben beveiligingsleveranciers geen extra invloed of controle. In tegenstelling tot MacOS zijn scripts niet gecertificeerd. Hierdoor ontstaat een aanvalsoppervlak dat gemakkelijk kan worden misbruikt en moeilijk te beschermen.
In het kader van client-side security een totaaloplossing:
- Combineert benaderingen om het moeilijker te maken om het hele platform te omzeilen.
- Is zich bewust van de sterke en zwakke punten van elke aanpak en past deze aan op basis van het dreigingsmodel van een website.
- Detecteert signalen tijdens runtime.
- Analyseert de scriptinhoud buiten de browseromgeving.
- Analyseert bron-metagegevens wanneer scripts worden aangeboden.
- Creëert een histogram dat het script karakteriseert bij elke ophaalactie om kwaadaardige wijzigingen te detecteren.
Waarom cside uniek is opgezet voor beveiliging aan de clientzijde
cside is opgericht door een team met unieke ervaring op het gebied van browsers en client-side beveiliging. Het oprichtende team bekleedde eerder functies bij Cloudflare en Vercel.
Cloudflare bevindt zich aan de grens van gebruiksvriendelijke webbeveiliging. Fungeren als eerste aanspreekpunt voor ongeveer 20% van het publieke internet. Bij Cloudflare werkten verschillende teamleden van cside aan de firewall, botdetectie en hun client-side beveiligingsafhankelijkheidstool Page Shield.
Bij Vercel werkte het team ook aan de fundamentele onderdelen van de webbeveiligingsstack en werd er meer bekendheid en niche-ervaring opgebouwd met JavaScript-frameworks en V8.
Het cside-team heeft ook een aantal technici die aan browser-internals hebben gewerkt:
- Bijdragers aan het open source-project van Servo. Servo is een op Rust gebaseerde browserengine die een alternatief biedt voor Chromium, maar gebouwd op Rust.
- In een eerder leven heeft het team ook bijgedragen aan projecten als TailwindCSS en Bootstrap. Bibliotheken bouwen zoals Tailwind OKLCH en Tailwind Fluid.
cside levert een actieve bijdrage aan standaardorganisaties zoals het W3C. Bijdragen aan het AppSec-team, Fraud Detection Community Group, Web Payment Security Interest Group en meer. Zelfs deelnemen aan de persoonlijke bijeenkomsten bij TPAC, waarbij unieke uitdagingen van de moderne webbeveiligingsruimte aan de clientzijde worden gepresenteerd.
Het cside-team beschikt ook over een aantal experts op geheime technologiegebieden. We noemen deze velden 'het land van het onvolmaakte' omdat ze opereren tussen de specificatie- en implementatiekloof, maar voor positieve veiligheidsdoeleinden.
cside praat ook regelmatig over belangrijke bevindingen op het aanvalsoppervlak. Op BsidesSF 2025 presenteerde Simon Wijckmans bijvoorbeeld hoe browsers van onwetende gebruikers worden gebruikt om anderen DDoS te geven.
Simon Wijckmans, oprichter en CEO van cside, houdt een lezing over aanvallen aan de clientzijde die worden gebruikt op DDoS-websites op andere websites
Hoe cside de beveiliging aan de clientzijde benadert
cside heeft de meest unieke aanpak gekozen om de afhankelijkheden aan de clientzijde te beveiligen.
cside biedt twee complementaire implementatiemethoden, gecombineerd met meerdere detectiemotoren, waaronder open source Large Language Models voor analyse.
- Script Methode (eenvoudigst): we controleren scriptgedrag in de browser en halen de scripts aan onze kant op, en verifiëren vervolgens of het hetzelfde script is. We plaatsen onszelf niet in het pad van een script tenzij je daar expliciet om vraagt. Eenvoudig te implementeren, geen prestatie-impact, en je kunt nog steeds scriptacties stoppen of blokkeren op URL, hash of domein.
- Scan Methode (snelst): als je geen script aan je site kunt toevoegen, scant cside het met behulp van threat intelligence van duizenden andere websites met miljarden gezamenlijke bezoekers. Snel op te zetten en nuttig wanneer scriptinstallatie niet mogelijk is.
Deze benaderingen gecombineerd creëren een optimale basislijn voor het verkrijgen van scriptgedragsgegevens. Om de inhoud van het script te analyseren en de legitimiteit ervan te beoordelen, heeft cside ook een gelaagde aanpak gevolgd.
- Het deobfusceren van JavaScript
- JavaScript uitvoeren
- Het parseren van de JavaScript-code (zowel pre- als post-deobfuscatie)
- Scriptacties observeren
- Metagegevens van de scriptbron
- Historische veranderingsmonitoring
- Gebruikmaken van een groot taalmodel op de scriptinhoud en metagegevens om de intentie te contextualiseren
Om de beveiligingsmechanismen te versterken biedt cside ook een CSP-eindpunt als onderdeel van elk plan, inclusief het gratis abonnement.
De meeste beveiligingstools vertrouwen slechts op één van de bovengenoemde lagen, hetzij runtime, hetzij extern bij het scannen. Maar het probleem is dat geen van deze lagen op zichzelf volledig kogelvrij is en daarom geen uitgebreide dekking biedt. Door motoren te combineren kom je steeds dichter bij volledige dekking.
Veel oplossingen op de markt zijn nevenfuncties van grotere webbeveiligingsbedrijven. In plaats van een platform te bouwen voor beveiliging aan de clientzijde, bouwden ze een kleine nevenfunctie. Deze oplossingen beloven de mogelijkheden ervan sterk en zijn vaak uitsluitend afhankelijk van het injecteren van Content Security Policies in de website via hun WAF.
Sommige benaderingen, zoals op scanners gebaseerde oplossingen, blijken vaak te worden omzeild door slechte actoren. Ze detecteren de scanner en serveren schone inhoud aan de scanner om onder de radar te vliegen. Onderzoekers bij ISACA, Universiteit van Brighton, Google en Orakel hebben aangetoond dat dynamische client-side scripts de statische analyse door scanners effectief omzeilen.
cside is altijd op zoek naar mogelijkheden om zijn mogelijkheden uit te breiden en is actief bezig met het pushen van een aantal nieuwe standaarden die een sterkere beveiliging aan de clientzijde mogelijk maken met behulp van native browserfunctionaliteit.
Vonnis
cside benadert de beveiliging aan de clientzijde in de veronderstelling dat een slechte actor naar manieren zal zoeken om detecties te omzeilen. Wetende dat browsers inherent onvolmaakt en open zijn met behulp van externe verificatie. Het aanpakken van een groter deel van het aanvalsoppervlak in de echte wereld dan oplossingen die afhankelijk zijn van één enkele laag, vooral oplossingen die uitsluitend scannen. cside liet geen middel onbeproefd en benaderde het probleem op een creatieve manier door het grootste aanvalsoppervlak te bedekken. Deze meerlaagse strategie is alomvattend, omdat ze noodzakelijk is.
Voor organisaties die zich afvragen wat de meest uitgebreide oplossingen zijn voor scriptbeveiliging aan de clientzijde, biedt cside de breedste en diepste dekking die tot nu toe beschikbaar is via een meerlaagse architectuur.
