Encryptiemogelijkheden van browsers: wat moderne browsers kunnen

Moderne browsers leveren native cryptografie die concurreert met gespecialiseerde beveiligingsbibliotheken. Chrome, Firefox, Safari en Edge bieden allemaal de Web Crypto API (crypto.subtle), implementeren TLS 1.3, ondersteunen WebAuthn/passkeys voor phishing-resistente authenticatie, isoleren elke origin via Site Isolation en bieden hardware-backed sleutelopslag via de Trusted Platform Module op Windows en de Secure Enclave op macOS/iOS. Voor ontwikkelaars die versleutelde bestandsoverdrachtstools bouwen betekent dit dat AES-256-GCM versleuteling, PBKDF2 sleutelafleiding en FIDO2 authenticatie gratis beschikbaar zijn zonder externe bibliotheken. Hier is wat elke browser in 2026 werkelijk kan.

Web Crypto API: de gemeenschappelijke basis

Alle vier grote browsers ondersteunen de W3C Web Cryptography API met nagenoeg identieke functies. De kernalgoritmen zijn:

• Symmetrisch: AES-GCM, AES-CBC, AES-CTR, AES-KW (128, 192, 256-bit)
• Asymmetrisch: RSA-OAEP, RSA-PSS, RSASSA-PKCS1-v1_5 (tot 4096-bit), ECDSA en ECDH (P-256, P-384, P-521)
• Hashing: SHA-1, SHA-256, SHA-384, SHA-512
• Sleutelafleiding: PBKDF2, HKDF
• MAC: HMAC

Wat ontbreekt: ChaCha20-Poly1305 (geen browserondersteuning), Argon2 (geen browserondersteuning), Ed25519/X25519 (Safari 17+ en Firefox 129+ ondersteunen het, Chrome haalt bij). Daarvoor heb je nog steeds JavaScript- of WASM-bibliotheken nodig zoals libsodium.js of @noble/curves.

Chrome en Edge delen dezelfde crypto-implementatie (BoringSSL via V8). Firefox gebruikt NSS. Safari gebruikt CoreCrypto, Apple's FIPS-gevalideerde bibliotheek. Prestaties variëren: Firefox's PBKDF2-iteraties zijn ongeveer 20% langzamer dan Chrome op gelijkwaardige hardware; Safari's AES-GCM met hardwareversnelling op Apple Silicon is ruwweg 2x sneller dan Chrome op dezelfde Mac.

TLS 1.3 en Certificate Transparency

Elke grote browser gebruikt standaard TLS 1.3 op ondersteunde origins en valt terug op 1.2 alleen voor verouderde servers. Chrome verwijderde TLS 1.0 en 1.1 ondersteuning in Chrome 84 (juli 2020). Firefox verwijderde ze in Firefox 78. Safari liet ze vallen in macOS 11 / iOS 14.

Certificate Transparency wordt afgedwongen: certificaten uitgegeven na april 2018 moeten verschijnen in minstens twee CT-logs, anders weigeren Chrome en Safari ze. Dit vat DigiNotar-stijl aanvallen vroegtijdig op door verkeerde CA-uitgifte publiekelijk controleerbaar te maken. Mozilla's Firefox begon CT af te dwingen in Firefox 117 (2023).

Public key pinning via de HPKP-header werd beëindigd (Chrome 72 verwijderde ondersteuning) omdat het lockout-aanvallen mogelijk maakte. Expect-CT headers dienden hetzelfde monitoringdoel en worden zelf ook gefaseerd nu CT verplicht is. Ondernemingen die pinning nodig hebben, hebben het nog via vertrouwde root-pinning in beheerde configuraties (MDM op macOS, Chrome Enterprise-beleid).

Origin-isolatie en sandboxing

Chrome's Site Isolation plaatst elke origin in zijn eigen OS-proces sinds 2018 (desktop) en 2019 (Android). Firefox's Fission bereikt hetzelfde sinds Firefox 94. Safari gebruikt WebKit's per-proces model. Wat dit betekent voor encryptie: een kwaadaardig cross-origin script kan je ontsleutelde bestand niet lezen uit het geheugen van een zijdelingse tab, omdat de zijdelingse tab in een ander proces leeft met zijn eigen heap.

Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP) en Cross-Origin-Resource-Policy (CORP) laten pagina's kiezen voor nog strengere isolatie. Het instellen van Cross-Origin-Opener-Policy: same-origin en Cross-Origin-Embedder-Policy: require-corp schakelt cross-origin isolatie in, wat op zijn beurt SharedArrayBuffer en hoge-resolutie timers ontgrendelt. Relevant voor crypto omdat Spectre-stijl timing-aanvallen tegen AES-implementaties worden beperkt wanneer de aanvaller geen SAB in je origin kan openen.

WebAuthn en passkeys voor authenticatie

FIDO2 WebAuthn wordt ondersteund in Chrome 67+, Firefox 60+, Safari 14+ en Edge 18+. Het laat applicaties gebruikers authenticeren via hardwaresleutels (YubiKey, Titan), platform-authenticators (Face ID, Windows Hello, Android biometrie) of passkeys gesynchroniseerd over de apparaten van een gebruiker via iCloud Keychain, Google Password Manager of 1Password.

Voor een bestandsoverdrachtsapplicatie vervangt WebAuthn wachtwoorden als de factor die toegang beschermt tot een opgeslagen deellink. Cruciaal is dat WebAuthn phishing-resistent is: de handtekening is gebonden aan de origin, zodat een look-alike domein geen inloggegevens kan onderscheppen. Chrome en Safari zijn beide in 2023-2024 overgestapt op passkey-standaard workflows, waardoor de vereiste van een fysieke sleutel voor de meeste consumentengebruikers is weggevallen.

Hardware-backed sleutelopslag

Op Windows kan de TPM 2.0-chip (verplicht op Windows 11) Web Crypto-sleutels opslaan die zijn gegenereerd als niet-extracteerbaar via de Windows CNG-brug. Op macOS en iOS houdt de Secure Enclave sleutels die worden gebruikt voor Face ID, Touch ID en passkeys. Op Android biedt de Keystore ondersteund door StrongBox (hardware) of TEE (Trusted Execution Environment) vergelijkbare bescherming.

Wat dit praktisch betekent: een sleutel gegenereerd als extractable: false via Web Crypto op een moderne laptop kan in de TPM of Secure Enclave leven, niet in het hoofdgeheugen. Zelfs een volledig browser-exploit dat JavaScript-geheugen dumpt, levert de ruwe sleutelbytes niet op. Voor bestandsoverdrachtstools is dit het meest nuttig voor langlevende ontvangersleutels; tijdelijke per-bestand AES-sleutels hebben deze bescherming niet nodig.

Content Security Policy als cryptoversterker

Versleuteling is nutteloos als een kwaadaardig script plaintext kan lezen voordat het wordt versleuteld. Content Security Policy-headers laten een site verklaren welke scripts mogen uitvoeren. Een strikt beleid zoals:

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-abc123';

blokkeert inline scripts en code van derden, waardoor er geen aanvalsoppervlak is voor geïnjecteerde payloads die crypto stelen. Alle grote browsers ondersteunen CSP Level 3. Combineer CSP voor bestandsoverdrachtsapps met Subresource Integrity (SRI) op alle externe scripts om er zeker van te zijn dat zelfs toegestane JS van derden niet is gemanipuleerd.

Bestandssysteemtoegang en OPFS

De File System Access API (Chrome 86+, Edge 86+, gedeeltelijk Safari 15.2+ via Origin Private File System) laat webapps lokale bestanden lezen en schrijven met gebruikerstoestemming. Het Origin Private File System is bijzonder relevant voor encryptie: het is een privé-bestandssysteem per origin, beheerd door de browser, gebruikt voor het opslaan van grote versleutelde payloads vóór upload zonder het geheel in het geheugen te laden.

Firefox is trager geweest bij het adopteren van FSA maar ondersteunt OPFS sinds Firefox 111. Safari ondersteunt OPFS overal maar heeft meer beperkend gedrag op de bredere File System Access API.

Wat browsers nog steeds niet goed kunnen

Er blijven enkele leemten:

• Argon2 sleutelafleiding ontbreekt in Web Crypto. Gebruik WASM-bibliotheken voor wachtwoord-hashing boven PBKDF2.
• ChaCha20-Poly1305 is niet beschikbaar. AES-GCM dekt de meeste behoeften, maar ChaCha zou helpen op apparaten zonder AES-NI (oudere ARM).
• Sleutelattestatie voor hardware-backed sleutels is beperkt. WebAuthn biedt attestatie; de bredere Web Crypto API doet dit niet.
• Streaming AEAD maakt nog geen deel uit van de specificatie. Versleuteling van grote bestanden vereist chunking-logica of WASM.
• Post-kwantumalgoritmen (Kyber, Dilithium) zijn nog niet in de browser. Google heeft Kyber verzonden in TLS-handshakes (Chrome 116+), maar JavaScript-beschikbare post-kwantumcrypto is nog bibliotheekterrein.

Wat je vandaag gebruikt voor bestandsoverdracht

Een betrouwbare browser-gebaseerde bestandsoverdrachtsstack in 2026:

• AES-256-GCM via crypto.subtle.encrypt voor bestandsinhoud
• PBKDF2-SHA-256 bij 600.000 iteraties voor wachtwoordafgeleide sleutels
• crypto.getRandomValues() voor salts en nonces (nooit Math.random)
• URL-fragmenten (#key=...) om sleutels client-side door te geven zonder serverblootstelling
• HTTPS met minimaal TLS 1.3, HSTS ingeschakeld, COOP/COEP voor isolatie
• CSP strict-dynamic, geen inline scripts
• WebAuthn passkeys voor eventuele opgeslagen-account-functies
• OPFS voor grote bestandsopslag op Chrome/Edge/Safari 16+

HexaTransfer draait vrijwel op deze stack. Hetzelfde geldt voor SwissTransfer, Tresorit Send, Cryptpad en Proton Drive Share. De primitieven zijn volwassen en consistent over browsers heen.

Testen in alle browsers

Test altijd in alle vier. Praktijkbugs: Firefox gooit OperationError op PBKDF2-invoer die Chrome stilzwijgend accepteert. Safari's FileReader is langzamer op bestanden van 2+ GB. Chrome's OPFS schrijft in stukken boven 4 GB in sommige versies. WebAuthn gebruikersverificatievragen verschillen aanzienlijk (Face ID vs Touch ID vs Windows Hello vs Android biometrie). Gebruik BrowserStack, Sauce Labs of een lokale matrix van fysieke apparaten voor pre-release testen.

Browsers zijn stilletjes uitgegroeid tot een van de meest complete crypto-platforms. Dezelfde op standaarden gebaseerde primitieven die bankingapps, wachtwoordmanagers en messaging-clients aandrijven, zijn slechts één JavaScript-aanroep verwijderd voor iedereen die versleutelde bestandsoverdrachtstools bouwt.

Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.