Waarom is de Set-Cookie-header succesvol ingesteld maar heeft de browser mijn Cookie niet opgeslagen?
Dit is het meest voorkomende probleem: de browser geeft niet actief een foutmelding, maar verwijdert stilletjes niet-conforme Cookies. Veelvoorkomende oorzaken zijn: SameSite=None zonder Secure, Secure Cookie ingesteld op een HTTP-pagina (behalve localhost), __Host-/__Secure--voorvoegsels voldoen niet aan beperkingen, niet-overeenkomende Domain/Path, overschrijding van 4KB-limiet, Max-Age is 0 of negatief. Aanbevolen wordt om eerst Set-Cookie in deze tool te plakken om de specifieke reden te achterhalen via de waarschuwingsbadges, open vervolgens Chrome DevTools → Application → Cookies, controleer onder het bijbehorende domein of er een gele waarschuwingsdriehoek is — als je er met de muis overheen gaat, zie je de specifieke reden van weigering.
Wat is precies het verschil tussen Strict, Lax en None van SameSite? Wanneer gebruik ik welke?
Strict staat cross-site verzending helemaal niet toe, het veiligst maar de gebruiker lijkt uitgelogd bij het klikken op links van andere sites, geschikt voor Cookies voor gevoelige bewerkingen zoals betalingen/wachtwoordwijziging. Lax is de standaardwaarde van Chrome 80+, staat verzending toe bij GET-navigatie op topniveau (klikken op een link van een andere site die terugkeert naar je site) maar niet bij subresources zoals iframe/img/script/XHR/POST-formulieren, en is de aanbevolen waarde voor de meeste scenario's. None staat verzending toe in alle cross-site scenario's (gebruikt voor SSO eenmalige aanmelding, derde-partij insluitingen in iframe, cross-site API-aanroepen) maar moet samen met Secure worden ingesteld, anders weigert de browser direct.
Waarom moet SameSite=None vergezeld gaan van Secure?
Dit is een regel die door Chrome is afgedwongen vanaf versie 80 (februari 2020), gevolgd door Firefox, Edge en Safari. Omdat SameSite=None expliciet cross-site verzending van Cookies toestaat, hebben aanvallers het gemakkelijker om CSRF of afluisteren te lanceren in cross-site scenario's, en is het noodzakelijk om samen met Secure (versleutelde HTTPS-verzending) te gebruiken om risico's te verkleinen. Als je SameSite=None Cookie via HTTP wordt ingesteld, zal de browser deze verwijderen zonder op te slaan. Deze tool detecteert de combinatie SameSite=None zonder Secure en markeert deze met een rode waarschuwing.
Wat moet ik gebruiken: Max-Age of Expires? Wat is het verschil?
Geef de voorkeur aan Max-Age. Max-Age is relatieve tijd (verloopt na hoeveel seconden), is niet afhankelijk van de klok van de client, de browser start de aftelling bij ontvangst; Expires is een absoluut tijdstip, afhankelijk van de lokale tijd van de computer van de gebruiker (als de gebruiker de klok naar 1970 zet, verloopt de Cookie onmiddellijk). Wanneer beide aanwezig zijn heeft Max-Age hogere prioriteit (expliciet gespecificeerd in RFC 6265). Als geen van beide is ingesteld, wordt de Cookie een «sessie-Cookie» die verloopt bij het sluiten van de browser. Deze tool geeft een tip wanneer Expires is ingesteld maar Max-Age niet, en adviseert om Max-Age toe te voegen. Let op: de eenheid van Max-Age is seconden, geen milliseconden.
Wat is het verschil tussen Path=/ en het niet instellen van Path?
Path bepaalt bij welke URL-paden de browser de Cookie bij verzoeken zal verzenden. Wanneer Path niet is ingesteld, gebruikt de browser standaard «het pad van de respons-URL zonder het laatste segment». Bijvoorbeeld bij het instellen van een Cookie vanaf /api/user/login is de standaard Path /api/user/, dus verzoeken op het pad / en /order/ zullen deze Cookie niet verzenden. Expliciet instellen van Path=/ zorgt ervoor dat de Cookie voor de hele site geldt. Let op: Path-overeenkomst is voorvoegselovereenkomst — Path=/api komt ook overeen met /api/, /api/user, /api/v2/abc, enz. Cookies met __Host--voorvoegsel vereisen verplicht Path=/.
Wat is het verschil tussen Domain met een punt aan het begin (zoals .example.com) en zonder punt?
In moderne browsers (recente versies van Chrome, Firefox, Edge, Safari) zijn beide inmiddels equivalent: beide zorgen ervoor dat de Cookie geldt voor example.com en al zijn subdomeinen (a.example.com, b.c.example.com). De punt aan het begin was een oude syntaxis uit de tijd van RFC 2109 — RFC 6265 specificeert al dat de beginpunt wordt genegeerd. Voor de leesbaarheid wordt echter aanbevolen om zonder punt te schrijven. Deze tool geeft een tip wanneer Domain een beginpunt heeft (geen fout, maar historische syntaxis). Let op: wanneer Domain niet is ingesteld, geldt de Cookie alleen voor de huidige host (subdomeinen krijgen hem niet), bij het instellen van Domain gaat hij ook gelden voor subdomeinen.
Wat zijn de __Host- en __Secure--voorvoegsels? Kan ik zonder voorvoegsels werken?
Dit zijn beveiligingsvoorvoegsels voor Cookie-namen geïntroduceerd in RFC 6265bis om strenge beperkingen op te leggen aan hoogbeveiligde Cookies: wanneer de browser ziet dat de Cookie-naam begint met __Host-, eist hij verplicht Secure, Path=/ en geen Domain-attribuut — als aan een voorwaarde niet wordt voldaan, weigert hij de opslag direct; het __Secure--voorvoegsel vereist dat Secure is ingesteld, andere attributen mogen worden geconfigureerd. Zonder voorvoegsels werken ook (de meeste Cookies gebruiken geen voorvoegsels), maar voor hoogbeveiligde Cookies zoals sessie-ID's en autorisatietokens wordt het gebruik van het __Host--voorvoegsel sterk aanbevolen, omdat het Cookie-injectieaanvallen op subdomein-/padniveau voorkomt. Deze tool detecteert automatisch de naleving van beide voorvoegsels.
Is een HttpOnly Cookie echt veilig? Voorkomt het XSS en CSRF?
HttpOnly voorkomt dat JavaScript Cookie-waarden leest via document.cookie en is een belangrijke verdedigingslinie voor het <strong>beperken van sessiediefstal via XSS</strong>, maar het is geen wondermiddel: XSS-aanvallers kunnen nog steeds verzoeken uitvoeren in de browser van de gebruiker (verzoeken dragen automatisch Cookie) om handelingen uit te voeren (dit is het domein van CSRF); HttpOnly verdedigt ook niet tegen CSRF-aanvallen (hiervoor is SameSite of CSRF Token nodig). Alleen het gelijktijdig gebruiken van de drieluik HttpOnly+Secure+SameSite=Lax/Strict bereikt een basisbeveiligingsniveau. Gevoelige Cookies (session, JWT, access_token) moeten HttpOnly zijn, geef JS van de front-end er geen toegang toe zonder noodzaak. Deze tool markeert Cookies zonder HttpOnly met een waarschuwing.
Wat is een Partitioned (CHIPS) Cookie? Wanneer moet ik het gebruiken?
Partitioned is een nieuw attribuut dat door Chrome is gelanceerd als reactie op de afschaffing van derde-partij Cookies, met volledige naam Cookies Having Independent Partitioned State (CHIPS). Traditionele derde-partij Cookies (zoals die van advertenties/ingesloten diensten die op meerdere sites worden ingesteld) worden globaal gedeeld en kunnen worden gebruikt om gebruikers cross-site te volgen. Met Partitioned slaat de browser de derde-partij Cookie gescheiden op per topniveausite: de derde-partij Cookie die de gebruiker ziet op Site A is volledig onafhankelijk van die op Site B, en kan identiteit niet cross-site delen. Gebruiksscenario's: ingesloten video/kaart-/betalingscomponenten, derde-partij chatplugins, cross-site SSO ingesloten in iframe. Gebruik van Partitioned vereist dat Secure gelijktijdig is ingesteld, aanbevolen met __Host--voorvoegsel.
Hoeveel kan een Cookie maximaal opslaan? Hoeveel Cookies kunnen er per domein?
Volgens RFC 6265 ondersteunen browsers minimaal 4096 bytes per Cookie (inclusief naam, waarde en attributen), en de belangrijkste browsers (Chrome/Firefox/Safari/Edge) handhaven deze limiet — overschrijdende inhoud wordt stil afgekapt of verwijderd. Aantallimieten verschillen per browser: Chrome heeft ongeveer 180 per domein, Firefox ongeveer 150, Safari ongeveer 600 (en wordt beïnvloed door het 7-daagse opschoningsbeleid van ITP); bij overschrijding verwijdert de browser de oudste Cookies volgens LRU-beleid. Aanbevolen wordt dat Cookies alleen sessie-ID's opslaan, plaats geen grote hoeveelheden bedrijfsgegevens in Cookies (bedrijfsgegevens plaats je in localStorage of serversessie).
Ondersteunt de tool het direct kopiëren van Set-Cookie uit Chrome DevTools om te analyseren? Moet ik het voorvoegsel handmatig verwijderen?
Volledig ondersteund, zonder noodzaak van handmatige verwerking. Je kunt op het doelverzoek klikken in het Netwerkpaneel van Chrome DevTools, met de rechtermuisknop op de waarde van Set-Cookie in het Response Headers-gebied klikken om direct te kopiëren (voor meerdere regels Ctrl/⌘+klik voor meervoudige selectie of kopieer het hele blok) en in het invoergebied van deze tool plakken. De tool verwijdert automatisch de Set-Cookie:-voorvoegsel aan het begin van elke regel (hoofdletterongevoelig), verwerkt automatisch witruimte aan begin/einde van regels, verwerkt correct speciale tekens zoals komma's en puntkomma's in Expires-datums, en verwerkt ook correct Cookie-waarden met dubbele aanhalingstekens.
Waarom worden Chinese of speciale tekens in Cookie-waarden de vorm %XX?
RFC 6265 vereist dat Cookie-waarden alleen een veilige subset van de ASCII-tekenset gebruiken, en mogen niet direct niet-ASCII-tekens, spaties, komma's, puntkomma's, enz. bevatten. Veel serverframeworks voeren bij het instellen van Cookies automatisch URL-codering (encodeURIComponent/Percent-encoding) uit op niet-ASCII-tekens. Browsers behouden ook de gecodeerde vorm bij het terugsturen. Wanneer deze tool detecteert dat de waarde %XX-codering bevat, toont hij automatisch de originele tekst gedecodeerd door decodeURIComponent naast de onbewerkte waarde met een groene pijl, om het bekijken van de echte inhoud te vergemakkelijken.
Wat is het verschil tussen Set-Cookie en de Cookie-verzoekheader?
Het zijn headers van volledig verschillende richtingen: Set-Cookie is een responsheader (server→browser), verschijnt alleen in antwoorden, kan meerdere keren verschijnen, en stelt elke keer een Cookie in met volledige attributen (Secure/HttpOnly/Path/Domain, enz.); Cookie is een verzoekheader (browser→server), verschijnt slechts één keer per verzoek, en bevat alle name=value-paren van Cookies die overeenkomen met het huidige bereik in platte vorm (name1=v1; name2=v2), zonder enige attribuutinformatie. Dat betekent dat de server in het verzoek niet kan weten of een Cookie HttpOnly of Secure heeft ingesteld — attribuutinformatie wordt alleen door de browser bewaard bij lokale opslag. Gebruik voor het analyseren van de Cookie-verzoekheader de bijbehorende <a href='/network/http-cookie-parser/'>Cookie-verzoekheader parser</a>.
Waarom verdwijnen mijn Cookies in Safari na een paar dagen?
Dit is het Intelligente Tracking Preventie (ITP: Intelligent Tracking Prevention)-mechanisme van Safari dat in werking treedt. Vanaf ITP 2.1, als de gebruiker 7 dagen lang niet direct met het domein heeft geïnteracteerd (dat wil zeggen de site van het domein niet direct heeft bezocht), wist Safari alle Cookies en sitegegevens onder dat domein, ongeacht hoe lang Max-Age/Expires zijn ingesteld. Dit treft vooral ingesloten derde-partijdiensten, terwijl Cookies van de hoofdsite niet worden beïnvloed zolang de gebruiker de site blijft bezoeken. Bovendien zijn de beperkingen van Safari voor derde-partij Cookies strenger dan die van Chrome. Oplossingen zijn onder andere: gebruik het Partitioned-attribuut, vraag toestemming via de Storage Access API of vernieuw de Cookie wanneer de gebruiker de hoofdsite bezoekt. De probleemoplossingssectie van deze tool bevat meer gedetailleerde aanwijzingen voor debuggen in Safari.
Ondersteunt de tool batchgewijs analyse van meerdere Set-Cookie? Wordt de Cookie-inhoud naar servers verzonden?
Ondersteunt batchgewijze analyse. Het invoergebied ondersteunt het plakken van een willekeurig aantal Set-Cookie-regels (zoals het in één keer plakken van een heel blok responsheaders), elke Set-Cookie wordt geanalyseerd met onafhankelijke nummering, met meerdere attribuutkaarten die afzonderlijk attributen en waarschuwingen tonen. Het gehele analyseproces wordt volledig lokaal in je browser uitgevoerd (pure front-end JavaScript-verwerking), de Cookie-inhoud wordt naar geen enkele server verzonden en er worden geen netwerkverzoeken gedaan — gevoelige informatie zoals Session/Token die je plakt, verlaat je computer niet, je kunt het met een gerust hart gebruiken.
