Capacità di crittografia del browser: cosa possono fare i browser moderni

I browser moderni integrano una crittografia nativa che rivaleggia con le librerie di sicurezza dedicate. Chrome, Firefox, Safari e Edge espongono tutti la Web Crypto API (crypto.subtle), implementano TLS 1.3 con meccanismi successori al certificate pinning tramite HPKP, supportano WebAuthn/passkey per l'autenticazione phishing-resistant, isolano ogni origine con Site Isolation, e forniscono storage delle chiavi supportato da hardware tramite il Trusted Platform Module su Windows e il Secure Enclave su macOS/iOS. Per gli sviluppatori che costruiscono strumenti di trasferimento file crittografato, questo significa che la crittografia AES-256-GCM, la derivazione delle chiavi PBKDF2 e l'autenticazione FIDO2 sono disponibili gratuitamente, senza librerie esterne. Ecco cosa può fare concretamente ogni browser nel 2026.

Web Crypto API: la base comune

Tutti e quattro i principali browser supportano la W3C Web Cryptography API con una superficie quasi identica. Gli algoritmi principali sono:

Simmetrico: AES-GCM, AES-CBC, AES-CTR, AES-KW (128, 192, 256 bit)
Asimmetrico: RSA-OAEP, RSA-PSS, RSASSA-PKCS1-v1_5 (fino a 4096 bit), ECDSA e ECDH (P-256, P-384, P-521)
Hashing: SHA-1, SHA-256, SHA-384, SHA-512
Derivazione delle chiavi: PBKDF2, HKDF
MAC: HMAC

Cosa manca: ChaCha20-Poly1305 (nessun supporto browser), Argon2 (nessun supporto browser), Ed25519/X25519 (Safari 17+ e Firefox 129+ lo hanno, Chrome sta recuperando). Per quelle hai ancora bisogno di librerie JavaScript o WASM come libsodium.js o @noble/curves.

Chrome e Edge condividono la stessa implementazione crittografica (BoringSSL tramite V8). Firefox usa NSS. Safari usa CoreCrypto, la libreria con validazione FIPS di Apple. Le prestazioni variano: le iterazioni PBKDF2 di Firefox sono circa il 20% più lente di Chrome su hardware equivalente; AES-GCM di Safari con accelerazione hardware su Apple Silicon è circa 2x più veloce di Chrome sullo stesso Mac.

TLS 1.3 e Certificate Transparency

Ogni browser principale usa TLS 1.3 di default sulle origini supportate e torna a 1.2 solo per i server legacy. Chrome ha rimosso il supporto TLS 1.0 e 1.1 in Chrome 84 (luglio 2020). Firefox li ha rimossi in Firefox 78. Safari li ha abbandonati in macOS 11 / iOS 14.

Certificate Transparency è applicato: i certificati emessi dopo aprile 2018 devono apparire in almeno due CT log oppure Chrome e Safari li rifiutano. Questo ha individuato presto gli attacchi stile DigiNotar rendendo l'emissione erronea dei CA pubblicamente verificabile. Mozilla's Firefox ha iniziato ad applicare CT in Firefox 117 (2023).

Il public key pinning tramite l'header HPKP è stato deprecato (Chrome 72 ha rimosso il supporto) perché abilitava attacchi di lockout. Gli header Expect-CT servivano lo stesso scopo di monitoraggio e stanno anch'essi venendo eliminati ora che CT è obbligatorio. Le imprese che necessitano di pinning lo hanno ancora tramite il trusted root pinning nelle configurazioni gestite (MDM su macOS, policy Chrome Enterprise).

Isolamento delle origini e sandboxing

Site Isolation di Chrome mette ogni origine nel proprio processo OS dal 2018 (desktop) e 2019 (Android). Fission di Firefox raggiunge lo stesso risultato da Firefox 94. Safari usa il modello per processo di WebKit. Cosa significa per la crittografia: uno script cross-origin malevolo non può leggere il tuo file decifrato dalla memoria di un tab gemello, perché il gemello vive in un processo diverso con il proprio heap.

Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP) e Cross-Origin-Resource-Policy (CORP) permettono alle pagine di optare per un isolamento ancora più rigido. Impostare Cross-Origin-Opener-Policy: same-origin e Cross-Origin-Embedder-Policy: require-corp abilita l'isolamento cross-origin, che a sua volta sblocca SharedArrayBuffer e i timer ad alta risoluzione. Rilevante per la crittografia perché gli attacchi di timing stile Spectre contro le implementazioni AES sono mitigati quando l'aggressore non può aprire un SAB nella tua origine.

WebAuthn e passkey per l'autenticazione

FIDO2 WebAuthn è supportato in Chrome 67+, Firefox 60+, Safari 14+ e Edge 18+. Permette alle applicazioni di autenticare gli utenti tramite chiavi hardware (YubiKey, Titan), autenticatori di piattaforma (Face ID, Windows Hello, biometrica Android), o passkey sincronizzate tra i dispositivi dell'utente tramite iCloud Keychain, Google Password Manager o 1Password.

Per un'applicazione di trasferimento file, WebAuthn sostituisce le password come fattore che protegge l'accesso a un link di condivisione memorizzato. Crucialmente, WebAuthn è phishing-resistant: la firma è vincolata all'origine, quindi un dominio simile non può catturare le credenziali. Chrome e Safari sono passati entrambi ai flussi predefiniti passkey nel 2023–2024, eliminando il requisito della chiave fisica per la maggior parte degli usi consumer.

Storage delle chiavi supportato da hardware

Su Windows, il chip TPM 2.0 (obbligatorio su Windows 11) può memorizzare le chiavi Web Crypto generate come non estraibili tramite il bridge Windows CNG. Su macOS e iOS, il Secure Enclave detiene le chiavi usate per Face ID, Touch ID e passkey. Su Android, il Keystore supportato da StrongBox (hardware) o TEE (Trusted Execution Environment) fornisce una protezione simile.

Cosa significa in pratica: una chiave generata come extractable: false tramite Web Crypto su un laptop moderno potrebbe risiedere nel TPM o nel Secure Enclave, non nella memoria principale. Anche un exploit completo del browser che scarica la memoria JavaScript non produrrà i byte grezzi della chiave. Per gli strumenti di trasferimento file, questo è più utile per le chiavi del destinatario a lungo termine; le chiavi AES effimere per file non hanno bisogno di questa protezione.

Content Security Policy come moltiplicatore crittografico

La crittografia è inutile se uno script malevolo può leggere il testo in chiaro prima che venga crittografato. Le header Content Security Policy permettono a un sito di dichiarare quali script possono essere eseguiti. Una policy rigida come:

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

blocca gli script inline e il codice di terze parti, senza lasciare superficie di attacco per i payload iniettati che rubano la crittografia. Tutti i principali browser supportano CSP Level 3. Per le app di trasferimento file, combina CSP con Subresource Integrity (SRI) su qualsiasi script esterno per garantire che anche il JS di terze parti consentito non sia stato manomesso.

File System Access e OPFS

La File System Access API (Chrome 86+, Edge 86+, parziale Safari 15.2+ tramite Origin Private File System) permette alle web app di leggere e scrivere file locali con il permesso dell'utente. L'Origin Private File System è particolarmente rilevante per la crittografia: è un filesystem privato per origine, gestito dal browser, usato per fare lo staging di grandi payload crittografati prima del caricamento senza caricare tutto in memoria.

Firefox è stato più lento nell'adottare FSA ma supporta OPFS da Firefox 111. Safari supporta OPFS su tutti i fronti ma ha un comportamento più restrittivo sulla File System Access API più ampia.

Cosa i browser non riescono ancora a fare bene

Rimangono alcune lacune:

Derivazione delle chiavi Argon2 è assente da Web Crypto. Usa librerie WASM per l'hashing delle password al di sopra di PBKDF2.
ChaCha20-Poly1305 non è esposta. AES-GCM copre la maggior parte delle esigenze, ma ChaCha aiuterebbe sui dispositivi senza AES-NI (ARM più vecchi).
Key attestation per le chiavi supportate da hardware è limitata. WebAuthn fornisce attestazione; la Web Crypto API più ampia no.
AEAD in streaming non fa ancora parte delle specifiche. La crittografia di file di grandi dimensioni richiede logica di chunking o WASM.
Algoritmi post-quantum (Kyber, Dilithium) non sono ancora nel browser. Google ha distribuito Kyber negli handshake TLS (Chrome 116+) ma la crittografia post-quantum esposta in JavaScript è ancora territorio delle librerie.

Cosa usare oggi per il trasferimento file

Uno stack credibile per il trasferimento file basato su browser nel 2026:

AES-256-GCM tramite crypto.subtle.encrypt per i contenuti dei file
PBKDF2-SHA-256 a 600.000 iterazioni per le chiavi derivate da password
crypto.getRandomValues() per salt e nonce (mai Math.random)
Frammenti URL (#key=...) per passare le chiavi lato client senza esposizione al server
HTTPS con TLS 1.3 minimo, HSTS abilitato, COOP/COEP per l'isolamento
CSP strict-dynamic, nessun script inline
Passkey WebAuthn per qualsiasi funzionalità con account memorizzato
OPFS per lo staging di file di grandi dimensioni su Chrome/Edge/Safari 16+

HexaTransfer esegue essenzialmente questo stack. Così come SwissTransfer, Tresorit Send, Cryptpad e Proton Drive Share. Le primitive sono mature e consistenti tra i browser.

Test su tutti i browser

Testa sempre su tutti e quattro. Bug nel mondo reale: Firefox lancia OperationError su input PBKDF2 che Chrome accetta silenziosamente. FileReader di Safari è più lento su file da 2+ GB. Le scritture OPFS di Chrome sono frammentate sopra i 4 GB in alcune versioni. I prompt di verifica utente WebAuthn differiscono significativamente (Face ID vs Touch ID vs Windows Hello vs biometrica Android). Usa BrowserStack, Sauce Labs o una matrice locale di dispositivi fisici per i test pre-rilascio.

I browser sono diventati silenziosamente una delle piattaforme crittografiche più complete disponibili. Le stesse primitive basate su standard che alimentano le app bancarie, i gestori di password e i client di messaggistica sono a una singola chiamata JavaScript di distanza per chiunque costruisca strumenti di trasferimento file crittografato.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 50 GB.