TL;DR: passkey e MFA proteggono il login, ma una sessione già aperta resta esposta se un infostealer ruba il cookie. Device Bound Session Credentials (DBSC) cambia il modello: Chrome lega la sessione a una chiave privata custodita sul dispositivo e il server rinnova cookie brevi solo dopo una prova crittografica. Per una PMI con WordPress non è un interruttore da attivare oggi nel browser o in un plugin. È una tecnologia da seguire, mentre si applicano subito sessioni più corte, revoca rapida, account separati, minimo privilegio e controllo degli endpoint.

La parte più fragile dell’accesso a un sito non è sempre la password. Spesso viene dopo. Un amministratore supera il login con passkey o autenticazione a più fattori, WordPress gli assegna un cookie e da quel momento il browser usa quel cookie per dimostrare che la sessione è valida.

Se un malware copia il cookie, l’attaccante può provare a riutilizzarlo su un altro computer. Non deve conoscere la password e non deve ripetere l’MFA. È il motivo per cui il furto di sessione è diventato un obiettivo pratico degli infostealer.

DBSC affronta precisamente questo passaggio. Non rende sicuro un computer compromesso e non sostituisce le protezioni del login. Riduce però il valore di un cookie esportato: senza la chiave privata del dispositivo originale, il rinnovo della sessione fallisce.

Il problema arriva dopo il login

Un cookie di sessione tradizionale è un bearer token: chi lo possiede può presentarlo al server. Il server controlla firma, scadenza e stato della sessione, ma non sa se il cookie arriva dal browser che ha eseguito il login oppure da un altro dispositivo.

Questo spiega perché una passkey resistente al phishing non chiude da sola il problema. La passkey rende molto più difficile rubare la credenziale di accesso. Dopo l’autenticazione, però, l’applicazione continua spesso a usare cookie ordinari per evitare una nuova firma crittografica a ogni pagina.

Per WordPress il punto è concreto. La documentazione ufficiale descrive wordpress_[hash] come cookie usato nell’area amministrativa e wordpress_logged_in_[hash] come indicatore della sessione per il resto dell’interfaccia. Se WordPress riconosce un cookie valido e non scaduto, non chiede di nuovo la password.

I nonce aggiungono una difesa contro richieste CSRF, ma non trasformano il cookie in una credenziale legata al dispositivo. La documentazione WordPress precisa che i nonce non sono un sistema di autenticazione o autorizzazione e non proteggono dai replay. Un plugin deve comunque verificare le capability con current_user_can().

Come funziona DBSC

DBSC aggiunge una prova di possesso alla sessione senza obbligare il frontend a sostituire tutti i cookie. Il flusso base ha cinque passaggi:

  1. dopo il login, il server invia l’header Secure-Session-Registration;
  2. Chrome genera una coppia di chiavi per quella sessione e protegge la chiave privata con i meccanismi disponibili sul dispositivo;
  3. il browser chiama un endpoint di registrazione e il server associa la chiave pubblica alla sessione;
  4. l’applicazione usa un cookie di durata breve per le richieste autenticate;
  5. quando il cookie deve essere rinnovato, un endpoint di refresh chiede al browser una prova firmata. Solo una prova valida produce un nuovo cookie.

Il cookie rubato mantiene quindi valore per una finestra più piccola. Quando scade, l’attaccante che lo ha spostato su un’altra macchina non dispone della chiave privata e non può completare la challenge. Chrome può anche rinviare per un attimo una richiesta mentre rinnova il cookie, così l’applicazione continua a ragionare con il normale controllo della sessione.

La specifica W3C richiede chiavi distinte per sessione e prevede che chiavi e sessioni vengano eliminate insieme ai dati del sito. Non dovrebbe emergere un identificatore stabile del dispositivo. È una distinzione importante: il server verifica la continuità crittografica della sessione, non riceve una targa permanente del computer.

Cosa protegge e cosa lascia scoperto

DBSC è efficace contro l’esportazione del cookie verso un altro dispositivo. Costringe l’attaccante a restare sulla macchina compromessa oppure a trovare un attacco più invasivo. Questo alza il costo e rende l’abuso più visibile, ma non elimina la compromissione locale.

La bozza W3C elenca due limiti netti. Se il malware è ancora attivo sul dispositivo, può tentare di usare la capacità di firma disponibile al browser. Se l’attaccante controlla o sostituisce lo user agent durante la registrazione, può cercare di legare la nuova sessione a una chiave sotto il proprio controllo. DBSC non certifica inoltre che il dispositivo sia aggiornato, gestito o privo di malware.

La mia lettura è semplice: il binding della sessione è una barriera contro l’esfiltrazione, non un attestato di salute dell’endpoint. Servono ancora aggiornamenti, protezione del sistema operativo, separazione degli account, logging e una procedura di risposta agli incidenti.

Anche passkey e MFA restano necessarie. Proteggono la fase di autenticazione iniziale, mentre DBSC protegge la continuità della sessione. Sono due livelli diversi della stessa catena.

Lo stato reale nel 2026

Google ha portato DBSC in disponibilità pubblica su Chrome per Windows nel 2026 e ha annunciato l’espansione a macOS. La distribuzione resta comunque dipendente dal browser, dal sistema operativo, dal servizio visitato e dal rollout scelto dal fornitore. Avere una versione recente di Chrome non significa che tutte le sessioni siano già protette.

Il modo più affidabile per controllare un sito è DevTools. In Chrome si apre Application, poi Background services e Device bound sessions. Quando il sito ha registrato una sessione DBSC, il pannello mostra definizione, eventi di creazione, refresh, challenge, errori e terminazione.

Questa verifica evita due equivoci. Il primo è pensare che basti abilitare una flag locale. Il secondo è confondere il supporto del browser con l’adozione server. Senza header di registrazione, endpoint di registrazione e endpoint di refresh, non esiste alcun binding della sessione.

Cosa fare oggi su WordPress

WordPress core gestisce cookie di autenticazione e token di sessione. La documentazione corrente espone WP_Session_Tokens, consente di cambiare la durata del cookie tramite il filtro auth_cookie_expiration e permette di revocare tutte le sessioni di un utente. Non documenta un’integrazione DBSC pronta per wp-admin.

Per una normale PMI non scriverei oggi un plugin DBSC da installare alla cieca. Il refresh è sul percorso critico: se l’endpoint risponde male, può creare loop di login o richieste senza cookie bound. La specifica raccomanda inoltre challenge brevi, CORS stretto e protezioni contro embedding e leak dello stato di login. È lavoro da stack di autenticazione, non uno snippet.

Applicherei invece questo ordine:

  1. Passkey o MFA per gli amministratori. Riduce phishing e riuso delle password nella fase di login.
  2. Account personali, mai condivisi. Ogni amministratore deve avere una sessione e una traccia attribuibile.
  3. Minimo privilegio. Chi scrive non deve installare plugin; chi gestisce fatture non deve essere amministratore del sito.
  4. Sessioni più corte sugli account critici. La durata va scelta insieme al rischio e al carico operativo, senza imporre lo stesso valore a editor e amministratori.
  5. HTTPS su login e amministrazione. I cookie di autenticazione devono viaggiare solo su connessioni sicure, con configurazione proxy corretta se WordPress è dietro CDN o reverse proxy.
  6. Revoca pronta. In caso di sospetto, wp_destroy_all_sessions() rimuove dal database tutti i token di sessione dell’utente corrente. Per una procedura amministrativa si usa il gestore WP_Session_Tokens sull’utente interessato, con capability e audit adeguati.
  7. Credenziali delle automazioni separate. Le Application Password della REST API non vanno confuse con i cookie del browser. Devono avere proprietario, scopo, rotazione e revoca propri.

Infine, monitora ciò che conta: nuovi amministratori, cambio e-mail degli account, installazione di plugin, creazione di Application Password, login insoliti e modifiche ai file. È lo stesso principio discusso per la sicurezza basata su accesso e monitoraggio continuo: prevenzione e rilevazione devono lavorare insieme.

Quando ha senso progettare un’integrazione

DBSC merita un pilot se WordPress è solo una parte di un portale con utenti ad alto valore, se l’autenticazione passa da un identity provider controllato oppure se un’app headless usa WordPress come backend. In questi casi il binding può vivere nel gateway di autenticazione, invece di modificare ogni plugin che legge la sessione.

Il pilot dovrebbe partire da un percorso ristretto, per esempio le azioni amministrative più sensibili. Il server mantiene un fallback per browser o hardware non compatibili, ma non deve trasformarlo in una scorciatoia che accetta sempre il cookie lungo. Vanno misurati almeno:

  • percentuale di sessioni registrate con chiave protetta;
  • errori e latenza del refresh;
  • richieste rinviate o terminate;
  • loop di login e problemi dopo sospensione o riavvio del dispositivo;
  • tempo necessario per revocare una sessione compromessa.

Prima del rollout serve anche un test di fallback. La guida Chrome segnala che errori di rete, endpoint di refresh non raggiungibile o limiti delle operazioni crittografiche possono portare il browser a saltare il flusso DBSC. L’applicazione deve decidere quali azioni restano permesse senza cookie bound e quali richiedono una nuova autenticazione.

Playbook per un sospetto furto di sessione

La tecnologia futura non sostituisce una procedura pronta oggi. Se un amministratore vede attività che non riconosce:

  1. isola il dispositivo sospetto dalla rete e preserva i log;
  2. revoca tutte le sessioni WordPress dell’utente da un dispositivo pulito;
  3. revoca Application Password, token API e sessioni dell’identity provider collegate;
  4. cambia password e ricrea le credenziali soltanto dopo aver verificato l’endpoint;
  5. controlla utenti, ruoli, plugin, temi, file modificati, cron e opzioni sensibili;
  6. purgare la cache non basta: il problema è l’autenticazione, non una copia HTML obsoleta.

Se cambi la password ma lasci attivo il malware, la nuova sessione può essere rubata di nuovo. Se pulisci il computer ma non revochi i token, l’attaccante può continuare a usare ciò che ha già copiato. Le due azioni vanno eseguite insieme.

La mia take: il cookie lungo è debito di sicurezza

DBSC porta sul web un principio corretto: una credenziale sensibile non dovrebbe essere utile solo perché qualcuno è riuscito a copiarla. La prova di possesso riduce il valore del dato esportato e sposta l’attacco dal furto scalabile alla compromissione locale.

Per WordPress, però, l’errore sarebbe aspettare il supporto perfetto del browser. Un cookie amministrativo troppo lungo, un account condiviso o una revoca che nessuno sa eseguire sono debito operativo già oggi.

La priorità di una PMI dovrebbe essere questa: rendere breve la finestra utile di una sessione rubata, limitare ciò che quell’utente può fare e riuscire a revocare tutto in pochi minuti. Quando DBSC sarà disponibile nello stack adottato, aggiungerà una barriera forte. Non sostituirà il resto.

Fonti