Snel antwoord: zet DBSC in waar je kunt. Het is goede, gratis bescherming tegen het hergebruik van gestolen cookies op Chrome. Maar DBSC doet één specifieke taak: het werkt alleen in Chrome, pas na het inloggen, is anti-diefstal in plaats van anti-fraude, en is met privacy als uitgangspunt ontworpen om je geen device-identiteit te geven. Device-fingerprinting beantwoordt een andere vraag, en DBSC is doelbewust gebouwd om die niet te beantwoorden. DBSC als vervanging van fingerprinting behandelen is een categoriefout.
Google's Device Bound Session Credentials (DBSC) werd algemeen beschikbaar in Chrome 146 op Windows op 2026-04-10. Zodra het uitkwam, kwam er bij elk fraude- en beveiligingsteam een terechte vraag op tafel: als Chrome sessies nu gratis aan het apparaat bindt, waarom dan nog voor fingerprinting betalen?
Het eerlijke antwoord begint met een toegeving. Voor zijn ene taak is DBSC echt sterk, sterker dan een fingerprint. De rest van dit artikel gaat over alles wat die taak niet omvat.
Wat DBSC is, nu het algemeen beschikbaar is
DBSC bindt een sessie aan een privésleutel die in de beveiligde hardware van het apparaat zit, een TPM op Windows of de Secure Enclave op macOS. De sleutel kan niet worden geëxporteerd. Ongeveer elke vijf minuten bewijst de browser dat hij die sleutel nog heeft, en pas dan vernieuwt de server een kortlevende cookie. Steel de cookie en verplaats die naar een andere machine, en hij sterft, omdat de dief het hardwaregebonden bewijs niet kan reproduceren.
Dat sluit precies het hergebruikvenster dat infostealer-malware en adversary-in-the-middle-phishingkits op grote schaal misbruiken. Voor een diepere blik op waarom de browsersessie een control plane werd, zie de browsersessie is nu een security control plane.
Waar DBSC echt beter is
Om een gestolen cookie op een ander apparaat onbruikbaar te maken, verslaat hardwarematige cryptografische binding een fingerprint, en dat mag duidelijk gezegd worden.
Een fingerprint is waarneembaar signaal. Een vastberaden aanvaller op een vergelijkbaar apparaat kan er genoeg van nabootsen om op het slachtoffer te lijken. In onze eigen tests maken op fingerprinting gebaseerde botverdedigingen geautomatiseerd hergebruik hard ongeldig, maar blijven ze zacht tegen een menselijke aanvaller die een gestolen cookie vanaf een vergelijkbaar apparaat hergebruikt. Een aan de TPM gebonden privésleutel heeft die zachte rand niet: hij kan niet worden geëxtraheerd, dus het hergebruik faalt simpelweg.
Daarom claimt cside niet beter te zijn in het stoppen van cookiediefstal. Voor dat stukje is het dat niet. Geef het punt toe en ga een niveau hoger, want op het niveau erboven leeft de meeste fraude.
DBSC versus device-fingerprinting in één oogopslag
| Aanval of behoefte | DBSC | Device-fingerprinting (cside) |
|---|---|---|
| Gestolen cookie hergebruikt buiten het apparaat | Sterk: de hardwaresleutel kan niet worden gereproduceerd | Gedeeltelijk: detecteert de apparaatwissel, kan worden nagebootst |
| Diefstal van inloggegevens en phishing | Geen: bindt ook het apparaat van de aanvaller | Markeert geldige inloggegevens op een gloednieuw apparaat |
| Credential stuffing | Geen: werkt na het inloggen | Detecteert geautomatiseerde en herhaald-apparaatpatronen |
| Fraude met nieuwe en synthetische accounts | Geen: er bestaat nog geen sessie | Werkt bij registratie |
| Botregistraties, scraping, carding | Geen | Kerngebruik, vóór authenticatie |
| Tussen accounts en multi-accounting | Geen: sleutels zijn per ontwerp niet correleerbaar | Koppelt apparaten tussen accounts |
| Device-reputatie en risicoscore | Geen | Ja |
| Browserdekking | Chrome op Windows vandaag | Elke browser, elke bezoeker |
| Implementatie | Herarchitectuur van de sessie aan serverzijde | Directe integratie op het first-party-scriptpad |
| Zichtbaarheid voor aanvallers | Openbaar, detecteerbaar protocol | Structureel onzichtbaar op het first-party-pad |
Waarom je device-fingerprinting nog steeds nodig hebt
DBSC bindt wie er ook inlogt, inclusief de aanvaller
Dit is het belangrijkste punt. DBSC verdedigt tegen cookiediefstal, waarbij malware een sessie pakt die al van het slachtoffer is. Het doet niets tegen diefstal van inloggegevens, phishing of credential stuffing. Als een aanvaller het wachtwoord heeft, geeft DBSC hem vrolijk een schone sessie die aan zijn apparaat is gebonden. De binding is echt. Ze is alleen aan de verkeerde persoon gebonden.
Fingerprinting is wat de echte route van accountovername detecteert: geldige inloggegevens die vanaf een gloednieuw apparaat binnenkomen. DBSC zegent precies het geval dat fingerprinting is gemaakt om te markeren. Voor de volledige aanvalsketen, zie oplossingen voor het voorkomen van accountovername vergelijken.
DBSC werkt alleen na het inloggen
Fraude gebeurt voordat er een sessie is om te binden. Fraude met nieuwe accounts, synthetische identiteiten, botregistraties, pogingen tot credential stuffing, scraping, carding en bonusmisbruik zijn allemaal gebeurtenissen vóór authenticatie of tussen accounts. Er is nog geen sessiecredential om cryptografisch te binden, dus DBSC heeft niets om op te handelen.
Fingerprinting werkt bij registratie, inloggen, afrekenen en wachtwoordherstel, de momenten waar misbruik vóór authenticatie wordt beslist.
DBSC is ontworpen om geen device-identiteitslaag te zijn
Dit is een kenmerk, geen tekortkoming, en het is belangrijk dat goed te begrijpen. DBSC-sleutels zijn per sessie, per origin en doelbewust niet correleerbaar, juist zodat het mechanisme geen tracking- of koppelingsvector kan worden. Dat is goed voor gebruikers.
Het is ook een harde muur voor fraudeteams. DBSC vertelt je "dezelfde browser als bij het begin van de sessie, ja of nee", en niets meer. Geen device-reputatie. Geen "dit apparaat zit achter 50 accounts". Geen koppeling tussen accounts. Geen risicoscore. Zelfs waar DBSC volledig is uitgerold, heb je nog steeds een aparte device-identificatielaag nodig, omdat DBSC weigert er een te zijn.
Dekking: Chrome op Windows vandaag
DBSC is algemeen beschikbaar in Chrome op Windows. Ondersteuning voor macOS via de Secure Enclave moet nog komen. Edge voerde een origin trial uit zonder algemene beschikbaarheid. Safari en Firefox brengen het niet uit. Op iOS Safari en op Firefox is dat nul bescherming.
cside-fingerprinting werkt in elke browser, voor elke bezoeker, zonder steekproef. Het ziet de echte aanvraag op het echte pad, ongeacht wat elke leverancier hierna uitbrengt.
De realiteit van de implementatie
DBSC is geen schakelaar. Elke site moet zijn sessielaag aan serverzijde opnieuw architecteren: sleutelregistratie, vernieuwingseindpunten, beheer van de levenscyclus en terugvalopties voor niet-ondersteunde browsers. Daarom is een kwartaal na de algemene beschikbaarheid de openbare lijst van afhankelijke partijen in wezen Google en Okta.
cside-fingerprinting is een directe integratie op het bestaande first-party-JavaScriptpad. De doorlooptijd is weken, geen beveiligingsprogramma van meerdere kwartalen.
Het architectonische verschil: first-party, zonder steekproef, onzichtbaar voor aanvallers
cside verzamelt via de first-party-proxy op het scriptleveringspad. Daaruit volgen twee dingen.
Het is zonder steekproef en universeel. Elke echte bezoeker, op de echte payload die aan echte gebruikers wordt geleverd, niet een steekproef van een SDK die een deel van het verkeer nooit laadt.
Het is structureel onzichtbaar voor aanvallers. Er is geen externe SDK-origin om op te zoeken en geen aparte aanvraag om te blokkeren. Toen we grote Amerikaanse banken en verzekeraars testten, draaide hun device-identificatie first-party en bleef ze onzichtbaar voor BuiltWith, Wappalyzer en standaard statische scans. Alleen een echte browserweergave bracht het aan het licht.
DBSC is per ontwerp het tegenovergestelde: een openbaar, goed gedocumenteerd, detecteerbaar protocol. Een aanvaller kan precies zien wanneer DBSC in het spel is en de gevallen omzeilen die het niet dekt, een Safari-sessie, een flow vóór het inloggen, of een vers via phishing verkregen sessie op zijn eigen apparaat.
Leverancierscontrole
"Gebruik gewoon de functie van Google" betekent dat je je roadmap voor sessievertrouwen uitbesteedt aan de ontwerpkeuzes van Chrome en aan browsers die je niet beheert. De dekking, het privacymodel en het uitrolschema worden elders bepaald. Een browseronafhankelijke laag die je zelf bezit, houdt die controle in huis.
De juiste manier om DBSC en fingerprinting samen te gebruiken
De geloofwaardige positie is complementair, niet of-of.
Zet DBSC in waar je kunt. Het is goede, gratis bescherming tegen cookiediefstal op Chrome, en het draagt een groter signaal: de hele sector beweegt naar apparaatgebonden vertrouwen. Dat bevestigt de stelling en vergroot doorgaans het budget ervoor.
Dek vervolgens wat DBSC structureel niet kan: elke browser, van vóór het inloggen tot het afrekenen, fraude tussen accounts, misbruik door bots en AI-agents, VPN- en proxy-detectie en bewijs bij terugboekingen. Dat DBSC algemeen beschikbaar wordt, dicht dat gat niet. Het versterkt het argument om het te dichten.
Wat je deze week kunt doen
- Zet DBSC aan waar je stack en de browsers van je gebruikers het ondersteunen. Behandel het als gratis bescherming tegen cookiediefstal voor Chrome op Windows, niet als je strategie voor sessievertrouwen.
- Voeg een browseronafhankelijke device-laag toe die vóór het inloggen en tussen accounts draait, zodat registratiefraude, credential stuffing en overname vanaf een nieuw apparaat in elke browser zichtbaar zijn.
- Koppel een apparaatmismatch aan een actie. Een fingerprint die niet overeenkomt met de basislijn die bij het inloggen is vastgesteld, zou versterkte authenticatie moeten activeren of de sessie moeten beëindigen, niet alleen een regel loggen.
- Controleer je dekking buiten Chrome. Als gebruikers van iOS Safari en Firefox geen apparaatbewuste sessievalidatie hebben, is dat waar het volgende hergebruik landt.
Hoe cside past
De device-fingerprinting van cside verzamelt meer dan 100 browser-, apparaat- en netwerksignalen op het first-party-pad om een persistente identificator van elke bezoeker op te bouwen, in elke browser. Het werkt voordat er een sessie is om te binden, koppelt apparaten tussen accounts, scoort risico en voert een mismatch in je bestaande regelengine of identiteitsprovider.
DBSC vertelt je of de cookie van hetzelfde apparaat terugkwam. cside vertelt je wie het apparaat is, wat het op je accounts heeft gedaan en of je het kunt vertrouwen, van de eerste aanvraag tot het afrekenen.
Per 2026-06-09. De beschikbaarheid van DBSC en de browserondersteuning veranderen snel; controleer de huidige uitrolstatus bij de bronnen van Google en de browserleveranciers voordat je op de dekking vertrouwt.
Vraag een demo aan om te zien hoe cside de fraude dekt die DBSC nooit is gemaakt om te stoppen.
