Perché l'header Set-Cookie è stato impostato con successo ma il browser non ha salvato il mio Cookie?
Questo è il problema più comune: il browser non restituisce errori attivamente, ma scarta silenziosamente i Cookie non conformi. Le cause comuni sono: SameSite=None senza Secure, Cookie Secure impostato su una pagina HTTP (eccetto localhost), i prefissi __Host-/__Secure- non soddisfano le restrizioni, mancata corrispondenza di Domain/Path, superamento del limite di 4KB, Max-Age è 0 o negativo. Si consiglia di incollare prima il Set-Cookie in questo strumento per individuare il motivo specifico tramite i badge di avviso, poi apri Chrome DevTools → Application → Cookies, verifica sotto il dominio corrispondente se c'è un triangolo giallo di avviso — passandoci sopra il mouse vedrai il motivo specifico del rifiuto.
Qual è la differenza tra Strict, Lax e None di SameSite? Quando usare ognuno?
Strict non consente in alcun modo l'invio cross-site, è il più sicuro ma l'utente apparirà disconnesso quando clicca su link da altri siti, adatto per Cookie di operazioni sensibili come pagamenti/modifica password. Lax è il valore predefinito di Chrome 80+, consente l'invio nella navigazione GET di primo livello (cliccare su link da un altro sito tornando al tuo sito) ma non in sottorisorse come iframe/img/script/XHR/moduli POST, essendo il valore consigliato per la maggior parte degli scenari. None consente l'invio in tutti gli scenari cross-site (usato per il login SSO, incorporamenti di terze parti in iframe, chiamate API cross-site) ma richiede che Secure sia impostato contemporaneamente, altrimenti il browser lo rifiuta immediatamente.
Perché SameSite=None deve essere accompagnato da Secure?
Questa è una regola imposta da Chrome a partire dalla versione 80 (febbraio 2020), seguita da Firefox, Edge e Safari. Poiché SameSite=None consente esplicitamente l'invio cross-site di Cookie, gli aggressori hanno più facilità a lanciare CSRF o intercettazioni in scenari cross-site, ed è necessario accompagnare Secure (trasmissione crittografata HTTPS) per ridurre i rischi. Se il tuo Cookie SameSite=None viene impostato su HTTP, il browser lo scarterà senza salvarlo. Questo strumento rileva la combinazione SameSite=None senza Secure e la contrassegna con un avviso in rosso.
Quale usare: Max-Age o Expires? Qual è la differenza?
Privilegia Max-Age. Max-Age è tempo relativo (scade dopo quanti secondi), non dipende dall'orologio del client, il browser avvia il conto alla rovescia alla ricezione; Expires è un punto nel tempo assoluto, dipende dall'orario locale del computer dell'utente (se l'utente cambia l'orologio al 1970 il Cookie scade immediatamente). Quando entrambi esistono, Max-Age ha priorità maggiore (specificato esplicitamente da RFC 6265). Se nessuno è impostato, il Cookie diventa un «Cookie di Sessione» che scade alla chiusura del browser. Questo strumento dà un suggerimento quando Expires è impostato ma Max-Age no, consigliando di aggiungere Max-Age. Nota che l'unità di Max-Age è secondi, non millisecondi.
Qual è la differenza tra Path=/ e non impostare Path?
Path determina in quali percorsi URL il browser invierà il Cookie quando effettua richieste. Quando Path non è impostato, il browser usa per impostazione predefinita «il percorso dell'URL di risposta rimuovendo l'ultimo segmento». Ad esempio, quando imposti un Cookie da /api/user/login, il Path predefinito è /api/user/, quindi le richieste nel percorso / e /order/ non invieranno questo Cookie. Impostare Path=/ esplicitamente fa sì che il Cookie valga per tutto il sito. Nota che la corrispondenza di Path è una corrispondenza di prefisso — Path=/api corrisponderà anche a /api/, /api/user, /api/v2/abc, ecc. I Cookie con prefisso __Host- richiedono obbligatoriamente Path=/.
Qual è la differenza tra Domain con il punto all'inizio (come .example.com) e senza punto?
Nei browser moderni (versioni recenti di Chrome, Firefox, Edge, Safari) i due sono ormai equivalenti: entrambi fanno sì che il Cookie valga per example.com e tutti i suoi sottodomini (a.example.com, b.c.example.com). Il punto all'inizio era una sintassi vecchia dell'epoca di RFC 2109 — RFC 6265 ha già specificato che il punto iniziale viene ignorato. Tuttavia, per leggibilità si consiglia di scrivere senza punto. Questo strumento dà un suggerimento quando Domain ha il punto iniziale (non è un errore, ma è una sintassi legacy). Nota: quando Domain non è impostato il Cookie vale solo per l'host corrente (i sottodomini non lo inviano), impostando Domain passa a valere per i sottodomini.
Cosa sono i prefissi __Host- e __Secure-? Posso non usare i prefissi?
Sono prefissi di sicurezza del nome dei Cookie introdotti da RFC 6265bis per applicare restrizioni rigorose ai Cookie ad alta sicurezza: quando il browser vede che il nome del Cookie inizia con __Host-, richiede obbligatoriamente Secure, Path=/ e nessun Domain impostato — se una qualsiasi condizione non è soddisfatta, rifiuta immediatamente l'archiviazione; il prefisso __Secure- richiede che sia impostato Secure, potendo avere altri attributi. Non usare prefissi funziona comunque (la maggior parte dei Cookie non usa prefissi), ma per i Cookie ad alta sicurezza come gli identificatori di sessione, i Token di autorizzazione si consiglia vivamente di usare il prefisso __Host-, poiché previene gli attacchi di iniezione di Cookie a livello di sottodominio/percorso. Questo strumento rileva automaticamente la conformità di entrambi i prefissi.
Il Cookie HttpOnly è veramente sicuro? Previene XSS e CSRF?
HttpOnly impedisce a JavaScript di leggere i valori dei Cookie tramite document.cookie, essendo un'importante linea di difesa per <strong>mitigare il furto di sessione tramite XSS</strong>, ma non è una soluzione miracolosa: gli aggressori XSS sono comunque in grado di effettuare richieste nel browser dell'utente (le richieste portano automaticamente il Cookie) per eseguire azioni (questo è l'ambito di CSRF); HttpOnly inoltre non difende dagli attacchi CSRF (richiede SameSite o CSRF Token). Il trio HttpOnly+Secure+SameSite=Lax/Strict usato contemporaneamente è quello che raggiunge un livello base di sicurezza. I Cookie sensibili (session, JWT, access_token) devono essere HttpOnly, non dare accesso al JS del front-end senza necessità. Questo strumento contrassegna con un avviso i Cookie senza HttpOnly.
Cos'è il Cookie Partitioned (CHIPS)? Quando devo usarlo?
Partitioned è un nuovo attributo lanciato da Chrome in risposta all'eliminazione dei Cookie di terze parti, con nome completo Cookies Having Independent Partitioned State (CHIPS). I Cookie di terze parti tradizionali (come quelli di pubblicità/servizi incorporati impostati su più siti) sono condivisi globalmente e possono essere usati per tracciare gli utenti cross-site. Con Partitioned, il browser archivia il Cookie di terza parte separatamente per sito di primo livello: il Cookie di terza parte che l'utente vede nel Sito A è completamente indipendente da quello visto nel Sito B, non potendo condividere l'identità cross-site. Scenari d'uso: componenti incorporati di video/mappe/pagamento, plugin di assistenza di terze parti, SSO cross-site incorporato in iframe. L'uso di Partitioned richiede che Secure sia impostato contemporaneamente, consigliato con il prefisso __Host-.
Quanto può memorizzare al massimo un Cookie? Quanti Cookie possono stare per dominio?
Secondo RFC 6265, i browser supportano almeno 4096 byte per Cookie (inclusi nome, valore e attributi), e i browser principali (Chrome/Firefox/Safari/Edge) seguono questo limite — il contenuto eccedente viene troncato o scartato silenziosamente. I limiti di quantità variano per browser: Chrome ha circa 180 per dominio, Firefox circa 150, Safari circa 600 (ed è influenzato dalla politica di pulizia di 7 giorni dell'ITP); al superamento, il browser elimina i Cookie più vecchi con politica LRU. Si consiglia che i Cookie memorizzino solo identificatori di sessione, non mettere grandi blocchi di dati aziendali nei Cookie (i dati aziendali mettili in localStorage o nella Sessione sul server).
Lo strumento supporta la copia di Set-Cookie direttamente da Chrome DevTools per analizzarlo? Devo rimuovere il prefisso manualmente?
Supporta completamente, senza necessità di elaborazione manuale. Puoi cliccare sulla richiesta target nel pannello Network di Chrome DevTools, cliccare con il tasto destro sul valore di Set-Cookie nell'area Response Headers per copiare direttamente (per più righe, Ctrl/⌘+clic per selezione multipla o copia l'intero blocco) e incollare nell'area di input di questo strumento. Lo strumento rimuove automaticamente il prefisso Set-Cookie: dall'inizio di ogni riga (case-insensitive), elabora automaticamente gli spazi bianchi all'inizio/fine delle righe, gestisce correttamente i caratteri speciali come virgole e punto e virgola nelle date Expires, e gestisce anche correttamente i valori dei Cookie con virgolette doppie.
Perché i caratteri cinesi o speciali nei valori dei Cookie diventano nella forma %XX?
RFC 6265 richiede che i valori dei Cookie usino solo un sottoinsieme sicuro del set di caratteri ASCII, non potendo contenere direttamente caratteri non ASCII, spazi, virgole, punto e virgola, ecc. Molti framework server durante l'impostazione dei Cookie effettuano automaticamente la codifica URL (encodeURIComponent/Percent-encoding) sui caratteri non ASCII. I browser mantengono anche la forma codificata durante la restituzione. Quando questo strumento rileva che il valore contiene codifica %XX, mostra automaticamente il testo originale decodificato da decodeURIComponent accanto al valore grezzo con una freccia verde, per facilitare la visualizzazione del contenuto reale.
Qual è la differenza tra Set-Cookie e l'header di richiesta Cookie?
Sono header di direzioni completamente diverse: Set-Cookie è un header di risposta (server→browser), appare solo nelle risposte, può apparire più volte, ogni volta imposta un Cookie con attributi completi (Secure/HttpOnly/Path/Domain, ecc.); Cookie è un header di richiesta (browser→server), appare solo una volta per richiesta, contenente tutte le coppie name=value dei Cookie che corrispondono all'ambito corrente in forma piatta (name1=v1; name2=v2), senza nessuna informazione sugli attributi. Ciò significa che il server non è in grado di sapere nella richiesta se un Cookie ha HttpOnly o Secure impostato — le informazioni sugli attributi vengono mantenute solo dal browser nell'archiviazione locale. Per analizzare l'header Cookie delle richieste usa il <a href='/network/http-cookie-parser/'>Parser dell'header di richiesta Cookie</a> complementare.
Perché i miei Cookie scompaiono dopo alcuni giorni su Safari?
Questo è il meccanismo di Prevenzione del Tracciamento Intelligente (ITP: Intelligent Tracking Prevention) di Safari in azione. A partire da ITP 2.1, se l'utente non interagisce direttamente con il dominio per 7 giorni (cioè non ha visitato direttamente il sito del dominio), Safari cancella tutti i Cookie e i dati dei siti sotto quel dominio, indipendentemente da quanto tempo siano impostati Max-Age/Expires. Questo influisce maggiormente sui servizi incorporati di terze parti, mentre i Cookie del sito principale non sono influenzati fintanto che l'utente continua ad accedervi. Inoltre, le restrizioni di Safari sui Cookie di terze parti sono più rigorose di quelle di Chrome. Le soluzioni includono: usare l'attributo Partitioned, richiedere l'autorizzazione tramite Storage Access API o rinnovare il Cookie quando l'utente accede al sito principale. La sezione di risoluzione dei problemi di questo strumento ha indicazioni più dettagliate per il debug su Safari.
Lo strumento supporta l'analisi in batch di più Set-Cookie? Il contenuto del Cookie viene inviato ai server?
Supporta l'analisi in batch. L'area di input supporta l'incollaggio di qualsiasi numero di righe di Set-Cookie (come incollare un intero blocco di header di risposta in una volta), ogni Set-Cookie viene analizzato con numerazione indipendente, con più schede di attributi che mostrano separatamente attributi e avvisi. Tutto il processo di analisi viene effettuato completamente localmente nel tuo browser (elaborazione JavaScript pura sul front-end), il contenuto del Cookie non viene inviato a nessun server, né vengono effettuate richieste di rete — le informazioni sensibili come Session/Token che incolli non escono dal tuo computer, puoi usarlo con tranquillità.
