Per què la capçalera Set-Cookie s'ha configurat correctament però el navegador no ha desat la meva cookie?
Aquest és el problema més comú; el navegador no reportarà errors activament, sinó que descarta silenciosament les cookies que no compleixen les normes. Les causes habituals són: SameSite=None sense Secure, cookie Secure configurada en una pàgina HTTP (excepte localhost), incompliment de les restriccions dels prefixos __Host-/__Secure-, desajustament de Domain/Path, superació del límit de mida de 4KB, Max-Age igual a 0 o negatiu. Es recomana enganxar primer el Set-Cookie en aquesta eina, consultar les insígnies d'advertència per localitzar la causa específica, i després obrir Chrome DevTools → Application → Cookies per veure si hi ha un triangle d'advertència groc sota el domini corresponent; en passar-hi el cursor per sobre es veurà el motiu específic de rebuig.
Quina diferència hi ha realment entre Strict, Lax i None de SameSite? Quan s'ha d'utilitzar cadascun?
Strict no permet cap enviament entre tercers, és el més segur però els usuaris que entren des d'enllaços externs apareixeran com no autenticats, adequat per a cookies d'operacions sensibles com pagaments/canvi de contrasenya. Lax és el valor per defecte des de Chrome 80, permet portar la cookie en navegació GET de nivell superior (quan l'usuari fa clic en un enllaç extern per tornar al teu lloc), però no en subrecursos com iframe/img/script/XHR/formularis POST; és el valor recomanat per a la majoria d'escenaris. None permet l'enviament en tots els escenaris entre tercers (per a SSO d'inici de sessió únic, incrustació de tercers en iframe, cridades API entre tercers), però s'ha d'establir Secure obligatòriament, altrament el navegador la rebutjarà directament.
Per què SameSite=None ha d'anar acompanyat de Secure?
Aquesta és una regla que Chrome aplica obligatòriament des de la versió 80 (febrer de 2020), i Firefox, Edge i Safari també l'han adoptada. Com que SameSite=None permet explícitament l'enviament de cookies entre tercers, els atacants tenen més facilitat per dur a terme atacs CSRF o intercepcions en escenaris entre tercers, i cal acompanyar-lo de Secure (transmissió xifrada HTTPS) per reduir els riscos. Si la teva cookie SameSite=None es configura sota HTTP, el navegador la descartarà directament sense emmagatzemar-la. Aquesta eina detecta la combinació de SameSite=None sense Secure i la marca amb una advertència vermella.
Quin he d'utilitzar, Max-Age o Expires? Quina diferència hi ha?
Utilitza Max-Age prioritàriament. Max-Age és un temps relatiu (expira després de tants segons), no depèn del rellotge del client, i el navegador comença el compte enrere en rebre-la; Expires és un punt de temps absolut, depèn de l'hora local de l'ordinador de l'usuari (si l'usuari canvia el rellotge al 1970 la cookie caduca immediatament). Quan tots dos estan presents, Max-Age té prioritat més alta (especificat explícitament per RFC 6265). Si no s'estableix cap, la cookie es converteix en una «cookie de sessió» que caduca en tancar el navegador. Aquesta eina ofereix un avís per als casos en què s'ha establert Expires però no Max-Age, recomanant afegir Max-Age. Tingues en compte que la unitat de Max-Age és segons, no mil·lisegons.
Quina diferència hi ha entre establir Path=/ i no establir Path?
Path determina en quins camins URL el navegador inclourà aquesta cookie en les peticions. Quan no s'estableix Path, el navegador utilitza per defecte «el camí de l'URL de resposta sense l'últim segment»; per exemple, en configurar una cookie des de /api/user/login, el Path per defecte és /api/user/, de manera que les peticions sota / i /order/ no portaran aquesta cookie. Establir Path=/ explícitament fa que la cookie sigui efectiva per a tot el lloc. Tingues en compte que la concordança de Path és per prefix; Path=/api també concordarà amb /api/, /api/user, /api/v2/abc, etc. Les cookies amb prefix __Host- requereixen obligatòriament Path=/.
Quina diferència hi ha entre Domain que comença amb punt (com .example.com) i sense punt?
En navegadors moderns (versions recents de Chrome, Firefox, Edge, Safari), els dos són ja equivalents, i tots dos faran que la cookie sigui efectiva per a example.com i tots els seus subdominis (a.example.com, b.c.example.com). El punt inicial era l'escriptura antiga de l'època de RFC 2109, i RFC 6265 ja especifica explícitament ignorar el punt inicial. Tanmateix, per llegibilitat es recomana escriure la forma sense punt. Aquesta eina ofereix un avís per als casos en què Domain té un punt inicial (no és un error, però és una escriptura heretada històricament). Nota: si no s'estableix Domain, la cookie només és efectiva per a l'host actual (els subdominis no la portaran); en establir Domain ho serà per als subdominis.
Què són els prefixos __Host- i __Secure-? Es pot treballar sense escriure prefixos?
Aquests són prefixos de seguretat per a noms de cookie introduïts per RFC 6265bis, per afegir restriccions fortes a les cookies d'alta seguretat: quan el navegador veu que un nom de cookie comença per __Host-, obliga a establir simultàniament Secure, Path=/ i no establir Domain; si no es compleix qualsevol condició, rebutja directament emmagatzemar-la; el prefix __Secure- requereix establir Secure obligatòriament, i els altres atributs es poden configurar. Sense escriure prefixos també funciona (la majoria de cookies no utilitzen prefixos), però per a cookies d'alta seguretat com identificadors de sessió i tokens d'autorització es recomana fermament utilitzar el prefix __Host-, ja que pot prevenir atacs d'injecció de cookies a nivell de subdomini/camí. Aquesta eina detecta automàticament el compliment dels dos tipus de prefixos.
Les cookies HttpOnly són realment segures? Protegeixen contra XSS i CSRF?
HttpOnly impedeix que JavaScript llegeixi el valor de la cookie mitjançant document.cookie, i és una línia de defensa important per <strong>mitigar el robatori de sessió per XSS</strong>, però no és una solució universal: els atacants XSS encara poden enviar peticions des del navegador de l'usuari (les peticions porten la cookie automàticament) per dur a terme accions (això és l'àmbit de CSRF); HttpOnly tampoc pot defensar contra atacs CSRF (cal SameSite o CSRF Token). Només amb la combinació de la trilogia HttpOnly+Secure+SameSite=Lax/Strict s'aconsegueix un nivell bàsic de seguretat. Les cookies sensibles (session, JWT, access_token) han de ser HttpOnly, i no s'han de donar a llegir al JS del frontend si no és necessari. Aquesta eina marca amb una advertència les cookies que no tenen HttpOnly.
Què són les cookies Partitioned (CHIPS)? Quan cal utilitzar-les?
Partitioned és un nou atribut introduït per Chrome per fer front a l'eliminació de cookies de tercers, amb el nom complet Cookies Having Independent Partitioned State (CHIPS). Les cookies de tercers tradicionals (com les que configuren serveis de publicitat/incrustació en múltiples llocs) són compartides globalment i s'utilitzen per fer seguiment d'usuaris entre llocs. En afegir Partitioned, el navegador emmagatzemarà la cookie de tercer separadament per lloc de nivell superior: la cookie de tercer que l'usuari veu en el lloc A i la que veu en el lloc B són completament independents i no poden compartir identitat entre llocs. Casos d'ús: components de vídeo/mapes/pagaments incrustats, connectors de servei d'atenció al client de tercers, SSO entre llocs incrustats en iframe. L'ús de Partitioned requereix establir Secure obligatòriament i es recomana acompanyar-lo del prefix __Host-.
Quant pot emmagatzemar com a màxim una cookie? Quantes es poden posar per domini?
Segons RFC 6265, els navegadors admeten com a mínim 4096 bytes per cookie (incloent nom, valor i atributs), i els navegadors principals (Chrome/Firefox/Safari/Edge) apliquen aquest límit; la part que el superi serà truncada o descartada silenciosament. Els límits de nombre varien segons el navegador: Chrome uns 180 per domini, Firefox uns 150, Safari uns 600 (i sotmesos a la política de neteja de 7 dies d'ITP); en superar el límit, els navegadors eliminaran les cookies més antigues mitjançant l'estratègia LRU. Es recomana que les cookies només emmagatzemin identificadors de sessió, i no hi posis grans blocs de dades de negoci (les dades de negoci s'han de posar en localStorage o en sessions del costat servidor).
Admet copiar Set-Cookie directament des de Chrome DevTools per analitzar-lo? Cal eliminar el prefix manualment?
Totalment admès, no cal processar-ho manualment. Pots fer clic a la petició objectiu al panell Network de Chrome DevTools, fer clic dret al valor de Set-Cookie a la secció Response Headers i copiar-lo directament (en múltiples línies, fes clic múltiple amb Ctrl/⌘ o copia la secció sencera), i enganxar-lo a l'àrea d'entrada d'aquesta eina. L'eina eliminarà automàticament el prefix Set-Cookie: del començament de cada línia (sensible a majúscules i minúscules), processarà automàticament els espais en blanc al principi i al final de les línies, tractarà correctament caràcters especials comes, punts i comes, etc. que contenen les dates Expires, i també processarà correctament els valors de cookie entre cometes dobles.
Per què els caràcters xinesos o especials en el valor de la cookie es converteixen en forma %XX?
RFC 6265 requereix que els valors de cookie només utilitzin un subconjunt segur del joc de caràcters ASCII, i no poden contenir directament caràcters xinesos, espais, comes, punts i comes, etc. Molts frameworks del costat servidor codifiquen automàticament en URL (encodeURIComponent/Percent-encoding) els caràcters no ASCII en configurar cookies; per exemple, «你好» es codificarà com %E4%BD%A0%E5%A5%BD. El navegador també manté la forma codificada en retornar-la. Quan aquesta eina detecta que un valor conté codificació %XX, mostra automàticament el text original descodificat amb decodeURIComponent mitjançant una fletxa verda al costat del valor original, per facilitar-ne la consulta del contingut real.
Quina diferència hi ha entre la capçalera Set-Cookie i la capçalera Cookie?
Són capçaleres en direccions completament diferents: Set-Cookie és una capçalera de resposta (servidor → navegador), només apareix en les respostes, pot aparèixer diverses vegades, cada vegada configura una cookie i conté tots els atributs (Secure/HttpOnly/Path/Domain, etc.); Cookie és una capçalera de petició (navegador → servidor), només apareix una vegada per petició i conté una llista plana de parells nom=valor de totes les cookies que coincideixen amb l'àmbit actual (name1=v1; name2=v2), sense cap informació d'atributs. Això significa que el servidor no pot saber des de la petició si una cookie té HttpOnly o Secure; la informació d'atributs només la conserva el navegador quan l'emmagatzema localment. Per analitzar la capçalera Cookie de la petició, utilitza l'<a href='/network/http-cookie-parser/'>analitzador de capçaleres Cookie de petició</a> complementari.
Per què les meves cookies desapareixen al cap d'uns dies a Safari?
Això és degut al mecanisme de Prevenció de Seguiment Intel·ligent (ITP: Intelligent Tracking Prevention) de Safari. Des d'ITP 2.1, si l'usuari no ha interactuat directament amb aquest domini en 7 dies (és a dir, no ha visitat directament el lloc d'aquest domini), Safari netejarà totes les cookies i dades del lloc sota aquest domini, independentment de la durada que s'hagi establert per a Max-Age/Expires. Això afecta més els serveis incrustats de tercers, i no afecta les cookies del lloc principal mentre l'usuari hi accedeix contínuament. A més, Safari té restriccions més estrictes sobre les cookies de tercers que Chrome. Les solucions inclouen utilitzar l'atribut Partitioned, sol·licitar permisos mitjançant l'API Storage Access, o refrescar la cookie novament quan l'usuari visita el lloc principal. La secció de resolució de problemes d'aquesta eina inclou una guia de depuració més detallada per a Safari.
L'eina admet l'anàlisi massiva de múltiples Set-Cookie? Pujarà el contingut de les cookies al servidor?
Admet anàlisi massiva. L'àrea d'entrada admet enganxar qualsevol nombre de línies de Set-Cookie (per exemple enganxar una secció sencera de capçaleres de resposta d'una vegada), cada Set-Cookie s'analitzarà amb numeració independent, i múltiples targetes d'atributs mostraran els seus atributs i advertències respectius. Tot el procés d'anàlisi es realitza completament de forma local al teu navegador (processament JavaScript purament de frontend), el contingut de les cookies no es pujarà a cap servidor ni s'enviarà cap petició de xarxa; la informació sensible com Session/Token que enganxis no sortirà del teu ordinador, i ho pots utilitzar amb total tranquil·litat.
