Vercel DBSC : lier la session à l'appareil contre le vol de cookies

En bref. Vercel déploie progressivement les Device Bound Session Credentials (DBSC) sur les connexions à vercel.com : la session est liée à une clé privée stockée dans la puce de sécurité de l'appareil, si bien qu'un cookie de session volé ne peut pas être réutilisé depuis une autre machine. La protection fonctionne aujourd'hui dans Chrome sur macOS et Windows. Pour une startup, la question utile n'est pas « Vercel est-il protégé ? » mais « lesquelles de mes consoles critiques acceptent encore un cookie rejoué depuis n'importe où ? ».

Ce qui s'est passé

Début novembre 2026, BleepingComputer a rapporté que Vercel déploie progressivement DBSC sur sa plateforme, présenté comme une défense contre les logiciels voleurs d'informations (infostealers). L'annonce a été faite par Malte Ubl, CTO de Vercel, sur X.

Le périmètre exact, selon la source :

• Ce qui est protégé : les connexions à vercel.com, c'est-à-dire la console où les développeurs gèrent leurs projets et leurs déploiements. Il ne s'agit pas d'une fonctionnalité offerte aux applications que vous hébergez chez Vercel.
• Navigateurs couverts : Chrome sur macOS et Windows, à ce stade.
• Déploiement progressif : Vercel avance par étapes pour traiter les cas limites liés aux applications OAuth.
• Ligne de commande : Vercel déploie en parallèle une technologie voisine, DPoP, pour la Vercel CLI.

La même semaine, Vercel a ouvert en bêta publique Security Review, une fonction de Vercel Agent qui analyse les changements de code à chaque push sur les dépôts GitHub connectés (équipes Pro et Enterprise), gratuite jusqu'au 10 novembre 2026 pour les analyses, les correctifs générés étant facturés à part.

Le contexte compte : en avril 2026, Vercel a subi une compromission touchant une partie de ses clients. D'après la source, l'attaquant est entré via le compte Google Workspace compromis d'un employé de Context.ai, a atteint des systèmes internes et consulté des variables d'environnement qui n'étaient pas marquées comme sensibles.

Le problème que DBSC traite : le cookie de session volé

Un cookie de session, c'est la preuve que vous vous êtes déjà authentifié. Une fois émis, il remplace votre mot de passe et votre second facteur (MFA, authentification multifacteur) pour toute la durée de la session. Celui qui le détient est, pour le serveur, vous.

Les infostealers exploitent exactement ce point. Ce sont des logiciels malveillants installés sur un poste (souvent via un faux logiciel, une extension piégée ou un téléchargement compromis) qui récupèrent les cookies du navigateur et les renvoient à l'attaquant. Celui-ci les recharge dans son propre navigateur et se retrouve connecté, sans avoir eu à franchir la MFA.

Pour une équipe qui déploie sur Vercel, la console donne accès aux projets, aux déploiements et aux variables d'environnement. Un cookie volé sur le portable d'un développeur peut donc mener aux secrets de production.

Comment DBSC fonctionne, dans le principe

Selon l'explication de Malte Ubl rapportée par BleepingComputer, DBSC stocke une clé privée dans le TPM (Trusted Platform Module, la puce de sécurité de l'appareil, la même famille de composant que celle utilisée par le capteur d'empreinte) et utilise cette clé pour signer le cookie. La clé ne peut jamais être extraite : ni par Vercel, ni par l'utilisateur, ni par un malware.

La conséquence : le cookie seul ne suffit plus. Le serveur attend une preuve que la requête vient de l'appareil qui détient la clé. Un attaquant qui copie le cookie sur sa machine n'a pas la clé, et la session ne peut pas être rejouée ailleurs.

Deux protections de Chrome se complètent ici :

• App-Bound Encryption rend plus difficile l'extraction des cookies par un infostealer sur le poste ;
• DBSC empêche la réutilisation d'un cookie qui aurait malgré tout été extrait.

DPoP (Demonstrating Proof of Possession, standardisé à l'IETF dans la RFC 9449) applique la même idée aux jetons OAuth : le jeton d'accès est lié à une clé détenue par le client, et chaque requête doit prouver la possession de cette clé. C'est pertinent pour une CLI, qui n'a pas de navigateur.

Ce que DBSC ne fait pas

C'est l'analyse qui manque dans la couverture de l'annonce, et c'est elle qui doit guider vos décisions.

• DBSC ne protège pas un poste déjà compromis. Si le malware tourne sur l'appareil légitime, il peut agir depuis cet appareil, avec la session valide. DBSC supprime le rejeu à distance, pas l'abus local. C'est une hypothèse de modèle de menace, pas une faiblesse annoncée par Vercel, mais elle découle directement du principe.
• DBSC ne protège que les navigateurs couverts. Un développeur sur Linux, sur Firefox ou sur Safari ne bénéficie pas, selon la source, de cette protection à ce stade.
• DBSC ne couvre pas les autres jetons. Les tokens d'API Vercel, les jetons de CI, les secrets copiés dans un .env local restent des secrets « au porteur » s'ils ne sont pas eux-mêmes liés à une clé.
• DBSC ne règle pas le scénario d'avril. La compromission décrite passait par un compte Workspace chez un tiers et par des variables d'environnement non marquées sensibles. La liaison de session à l'appareil ne traite ni l'un ni l'autre.

Qui est concerné

• Les équipes qui déploient sur Vercel : vos développeurs bénéficient de DBSC dès que le déploiement progressif les atteint, s'ils utilisent Chrome sur macOS ou Windows. Rien ne vous garantit qu'ils y sont déjà.
• Toutes les équipes techniques, en réalité : le vol de cookies vise n'importe quelle console SaaS. Votre fournisseur cloud, votre gestionnaire de code, votre outil de support, votre console d'IA générative et votre outil de paie acceptent probablement tous un cookie rejoué.
• Les éditeurs SaaS : vos propres clients vont commencer à poser la question de la liaison de session à l'appareil dans leurs questionnaires sécurité.

Comment s'en protéger

1. Cartographier les sessions qui ouvrent la production

Listez les consoles dont un cookie volé donne accès à de la production ou à des secrets : hébergement (Vercel, cloud), dépôt de code, CI/CD, gestionnaire de secrets, registre de paquets, fournisseur d'identité. Pour chacune, notez : durée de session, liaison à l'appareil ou non, possibilité de révoquer toutes les sessions d'un utilisateur.

2. Questions à poser à vos fournisseurs

• Les sessions de votre console sont-elles liées à l'appareil (DBSC ou équivalent) ? Sur quels navigateurs et systèmes ?
• Vos jetons d'API et de CLI sont-ils liés à une clé (DPoP ou mTLS) ou sont-ils des jetons au porteur ?
• Quelle est la durée de vie maximale d'une session et d'un jeton ? Est-elle configurable par l'administrateur ?
• Peut-on révoquer en un geste toutes les sessions et tous les jetons d'un utilisateur ?
• Journalisez-vous l'adresse IP, l'appareil et le changement d'appareil pour une même session, et ces journaux sont-ils exportables ?
• Les secrets stockés (variables d'environnement) sont-ils masqués par défaut, ou faut-il les marquer sensibles un par un ?

La dernière question renvoie directement à l'incident d'avril.

3. Durcir les postes des développeurs

DBSC suppose un appareil sain. Les contrôles de base restent la première ligne : EDR (détection et réponse sur le poste) sur les machines qui accèdent à la production, interdiction des logiciels non approuvés et des extensions de navigateur non validées, navigateur géré par l'entreprise, chiffrement du disque.

4. Réduire ce qu'un cookie volé peut atteindre

• Marquez comme sensibles toutes les variables d'environnement contenant des secrets dans Vercel, pour qu'elles ne soient pas relisibles depuis la console.
• Réduisez le nombre de personnes ayant un rôle administrateur.
• Raccourcissez les durées de session des consoles critiques.
• Préférez des jetons de déploiement à portée limitée et durée courte aux jetons personnels longue durée.

5. Vérifier chez vous

• Navigateur et système : inventoriez quels développeurs accèdent à vercel.com depuis Chrome sur macOS ou Windows. Les autres sont hors du périmètre DBSC actuel.
• Variables d'environnement : passez en revue chaque projet Vercel et comptez les variables contenant un secret qui ne sont pas marquées sensibles. L'objectif est zéro.
• Jetons : listez les jetons d'API Vercel actifs, leur propriétaire, leur portée et leur date d'expiration. Révoquez ceux qui n'ont pas de propriétaire identifiable.
• Exercice de révocation : chronométrez le temps nécessaire pour révoquer toutes les sessions et tous les jetons d'un développeur sur l'ensemble de vos consoles critiques. Si la réponse dépasse une heure, c'est votre vrai risque infostealer.

FAQ

Qu'est-ce que DBSC (Device Bound Session Credentials) ? Un mécanisme qui lie une session web à une clé privée conservée dans la puce de sécurité de l'appareil. Le cookie de session ne suffit plus à lui seul : il faut aussi la preuve que la requête vient de l'appareil qui détient la clé. Un cookie copié sur une autre machine devient inutilisable.

DBSC protège-t-il contre les infostealers ? En partie. Il empêche le rejeu d'un cookie volé depuis la machine de l'attaquant. Il ne protège pas contre un malware qui agit directement depuis l'appareil infecté, ni les jetons d'API ou les secrets stockés en clair sur le poste.

Quelle différence entre DBSC et DPoP ? Même principe de preuve de possession d'une clé, deux contextes. DBSC concerne les cookies de session dans le navigateur ; DPoP (RFC 9449) concerne les jetons OAuth, ce qui le rend adapté aux outils en ligne de commande et aux API. Vercel déploie le premier pour vercel.com et le second pour sa CLI.

Faut-il faire quelque chose pour activer DBSC sur Vercel ? D'après la source, le déploiement est progressif et côté Vercel, sans action décrite pour l'utilisateur. Il ne fonctionne qu'avec Chrome sur macOS et Windows. Vérifiez donc surtout quels postes de votre équipe sont hors de ce périmètre.

Sources

• BleepingComputer, Vercel rolls out new protection against stolen session cookie attacks, novembre 2026 : https://www.bleepingcomputer.com/news/security/vercel-rolls-out-new-protection-against-stolen-session-cookie-attacks
• IETF, RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP) : https://www.rfc-editor.org/rfc/rfc9449
• Chrome for Developers, documentation Device Bound Session Credentials : https://developer.chrome.com/docs/web-platform/device-bound-session-credentials

---

Si vous voulez savoir lesquelles de vos consoles et de vos pipelines s'ouvrent avec un simple cookie ou un jeton au porteur, c'est l'un des points que nous passons en revue dans nos missions DevSecOps.