Set-Cookie Parser

Set-Cookie-Parser

Fügen Sie mehrzeilige Set-Cookie-Antwortheader ein, um Attribute zu prüfen und riskante SameSite-/Secure-Kombinationen zu markieren.

Cookie-Attributkarten

2 Set-Cookie(s)

#1sessionabc123

path/

httponly(Flag)

secure(Flag)

samesiteLax

Keine offensichtlichen Attributprobleme gefunden

#2preview1

max-age600 (10m 0s)

setCookieParser.attr.maxAgeHint

samesiteNone

secure(Flag)

setCookieParser.warn.missingHttpOnlysetCookieParser.warn.missingPath

JSON-Vorschau

[
  {
    "index": 0,
    "raw": "session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax",
    "name": "session",
    "value": "abc123",
    "decodedValue": "abc123",
    "attributes": [
      {
        "key": "path",
        "value": "/"
      },
      {
        "key": "httponly",
        "value": null
      },
      {
        "key": "secure",
        "value": null
      },
      {
        "key": "samesite",
        "value": "Lax"
      }
    ],
    "attributeMap": {
      "path": "/",
      "httponly": true,
      "secure": true,
      "samesite": "Lax"
    },
    "warnings": []
  },
  {
    "index": 1,
    "raw": "preview=1; Max-Age=600; SameSite=None; Secure",
    "name": "preview",
    "value": "1",
    "decodedValue": "1",
    "attributes": [
      {
        "key": "max-age",
        "value": "600"
      },
      {
        "key": "samesite",
        "value": "None"
      },
      {
        "key": "secure",
        "value": null
      }
    ],
    "attributeMap": {
      "max-age": "600",
      "samesite": "None",
      "secure": true
    },
    "warnings": [
      "warn.missingHttpOnly",
      "warn.missingPath"
    ]
  }
]

Fügen Sie Ihre Set-Cookie-Header ein und sehen Sie sofort, warum der Browser Ihre Cookies nicht akzeptiert.

Anwendungsfälle

Wenn Browser das Schreiben von Cookies verweigern, schnell identifizieren, ob es sich um ein SameSite-Richtlinienproblem, ein fehlendes Secure-Flag oder eine Path/Domain-Nichtübereinstimmung handelt
Debuggen Sie von Browsern blockierte Cookies in Drittanbieter-Login/SSO/eingebetteten iframe-Szenarien – überprüfen Sie, ob SameSite=None korrekt mit Secure gepaart ist
Bei Sicherheitsaudits stapelweise prüfen, ob von APIs zurückgegebene Cookies alle HttpOnly gesetzt haben, um XSS-Diebstahl zu verhindern, und Secure, um HTTP-Klartextübertragung zu verhindern
Bei Verwendung von __Host-/__Secure--präfixierten Cookies überprüfen, ob die obligatorischen RFC 6265bis-Anforderungen erfüllt sind, um stilles Verwerfen durch Browser zu vermeiden
Beim Debuggen von CHIPS (Partitioned Cookie) Drittanbieter-Cookie-Partitionierung bestätigen, dass Partitioned und Secure gemeinsam deklariert sind
Beim serverseitigen Setzen von Max-Age/Expires gültige Werte bestätigen, um sofortigen Cookie-Ablauf durch Zeitversatz oder Max-Age=0 zu vermeiden
Vergleichen Sie Set-Cookie-Header-Unterschiede zwischen Umgebungen (Entwicklung/Staging/Produktion), um den mysteriösen Fall zu debuggen, dass Cookies lokal funktionieren, aber in der Produktion verschwinden
Kopieren Sie gesamte Response-Header direkt aus DevTools oder curl-Antworten – das Set-Cookie: Präfix muss nicht manuell entfernt werden, das Tool entfernt es automatisch
Beim Schreiben von API-Dokumentation oder Debuggen von WASM/WebWorker-Anfragefehlern fügen Sie analysierte JSON-Ergebnisse direkt in Dokumente ein, um die Cookie-Struktur zu veranschaulichen

Funktionen

Unabhängige Multi-Cookie-Analyse: Jede Set-Cookie-Zeile wird zu einer eigenen nummerierten Karte mit Name, Wert und URL-dekodiertem Wert – problematische Cookies auf einen Blick erkennen
14-Punkte-Sicherheitsattributprüfung: Erkennt automatisch SameSite=None ohne Secure, ungültige SameSite-Werte, Partitioned ohne Secure, fehlendes HttpOnly, fehlendes Path, fehlendes SameSite, __Host-Präfixverstöße, __Secure- ohne Secure, ungültiges/nullwertiges Max-Age, führenden Punkt in Domain, Expires ohne Max-Age und weitere häufige Fehler
Vollständige Attributsaufschlüsselung: SameSite, Secure, HttpOnly, Path, Domain, Expires, Max-Age, Partitioned punkt für punkt aufgelistet – Flag-Attribute und wertbehaftete Attribute klar unterschieden
Automatische Max-Age-Umrechnung: Sekunden werden automatisch in lesbare Zeit in Tagen/Stunden/Minuten/Sekunden umgerechnet, z.B. Max-Age=2592000 wird als 30d angezeigt
Automatische Anzeige URL-dekodierter Werte: Wenn Cookie-Werte %XX-Kodierung enthalten, wird der dekodierte Originaltext automatisch angezeigt (z.B. sessionID%3Dabc → sessionID=abc) mit grünem Pfeilindikator
RFC 6265bis-Präfixvalidierung: Prüft streng die Compliance-Anforderungen für __Host- und __Secure--präfixierte Cookies, einschließlich Path=/, kein Domain und obligatorisches Secure
Ein-Klick-Rohheader-Kopie: Alle analysierten Cookie-Rohzeilen zum einfachen Kopieren in E-Mails, Issues oder Dokumente zur Teambesprechung zusammenfassen
Strukturierte JSON-Vorschau: Analyseergebnisse unterstützen JSON-Ausgabe mit vollständigen Feldern: name/value/decodedValue/attributes/attributeMap/warnings – direkt in Skripten und Testfällen verwendbar
Vollständig lokale Verarbeitung: Set-Cookie-Inhalte werden vollständig in Ihrem Browser analysiert, niemals auf Server hochgeladen – schützt sensible Sitzungen, Tokens und andere Daten
Intelligente Warnmarken: Jedes Problem wird mit einer orangefarbenen Warnmarke mit genauer Angabe des Grundes markiert – kein zeilenweises Nachschlagen in RFC-Dokumenten nötig
Massive Mehrzeileneingabe: Fügen Sie gesamte Response-Header auf einmal ein (z.B. aus Chrome DevTools Network Panel kopiert) – das Set-Cookie: Präfix wird automatisch entfernt und zeilenweise analysiert
Unterstützt Werte mit Anführungszeichen und Semikolons: Verarbeitet korrekt doppelt angeführte Cookie-Werte und Semikolons in Expires-Daten gemäß RFC-Spezifikation, keine fehlerhafte Aufteilung

Anleitung

Öffnen Sie das DevTools Network-Panel Ihres Browsers, finden Sie die Zielanfrage und kopieren Sie den Set-Cookie-Inhalt aus dem Response Headers-Bereich (unterstützt mehrere Zeilen – kopieren Sie alle Cookies auf einmal)
Fügen Sie die kopierten Set-Cookie-Response-Header in den Eingabebereich ein, ein Cookie pro Zeile (das Set-Cookie: Präfix muss nicht manuell gelöscht werden; das Tool entfernt es automatisch)
Das Tool analysiert in Echtzeit: Oben wird angezeigt, wie viele Set-Cookie-Header erkannt wurden, und unten erscheint jedes Cookie als eigene Attributkarte
Der Kartenkopf zeigt Nummer, Cookie-Name und Rohwert; wenn der Wert URL-Kodierung enthält, erscheint der dekodierte Wert nach einem grünen Pfeil
Der Kartenkörper zeigt Attribute punkt für punkt an: SameSite, Secure, HttpOnly, Path, Domain, Max-Age, Expires, Partitioned usw. Max-Age fügt automatisch eine parenthetische Angabe mit lesbarer Zeitumrechnung hinzu
Der Kartenfuß zeigt Prüfergebnisse: Orangefarbene Warnmarken kennzeichnen spezifische Probleme (jedes Problem hat eine klare Erklärung), grüne Marken bedeuten, dass keine offensichtlichen Probleme erkannt wurden
Wenn Sie mit der Serverkonfiguration vergleichen müssen, klicken Sie auf 'Rohheader kopieren', um alle ursprünglichen Set-Cookie-Zeilen zu kopieren; für programmatische Verarbeitung prüfen Sie 'JSON-Vorschau'

Häufig gestellte Fragen

Warum wurde der Set-Cookie-Header erfolgreich gesetzt, aber der Browser hat mein Cookie nicht gespeichert?

Dies ist das häufigste Problem. Browser melden keine Fehler aktiv; sie verwerfen nicht konforme Cookies stillschweigend. Häufige Ursachen sind: SameSite=None fehlt Secure, Secure-Cookies auf HTTP-Seiten gesetzt (localhost-Ausnahme), __Host-/__Secure--Präfixe erfüllen Einschränkungen nicht, Domain/Path-Nichtübereinstimmung, Überschreitung der 4KB-Größenbeschränkung, Max-Age ist 0 oder negativ. Wir empfehlen, zuerst Ihre Set-Cookie-Header in dieses Tool einzufügen, um Warnmarken zu prüfen und die spezifische Ursache zu ermitteln, dann Chrome DevTools → Application → Cookies zu öffnen, unter der entsprechenden Domain nach einem gelben Warndreieck zu suchen und darüber zu fahren, um den genauen Ablehnungsgrund anzuzeigen.

Was genau ist der Unterschied zwischen SameSite Strict, Lax und None? Wann sollte ich welches verwenden?

Strict erlaubt Cross-Site-Senden vollständig nicht – am sichersten, aber Benutzer, die von externen Links hereinklicken, scheinen abgemeldet zu sein, geeignet für sensible Vorgänge wie Zahlungen/Passwortänderungen. Lax ist der Standard in Chrome 80+, erlaubt das Senden von Cookies, wenn Benutzer über Top-Level-GET-Navigation von externen Links auf Ihre Site zurückkehren, jedoch nicht für Subressourcen wie iframe/img/script/XHR/POST-Formulare – empfohlener Wert für die meisten Szenarien. None erlaubt das Senden in allen Cross-Site-Szenarien (für SSO Single Sign-On, Drittanbieter-eingebettete iframes, Cross-Site-API-Aufrufe), muss aber mit Secure gepaart sein, da der Browser es sonst direkt ablehnt.

Warum muss SameSite=None mit Secure gepaart werden?

Dies ist eine Regel, die Chrome seit Version 80 (Februar 2020) durchsetzt, wobei Firefox, Edge und Safari alle nachgezogen haben. Da SameSite=None das Cross-Site-Cookie-Senden explizit erlaubt, können Angreifer in Cross-Site-Szenarien leichter CSRF ausführen oder abhören, daher muss es mit Secure (HTTPS-verschlüsselte Übertragung) gepaart werden, um Risiken zu mindern. Wenn Ihr SameSite=None-Cookie über HTTP gesetzt wird, verwirft der Browser ihn einfach, ohne ihn zu speichern. Dieses Tool erkennt SameSite=None-ohne-Secure-Kombinationen und kennzeichnet sie mit roten Warnungen.

Sollte ich Max-Age oder Expires verwenden? Was ist der Unterschied?

Bevorzugen Sie Max-Age. Max-Age ist relative Zeit (läuft nach N Sekunden ab), hängt nicht von der Client-Uhr ab, und der Browser beginnt nach dem Empfang mit dem Countdown; Expires ist ein absoluter Zeitpunkt, abhängig von der lokalen Computerzeit des Benutzers (wenn ein Benutzer seine Uhr auf 1970 einstellt, läuft das Cookie sofort ab). Wenn beide vorhanden sind, hat Max-Age Vorrang (ausdrücklich in RFC 6265 festgelegt). Wenn keines von beiden gesetzt ist, wird das Cookie zu einem 'Session-Cookie', das abläuft, wenn der Browser geschlossen wird. Dieses Tool fordert auf, wenn Expires ohne Max-Age gesetzt ist, und empfiehlt, Max-Age hinzuzufügen. Hinweis: Max-Age ist in Sekunden, nicht Millisekunden.

Was ist der Unterschied zwischen Path=/ und dem Nichtsetzen von Path?

Path bestimmt, für welche URL-Pfad-Anfragen der Browser dieses Cookie einschließt. Wenn Path nicht gesetzt ist, verwendet der Browser standardmäßig 'den Pfad der Antwort-URL ohne das letzte Segment' – wenn Sie beispielsweise ein Cookie von /api/user/login setzen, ist der Standard-Path /api/user/, sodass Anfragen unter / und /order/ dieses Cookie nicht enthalten. Explizites Setzen von Path=/ macht das Cookie für die gesamte Site gültig. Beachten Sie, dass Path-Abgleich Präfixabgleich ist – Path=/api matcht auch /api/, /api/user, /api/v2/abc usw. __Host-präfixierte Cookies erfordern Path=/.

Was ist der Unterschied zwischen einer Domain mit führendem Punkt (wie .example.com) und ohne?

In modernen Browsern (neueren Versionen von Chrome, Firefox, Edge, Safari) sind die beiden gleichwertig – beide machen das Cookie für example.com und alle seine Subdomains (a.example.com, b.c.example.com) gültig. Der führende Punkt war alte Syntax aus der RFC-2109-Ära; RFC 6265 schreibt explizit vor, führende Punkte zu ignorieren. Aus Gründen der Lesbarkeit wird jedoch die Form ohne Punkt empfohlen. Dieses Tool weist auf Domains mit führendem Punkt hin (kein Fehler, aber eine veraltete Notation). Hinweis: Wenn Domain nicht gesetzt ist, gilt das Cookie nur für den aktuellen Host (Subdomains erhalten es nicht); durch Setzen von Domain gilt es auch für Subdomains.

Was sind die Host- und Secure--Präfixe? Kann ich sie weglassen?

Dies sind in RFC 6265bis eingeführte Cookie-Namenssicherheitspräfixe, um Hochsicherheits-Cookies harte Einschränkungen aufzuerlegen: Wenn Browser sehen, dass ein Cookie-Name mit __Host- beginnt, erzwingen sie, dass Secure gesetzt ist, Path=/ ist und Domain nicht gesetzt ist – wird eine Bedingung nicht erfüllt, wird die Speicherung direkt abgelehnt; das __Secure--Präfix erfordert, dass Secure gesetzt ist, andere Attribute sind konfigurierbar. Cookies funktionieren auch ohne Präfixe (die meisten Cookies verwenden keine Präfixe), aber __Host- wird für Hochsicherheits-Cookies wie Sitzungs-IDs und Authentifizierungs-Tokens dringend empfohlen, da es Cookie-Injektionsangriffe auf Subdomain-/Pfad-Ebene verhindert. Dieses Tool erkennt automatisch die Konformität beider Präfixtypen.

Sind HttpOnly-Cookies wirklich sicher? Verhindern sie XSS und CSRF?

HttpOnly verhindert, dass JavaScript Cookie-Werte über document.cookie liest, was es zu einer wichtigen Verteidigungslinie bei der <strong>Minderung von XSS-Sitzungsdiebstahl</strong> macht, aber es ist kein Allheilmittel: XSS-Angreifer können weiterhin Anfragen im Browser des Benutzers initiieren (die automatisch Cookies enthalten), um Aktionen durchzuführen (dies ist CSRF-Bereich); HttpOnly verteidigt auch nicht gegen CSRF-Angriffe (erfordert SameSite oder CSRF-Tokens). Das volle Trio aus HttpOnly+Secure+SameSite=Lax/Strict muss zusammen verwendet werden, um ein grundlegendes Sicherheitsniveau zu erreichen. Sensible Cookies (session, JWT, access_token) müssen HttpOnly sein; setzen Sie sie für Frontend-JS nicht unnötig frei. Dieses Tool warnt bei Cookies, denen HttpOnly fehlt.

Was sind Partitioned (CHIPS)-Cookies? Wann muss ich sie verwenden?

Partitioned ist ein neues Attribut, das Chrome in Vorbereitung auf die Abschaffung von Drittanbieter-Cookies eingeführt hat, kurz für Cookies Having Independent Partitioned State (CHIPS). Herkömmliche Drittanbieter-Cookies (wie die von Werbung/eingebetteten Diensten auf mehreren Sites gesetzten) werden global geteilt und konnten zum Cross-Site-Tracking von Benutzern verwendet werden. Mit hinzugefügtem Partitioned speichern Browser dieses Drittanbieter-Cookie getrennt pro Top-Level-Site: Das Drittanbieter-Cookie, das ein Benutzer auf Site A sieht, ist vollständig unabhängig von dem auf Site B, ohne Cross-Site-Identitätsfreigabe. Anwendungsfälle: eingebettete Video-/Karten-/Zahlungskomponenten, Drittanbieter-Chat-Plugins, Cross-Site-SSO-eingebettete iframes. Partitioned muss mit Secure verwendet werden und wird mit dem __Host--Präfix empfohlen.

Wie viele Daten kann ein einzelnes Cookie speichern? Wie viele können pro Domain platziert werden?

Gemäß RFC 6265 müssen Browser mindestens 4096 Bytes pro Cookie unterstützen (einschließlich Name, Wert und Attribute). Wichtige Browser (Chrome/Firefox/Safari/Edge) erzwingen dieses Limit; Überschüssiges wird stillschweigend abgeschnitten oder verworfen. Anzahlbeschränkungen variieren je nach Browser: Chrome erlaubt ~180 pro Domain, Firefox ~150, Safari ~600 (und ist von der ITP-7-Tage-Bereinigungsrichtlinie betroffen), danach verdrängen Browser die ältesten Cookies über eine LRU-Strategie. Wir empfehlen, dass Cookies nur Sitzungs-IDs speichern – speichern Sie keine großen Geschäftsdatensegmente in Cookies (speichern Sie Geschäftsdaten in localStorage oder serverseitigen Sitzungen).

Unterstützt es das Parsen von direkt aus Chrome DevTools kopierten Set-Cookie? Muss ich Präfixe manuell entfernen?

Vollständig unterstützt – keine manuelle Verarbeitung erforderlich. Sie können zu Chrome DevTools → Network Panel gehen, auf die Zielanfrage klicken, mit der rechten Maustaste auf den Set-Cookie-Wert im Response Headers-Bereich klicken und direkt kopieren (bei mehreren Zeilen Ctrl/⌘+Klick zur Mehrfachauswahl oder zum Kopieren des gesamten Blocks) und dann in den Eingabebereich dieses Tools einfügen. Das Tool entfernt automatisch das Set-Cookie:-Präfix vom Anfang jeder Zeile (groß-/kleinschreibungsunabhängig), verarbeitet führende/nachfolgende Leerzeichen, verarbeitet korrekt Sonderzeichen wie Kommas und Semikolons in Expires-Daten und verarbeitet korrekt doppelt angeführte Cookie-Werte.

Warum werden chinesische Zeichen oder Sonderzeichen in Cookie-Werten zu %XX-Form?

RFC 6265 erfordert, dass Cookie-Werte nur eine sichere Teilmenge des ASCII-Zeichensatzes verwenden und chinesische Schriftzeichen, Leerzeichen, Kommas, Semikolons usw. nicht direkt enthalten dürfen. Viele serverseitige Frameworks kodieren Nicht-ASCII-Zeichen automatisch URL (encodeURIComponent/Prozentkodierung), wenn sie Cookies setzen, z.B. '你好' wird zu %E4%BD%A0%E5%A5%BD kodiert. Browser behalten die kodierte Form auch beim Zurücksenden bei. Wenn dieses Tool Werte mit %XX-Kodierung erkennt, zeigt es automatisch den mit decodeURIComponent dekodierten Originaltext neben dem Rohwert mit einem grünen Pfeil zur besseren Übersicht an.

Was ist der Unterschied zwischen Set-Cookie und dem Cookie-Request-Header?

Sie sind Header in vollständig entgegengesetzte Richtungen: Set-Cookie ist ein Response-Header (Server → Browser), erscheint nur in Antworten, kann mehrmals erscheinen und setzt jedes Mal ein Cookie mit vollständigen Attributen (Secure/HttpOnly/Path/Domain usw.); Cookie ist ein Request-Header (Browser → Server), erscheint nur einmal pro Anfrage und enthält flache name=value-Paare (name1=v1; name2=v2) aller im Bereich passenden Cookies, ohne jegliche Attributinformationen. Das bedeutet, Server können aus Anfragen nicht erkennen, ob ein Cookie HttpOnly oder Secure gesetzt hat – Attributinformationen werden nur vom Browser bei lokaler Speicherung behalten. Zum Parsen von Cookie-Request-Headern verwenden Sie den begleitenden <a href='/network/http-cookie-parser/'>Cookie-Request-Header-Parser</a>.

Warum verschwinden meine Cookies in Safari nach einigen Tagen?

Dies ist Safaris Intelligent Tracking Prevention (ITP)-Mechanismus am Werk. Ab ITP 2.1 bereinigt Safari, wenn ein Benutzer 7 Tage lang nicht direkt mit einer Domain interagiert (d.h. die Domain-Site nicht direkt besucht hat), alle Cookies und Websitedaten unter dieser Domain, unabhängig davon, wie lang Max-Age/Expires gesetzt ist. Dies hat die größten Auswirkungen auf eingebettete Drittanbieterdienste, während Hauptseiten-Cookies nicht betroffen sind, solange Benutzer die Site weiterhin besuchen. Darüber hinaus sind Safaris Beschränkungen für Drittanbieter-Cookies strenger als die von Chrome. Lösungen umfassen: Verwenden des Partitioned-Attributs, Anfordern von Berechtigungen über die Storage Access API oder Aktualisieren von Cookies, wenn Benutzer die Hauptsite besuchen. Der Fehlerbehebungsabschnitt dieses Tools enthält detailliertere Safari-Debugging-Anleitungen.

Unterstützt das Tool die Massenanalyse mehrerer Set-Cookie-Header? Werden Cookie-Inhalte auf Server hochgeladen?

Massenanalyse wird unterstützt. Der Eingabebereich unterstützt das Einfügen beliebig vieler mehrzeiliger Set-Cookie-Header (z.B. Einfügen eines gesamten Antwort-Header-Blocks auf einmal). Jeder Set-Cookie wird mit unabhängiger Nummerierung analysiert, wobei mehrere Attributkarten ihre jeweiligen Attribute und Warnungen anzeigen. Alle Analyseprozesse laufen vollständig lokal in Ihrem Browser ab (reine Frontend-JavaScript-Verarbeitung). Cookie-Inhalte werden niemals auf Server hochgeladen, keine Netzwerkanfragen werden gestellt, und sensible Informationen wie Sitzungen/Tokens, die Sie einfügen, verlassen Ihren Computer nicht – verwenden Sie es mit Vertrauen.

术语表

Set-Cookie: HTTP-Response-Header, über den der Server den Browser anweist, Cookies zu speichern; kann in einer Antwort mehrmals vorkommen.
Cookie (Request-Header): HTTP-Request-Header mit einer Liste von bereichskonformen Cookie-Name-Wert-Paaren, die automatisch vom Browser angehängt werden, ohne Attribute.
HttpOnly: Cookie-Attribut-Flag. Wenn gesetzt, kann JavaScript das Cookie nicht über document.cookie lesen, dient hauptsächlich der Abwehr von XSS-Sitzungsdiebstahl.
Secure: Cookie-Attribut-Flag. Wenn gesetzt, sendet der Browser dieses Cookie nur über verschlüsselte HTTPS (oder localhost)-Verbindungen.
SameSite: Cookie-Attribut, das steuert, ob Cookies bei Cross-Site-Anfragen gesendet werden; Werte sind Strict/Lax/None. Standardmäßig Lax in Chrome 80+.
Max-Age: Cookie-Attribut, das die Cookie-Lebensdauer in Sekunden angibt. Hat Vorrang vor Expires, empfohlen. =0 bedeutet sofortiges Löschen.
Expires: Cookie-Attribut, das einen bestimmten Ablaufzeitpunkt angibt (HTTP-date), abhängig von der Client-Uhr.
Path: Cookie-Attribut, das das URL-Pfad-Präfix einschränkt, für das das Cookie aktiv ist; Standard ist der Verzeichnisteil der Antwort-URL.
Domain: Cookie-Attribut, das die Domain einschränkt, für die das Cookie aktiv ist. Wenn nicht gesetzt, nur aktueller Host; wenn gesetzt, auch für Subdomains gültig.
Partitioned (CHIPS): Cookie-Attribut-Flag zur Aktivierung partitionierter Drittanbieter-Cookie-Speicherung; der Ersatzansatz, nachdem Chrome Drittanbieter-Cookies abschafft, muss mit Secure gepaart werden.
__Host- Präfix: Sicherheitseinschränkung für Cookie-Namenspräfixe. Erfordert Secure, Path=/, kein Domain-Attribut; Browser lehnen Speicherung bei Verstoß ab.
__Secure- Präfix: Sicherheitseinschränkung für Cookie-Namenspräfixe. Erfordert gesetztes Secure; Browser lehnen Speicherung bei Verstoß ab.
Session-Cookie: Ein Cookie ohne gesetztes Max-Age oder Expires; wird automatisch gelöscht, wenn der Browser geschlossen wird.
Drittanbieter-Cookie (Third-party Cookie): Ein Cookie, das unter einer anderen Domain als der aktuell besuchten Seite gesetzt wird, typischerweise von Werbung, Analytik, eingebetteten iframes und anderen Drittanbieterdiensten; wird zunehmend in allen Browsern eingeschränkt.

SameSite Drei-Strategien-Schnellvergleichstabelle

Vollständige Set-Cookie-Attribut-Referenztabelle (RFC 6265bis)

Häufige Browser Set-Cookie Größen- und Anzahlbeschränkungen

Set-Cookie Parser