Capacités de chiffrement du navigateur : ce que les navigateurs modernes peuvent faire

Les navigateurs modernes embarquent une cryptographie native qui rivalise avec les bibliothèques de sécurité dédiées. Chrome, Firefox, Safari et Edge exposent tous l'API Web Crypto (crypto.subtle), implémentent TLS 1.3 avec des mécanismes successeurs à l'épinglage de certificat, supportent WebAuthn/passkeys pour une authentification résistante au phishing, isolent chaque origine grâce à Site Isolation, et offrent un stockage de clés sécurisé par matériel via le Trusted Platform Module sous Windows et la Secure Enclave sous macOS/iOS. Pour les développeurs qui construisent des outils de transfert de fichiers chiffrés, cela signifie que le chiffrement AES-256-GCM, la dérivation de clés PBKDF2 et l'authentification FIDO2 sont disponibles sans bibliothèque externe. Voici ce que chaque navigateur peut réellement faire en 2026.

API Web Crypto : la base commune

Les quatre navigateurs majeurs supportent l'API W3C Web Cryptography avec une surface quasi identique. Les algorithmes principaux sont :

Symétrique : AES-GCM, AES-CBC, AES-CTR, AES-KW (128, 192, 256 bits)
Asymétrique : RSA-OAEP, RSA-PSS, RSASSA-PKCS1-v1_5 (jusqu'à 4096 bits), ECDSA et ECDH (P-256, P-384, P-521)
Hachage : SHA-1, SHA-256, SHA-384, SHA-512
Dérivation de clés : PBKDF2, HKDF
MAC : HMAC

Ce qui manque : ChaCha20-Poly1305 (aucun support navigateur), Argon2 (aucun support navigateur), Ed25519/X25519 (Safari 17+ et Firefox 129+ l'ont, Chrome suit). Pour ceux-là, vous avez encore besoin de bibliothèques JavaScript ou WASM comme libsodium.js ou @noble/curves.

Chrome et Edge partagent la même implémentation crypto (BoringSSL via V8). Firefox utilise NSS. Safari utilise CoreCrypto, la bibliothèque validée FIPS d'Apple. Les performances varient : les itérations PBKDF2 de Firefox tournent environ 20 % plus lentement que Chrome sur du matériel équivalent ; AES-GCM de Safari avec accélération matérielle sur Apple Silicon est environ 2 fois plus rapide que Chrome sur le même Mac.

TLS 1.3 et Certificate Transparency

Chaque navigateur majeur utilise TLS 1.3 par défaut sur les origines supportées et ne revient à TLS 1.2 que pour les serveurs anciens. Chrome a supprimé le support de TLS 1.0 et 1.1 dans Chrome 84 (juillet 2020). Firefox les a supprimés dans Firefox 78. Safari les a abandonnés dans macOS 11 / iOS 14.

La Certificate Transparency est appliquée : les certificats émis après avril 2018 doivent apparaître dans au moins deux journaux CT ou Chrome et Safari les rejetteront. Cela permet de détecter tôt les attaques de type DigiNotar en rendant les émissions incorrectes des CA publiquement auditables. Mozilla Firefox a commencé à appliquer CT dans Firefox 117 (2023).

L'épinglage de clé publique via l'en-tête HPKP a été déprécié (Chrome 72 a supprimé le support) car il permettait des attaques de verrouillage. Les entreprises ayant besoin d'épinglage y ont toujours accès via l'épinglage de racine de confiance dans les configurations gérées (MDM sur macOS, politiques Chrome Enterprise).

Isolation d'origine et sandboxing

Site Isolation de Chrome place chaque origine dans son propre processus OS depuis 2018 (bureau) et 2019 (Android). Fission de Firefox fait de même depuis Firefox 94. Safari utilise le modèle par processus de WebKit. Ce que cela signifie pour le chiffrement : un script cross-origin malveillant ne peut pas lire votre fichier déchiffré depuis la mémoire d'un onglet voisin, car ce voisin vit dans un processus différent avec son propre tas.

Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP) et Cross-Origin-Resource-Policy (CORP) permettent aux pages d'opter pour une isolation encore plus stricte. Définir Cross-Origin-Opener-Policy: same-origin et Cross-Origin-Embedder-Policy: require-corp active l'isolation cross-origin, qui déverrouille à son tour SharedArrayBuffer et les minuteries haute résolution. Pertinent pour la cryptographie car les attaques de timing de style Spectre contre les implémentations AES sont atténuées quand l'attaquant ne peut pas ouvrir un SAB dans votre origine.

WebAuthn et Passkeys pour l'authentification

FIDO2 WebAuthn est supporté dans Chrome 67+, Firefox 60+, Safari 14+ et Edge 18+. Il permet aux applications d'authentifier les utilisateurs via des clés matérielles (YubiKey, Titan), des authentificateurs de plateforme (Face ID, Windows Hello, biométrie Android) ou des passkeys synchronisées entre les appareils d'un utilisateur via iCloud Keychain, Google Password Manager ou 1Password.

Pour une application de transfert de fichiers, WebAuthn remplace les mots de passe comme facteur protégeant l'accès à un lien de partage stocké. Surtout, WebAuthn est résistant au phishing : la signature est liée à l'origine, donc un domaine imitateur ne peut pas capturer les identifiants. Chrome et Safari ont tous deux adopté des flux passkey par défaut en 2023-2024, supprimant l'exigence de clé physique pour la plupart des usages grand public.

Stockage de clés sécurisé par matériel

Sur Windows, la puce TPM 2.0 (obligatoire sur Windows 11) peut stocker des clés Web Crypto générées comme non-extractables via le pont Windows CNG. Sur macOS et iOS, la Secure Enclave détient les clés utilisées pour Face ID, Touch ID et les passkeys. Sur Android, le Keystore sécurisé par StrongBox (matériel) ou TEE (Trusted Execution Environment) offre une protection similaire.

Ce que cela signifie en pratique : une clé générée comme extractable: false via Web Crypto sur un ordinateur portable moderne peut vivre dans le TPM ou la Secure Enclave, pas en mémoire principale. Même un exploit de navigateur complet qui vide la mémoire JavaScript ne produira pas les octets de clé bruts. Pour les outils de transfert de fichiers, c'est le plus utile pour les clés de destinataire à longue durée de vie ; les clés AES éphémères par fichier n'ont pas besoin de cette protection.

Content Security Policy comme multiplicateur de sécurité

Le chiffrement est sans valeur si un script malveillant peut lire le texte en clair avant qu'il ne soit chiffré. Les en-têtes Content Security Policy permettent à un site de déclarer quels scripts sont autorisés à s'exécuter. Une politique stricte comme :

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

bloque les scripts inline et le code tiers, ne laissant aucune surface d'attaque pour les charges utiles injectées volant la crypto. Tous les navigateurs majeurs supportent CSP Level 3. Pour les applications de transfert de fichiers, combinez CSP avec Subresource Integrity (SRI) sur tout script externe pour s'assurer que même le JS tiers autorisé n'a pas été altéré.

File System Access et OPFS

L'API File System Access (Chrome 86+, Edge 86+, Safari partiel 15.2+ via Origin Private File System) permet aux applications web de lire et écrire des fichiers locaux avec la permission de l'utilisateur. L'Origin Private File System est particulièrement pertinent pour le chiffrement : c'est un système de fichiers privé par origine, géré par le navigateur, utilisé pour mettre en scène de grandes charges utiles chiffrées avant téléversement sans charger l'intégralité en mémoire.

Firefox a été plus lent à adopter FSA mais supporte OPFS depuis Firefox 111. Safari supporte OPFS partout mais a un comportement plus restrictif sur l'API File System Access plus large.

Ce que les navigateurs ne font pas encore bien

Quelques lacunes subsistent :

Argon2 n'est pas dans Web Crypto. Utilisez des bibliothèques WASM pour le hachage de mots de passe au-delà de PBKDF2.
ChaCha20-Poly1305 n'est pas exposé. AES-GCM couvre la plupart des besoins, mais ChaCha aiderait sur les appareils sans AES-NI (ARM plus anciens).
L'attestation de clés pour les clés sécurisées par matériel est limitée. WebAuthn fournit l'attestation ; l'API Web Crypto plus large ne le fait pas.
L'AEAD en streaming ne fait pas encore partie de la spec. Le chiffrement de gros fichiers nécessite une logique de découpage ou WASM.
Les algorithmes post-quantiques (Kyber, Dilithium) ne sont pas encore dans le navigateur. Google a mis en production Kyber dans les handshakes TLS (Chrome 116+) mais la crypto post-quantique exposée en JavaScript reste du domaine des bibliothèques.

Que faire aujourd'hui pour le transfert de fichiers

Une pile de transfert de fichiers crédible dans le navigateur en 2026 :

AES-256-GCM via crypto.subtle.encrypt pour le contenu des fichiers
PBKDF2-SHA-256 à 600 000 itérations pour les clés dérivées de mots de passe
crypto.getRandomValues() pour les sels et nonces (jamais Math.random)
Fragments d'URL (#key=...) pour passer les clés côté client sans exposition serveur
HTTPS avec TLS 1.3 minimum, HSTS activé, COOP/COEP pour l'isolation
CSP strict-dynamic, pas de scripts inline
Passkeys WebAuthn pour toute fonctionnalité de compte stocké
OPFS pour la mise en scène de gros fichiers sur Chrome/Edge/Safari 16+

HexaTransfer utilise essentiellement cette pile. SwissTransfer, Tresorit Send, Cryptpad et Proton Drive Share également. Les primitives sont matures et cohérentes entre navigateurs.

Tester sur tous les navigateurs

Testez toujours sur les quatre. Bugs réels : Firefox lève OperationError sur des entrées PBKDF2 que Chrome accepte silencieusement. FileReader de Safari est plus lent sur les fichiers de 2+ Go. Les écritures OPFS de Chrome sont fragmentées au-delà de 4 Go dans certaines versions. Les invites de vérification utilisateur WebAuthn diffèrent significativement (Face ID vs Touch ID vs Windows Hello vs biométrie Android). Utilisez BrowserStack, Sauce Labs, ou une matrice locale d'appareils physiques pour les tests avant mise en production.

Les navigateurs sont devenus discrètement l'une des plateformes crypto les plus complètes disponibles. Les mêmes primitives basées sur des standards qui alimentent les applications bancaires, les gestionnaires de mots de passe et les clients de messagerie sont accessibles en un seul appel JavaScript pour quiconque construit des outils de transfert de fichiers chiffrés.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.