Gros plan sur un module de sécurité intégré sous un clavier d'ordinateur portable, éclairé par l'écran.

DBSC et Vercel : sécuriser les sessions web contre le vol de cookies

Vercel déploie les Device Bound Session Credentials (DBSC) pour contrer le vol de cookies de session. Cette technologie vise à rendre inutiles les cookies d’authentification volés en les liant cryptographiquement au matériel de l’appareil d’origine. C’est une réponse directe aux logiciels espions modernes, tels que Lumma ou Vidar, qui ciblent les cookies après une connexion, même après authentification multifacteur.

Le principe est simple en théorie : le navigateur génère une paire de clés cryptographiques lors de la connexion. La clé privée est ensuite stockée dans un module sécurisé, comme un TPM (Trusted Platform Module), si le matériel le permet. Le serveur émet des cookies à courte durée de vie. Lorsque ce cookie expire, le navigateur ne se contente pas de déconnecter l’utilisateur ; il suspend la requête et tente de rafraîchir le cookie en prouvant qu’il détient la clé privée correspondante. Ce processus assure que la continuité de la session est ancrée au dispositif initial.

Malte Ubl, CTO de Vercel, a précisé cette approche : « Si un appareil de l’utilisateur ne prend pas en charge le stockage sécurisé de clés, DBSC revient gracieusement au comportement standard sans casser le flux d’authentification », a-t-il indiqué à Help Net Security.

Collage d'illustration représentant une paire de clés numériques liées par une structure solide, sur fond texturé sombre.

Les exigences techniques pour l’adoption de DBSC

Pour qu’une application bénéficie de cette protection, les développeurs doivent modifier plusieurs points de leur architecture d’authentification. Le processus débute par une modification du flux de connexion : après l’authentification réussie, le serveur doit retourner un cookie de longue durée, accompagné de l’en-tête Secure-Session-Registration. Cet en-tête informe Chrome des paramètres de session.

Ensuite, l’endpoint de ‘registration’ doit traiter la clé publique envoyée par Chrome via un JWT. Le serveur doit alors associer cette clé publique à la session de l’utilisateur, définir la configuration de session et remplacer le cookie initial par un cookie à courte durée de vie, par exemple, expiré après dix minutes.

Le point le plus technique est le rafraîchissement. Quand le cookie court expire, Chrome intercepte la requête et la dirige vers un endpoint de rafraîchissement. Le serveur répond d’abord par un défi (Secure-Session-Challenge). Chrome signe ce défi en utilisant sa clé privée stockée en hardware et renvoie la preuve signée. Si la validation réussit, le serveur réémet un nouveau cookie court, permettant à Chrome de reprendre la requête initiale. L’intégration est conçue pour être additive, nécessitant des changements minimes pour les systèmes existants.

Caractéristique Cookie de longue durée Cookie de courte durée (DBSC) Rôle en cas de vol
Durée de vie Longue Courte (ex. 10 minutes) Le cookie volé expire vite.
Validation Basée sur la session simple Basée sur la preuve de possession de la clé L’attaquant n’a pas la clé privée.
Mécanisme Standard Refresh via clé hardware Bloqué par le manque d’accès hardware.

Au-delà de la sécurité des sessions : l’audit de code par IA

Parallèlement à cette avancée sur la résilience des sessions, Vercel étend son offre de sécurité avec le Security Review, une fonction intégrée à Vercel Agent. Ce scanner IA examine le code source des utilisateurs à la recherche de failles avant qu’elles n’atteignent le public.

Ce système n’est pas un audit de sécurité traditionnel ni un test d’intrusion en temps réel ; il analyse le code. Lorsqu’un développeur pousse des modifications sur un dépôt GitHub connecté, le Security Review s’active. Il compare le code modifié avec la version précédente du déploiement pour ne scanner que les changements récents. Les coûts de calcul sont basés sur les événements de push plutôt que sur les requêtes de pull request.

Les résultats sont centralisés dans le tableau de bord des vulnérabilités. Pour les dépôts privés ou internes, Vercel ajoute ses conclusions en commentaire directement sur la pull request. Les rôles d’accès sont définis : l’Owner voit tout, le Contributor voit uniquement les projets qui lui sont assignés, et le Viewer n’a aucun accès.

Difficile de ne pas y voir une approche de sécurité par couches. DBSC sécurise la couche d’authentification en temps réel, tandis que le Security Review agit en amont, en s’attaquant aux faiblesses potentielles dans la logique métier. L’implémentation de DBSC, bien que fonctionnelle sur Chrome pour Mac et Windows, dépend encore de systèmes matériels spécifiques. Vercel et Chrome travaillent sur des solutions de contournement (polyfill), mais celles-ci sont présentées comme moins sécurisées, ce qui souligne que l’adoption de cette technologie repose encore sur la maturité de l’écosystème des navigateurs.

Sources