Web Assembly is een binair instructieformaat voor stack-gebaseerde virtuele machines dat high-performance uitvoering van code in webbrowsers mogelijk maakt. Hoewel het in een sandbox-omgeving draait, omvatten beveiligingsoverwegingen juiste inputvalidatie en geheugenveiligheid. Wasm-modules moeten met dezelfde beveiligingsinspectie worden behandeld als andere client-side code.
WebAssembly, vaak afgekort tot Wasm, is een draagbaar binair instructieformaat voor een stack-gebaseerde virtuele machine die in webbrowsers naast JavaScript draait. Talen zoals C, C++ en Rust compileren naar compacte Wasm-modules die op bijna-native snelheid worden uitgevoerd, wat het uitermate geschikt maakt voor CPU-intensief werk zoals videoverwerking, games, cryptografie en CAD-tools in de browser. Wasm vervangt JavaScript niet; de twee werken samen, waarbij JavaScript doorgaans een module laadt en de geëxporteerde functies aanroept terwijl de module terugroept naar geïmporteerde host-functies. Modules draaien binnen dezelfde browser-sandbox als paginascript en hebben, door ontwerp, geen directe toegang tot de DOM, het bestandssysteem of het netwerk, behalve via JavaScript en browser-API's.
De sandbox en het lineaire-geheugenmodel geven WebAssembly een sterke basislijn: een module kan niet buiten zijn eigen geheugen reiken of willekeurige host-mogelijkheden aanroepen zonder een expliciete import. Maar Wasm is nog steeds code, en de binaire vorm maakt het veel moeilijker voor mensen en veel scanners om te beoordelen dan leesbare JavaScript, iets wat aanvallers uitbuiten om logica te verbergen zoals cryptominers of geobfusceerde skimming-routines. Geheugenveiligheidsbugs in de originele C of C++ kunnen de compilatie overleven en binnen het eigen geheugen van de module worden gecorrumpeerd. En omdat Wasm de buitenwereld alleen via zijn JavaScript-bindingen bereikt, is zwakke of ongevalideerde lijmcode tussen de twee een veelvoorkomende plek waar injectie en misbruik binnensluipen.
Behandel Wasm-modules met dezelfde zorgvuldigheid als elke andere client-side code: bouw ze uit broncode die je vertrouwt, pin en verifieer wat je verscheept, en pas Subresource Integrity toe bij het laden van modules vanaf een CDN, zodat een gemanipuleerd binair bestand wordt afgewezen. Valideer alle data die de JavaScript-naar-Wasm-grens in beide richtingen oversteekt, en houd de omringende pagina onder een strikt Content Security Policy, dat bepaalt waarvandaan Wasm kan worden geïnstantieerd. Compileer met de geheugenveiligheidsmaatregelen die je toolchain biedt. WebAssembly is een neutrale webplatform-technologie, dus cside is er niet specifiek aan gebonden; wanneer een kwaadaardige of verborgen Wasm-payload via een third-party script binnenkomt, kunnen cside's proxy en payload-analyse het gedrag van dat script detecteren en blokkeren.
Het draait in dezelfde browser-sandbox met een geheugenmodel dat beperkt wat een module kan bereiken, wat een solide basislijn is. Maar het binaire formaat is moeilijker te auditen dan JavaScript, dus kwaadaardige logica kan zich makkelijker verbergen, en geheugenbugs uit de brontaal kunnen blijven bestaan. Op sommige punten veiliger, niet universeel.
Nee. Een Wasm-module heeft geen directe DOM-, bestandssysteem- of netwerktoegang. Het bereikt de buitenwereld alleen via JavaScript en browser-API's die het expliciet als imports krijgt. Die grens is een beveiligingssterkte, maar de JavaScript-lijmcode eromheen moet nog steeds valideren wat er doorheen gaat.
We answer client-side security questions every day. Bring yours.