HTTP-Cookies Wie sie richtig erstellt und parsiert werden

HTTP-Cookies sind überall. Jede Login-Sitzung, Warenkorb und Analyse-Tool hängt von ihnen ab. Doch die meisten Entwickler kopieren einfach einen Header und verlassen ihn, ohne zu verstehen, was die Attribute tatsächlich tun – oder was passiert, wenn sie falsch eingesetzt werden. Set-Cookie Dieser Leitfaden behandelt die Anatomie von Cookies, alle relevanten Attribute, wie man Cookie-Strings parsiert und warum

Ihre CSRF-Verteidigung ist. Wenn Sie sofort hands-on beginnen möchten, probieren Sie das SameSite IO Tools Cookie Parser Cookie Builder oder die Was ein Cookie tatsächlich aussehen sieht.

Wenn ein Server einen Cookie setzen möchte, sendet er einen

Response-Header: Set-Cookie Der Browser speichert diesen und sendet ihn auf folgenden Anfragen zurück als:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400

Das ist das ganze Mechanismus. Die Komplexität liegt in diesen Attributen.

Cookie: sessionId=abc123

Anatomie von Cookies: Die Aufteilung des Strings

Ein Cookie-String folgt einem konsistenten Format:

Das Paar kommt zuerst. Alles nach dem ersten Semikolon ist eine Anweisung an den Browser – der Server sieht diese Attribute nicht in dem

name=value; attribute1; attribute2=attributeValue; ...

Der name=value Header, den er erhält. Cookie Die Sicherheitsattribute, die Sie richtig einstellen müssen

HttpOnly

verhindert, dass JavaScript das Cookie über

HttpOnly liest. Dies ist eine direkte Verteidigung gegen XSS-Angriffe, die Sitzungstoken stehlen. document.cookieJeder Cookie, der ein Benutzer authentifiziert, sollte

Set-Cookie: sessionId=abc123; HttpOnly

besitzen. Es gibt keinen guten Grund, dies nicht zu tun. HttpOnlybedeutet, dass der Browser das Cookie nur über HTTPS-Verbindungen sendet. Ohne es wird das Cookie im Klartext über HTTP übertragen und kann abgefangen werden. In Produktion müssen Sitzungscookies immer

Sicher

Secure besitzen. In der lokalen Entwicklung über Securekönnen Sie es weglassen – Browser machen eine Ausnahme für localhost. http://localhoststeuert, wann der Browser einen Cookie in Quer-Website-Anfragen einschließt. Dies ist die primäre Verteidigung gegen CSRF-Angriffe. Drei Werte:

SameSite

SameSite — der Cookie wird nie in Quer-Website-Anfragen gesendet. Am sichersten, aber Benutzer, die auf eine E-Mail klicken, werden abgemeldet (der Cookie wird nicht in dieser ersten Navigation gesendet).

• Strict — der Cookie wird bei obersten Navigationsanfragen (GET-Anfragen) von externen Websites gesendet, aber nicht bei eingebetteten Quer-Website-Anfragen oder Quer-POST-Anfragen. Dies ist der Standardwert für Cookies ohne explizite
• Lax Attribut. SameSite — der Cookie wird in allen Quer-Website-Anfragen gesendet. Erforderlich für Drittanbieter-Cookies (OAuth-Flows, eingebettete Widgets). Muss mit
• None gekoppelt sein. Secure.

# Third-party / cross-site cookie (e.g., OAuth callback)
Set-Cookie: token=xyz; SameSite=None; Secure

Wenn Sie senden SameSite=None — verwendet die lokale Zeitzone des Servers, stumm. Verwenden Sie Secure, lehnen moderne Browser das Cookie ganz ab. Für die meisten Sitzungscookies verwenden Sie SameSite=Lax — es balanciert Sicherheit mit einer nutzerfreundlichen Anmelderfahrung.

Gebiet: Domain und Pfad

Domain

Der Domain Attribut gibt an, welche Hostnamen den Cookie erhalten.

Set-Cookie: user=alice; Domain=example.com

Mit Domain=example.comwird der Cookie an example.com und alle Unterdomainen (api.example.com, app.example.com) gesendet. Ohne ein Domain Attribut wird der Cookie nur an die genaue Ursprungshost gesendet – nicht an Unterdomainen.

Gängige Vorstellung: Das Setzen von Domain=example.com beschränkt den Cookie auf nur nicht . Es erweitert den Bereich auf die Unterdomainen. Omit das Attribut, wenn Sie einen einzelnen Host-Cookie wünschen. example.combeschränkt die URL-Pfade, bei denen der Cookie gesendet wird.

Weg

Path Dieser Cookie wird nur bei Anfragen zu

Set-Cookie: adminToken=xyz; Path=/admin

und unterhalb davon mitgegeben. Eine Anfrage zu /admin würde ihn nicht enthalten. Der Standardwert ist / oder /api , was alle Pfade beinhaltet. /Max-Age vs. Expires

Beide steuern, wann ein Cookie abläuft. Vorteil

nimmt ein absolutes Datum im HTTP-Datum-Format. Dies ist relativ zum Client-Uhrzeit, die Sie nicht kontrollieren können. Max-Age.

• Expires nimmt eine Anzahl von Sekunden ab jetzt:
• Max-Age für 24 Stunden. Relativ zum Server-Intent, nicht zum Client-Uhrzeit. Max-Age=86400 Wenn beide vorhanden sind,

nimmt Vorrang. Ein Cookie mit weder Attribut ist ein Max-Age Sitzungscookie — es verschwindet, wenn der Browser geschlossen wird. Cookie-Attribut-Referenz

Attribut

Was es tut	Blockiert den Zugriff von JavaScript auf das Cookie	Standard	Empfehlung
HttpOnly	Nicht gesetzt	Immer gesetzt für Authentifizierungs-Cookies	HTTPS-Übertragung
Secure	Immer gesetzt in Produktion	Immer gesetzt für Authentifizierungs-Cookies	Steuerung der Übertragung in Quer-Website-Anfragen
SameSite	Lax (moderne Browser)	Lax für Sitzungscookies; None + Secure für Drittanbieter	Setzt das Hostnamensbereich
Domain	Nur aktueller Host	Verlassen Sie es, wenn über mehrere Unterdomainen zugriff benötigt wird	Setzt den Pfadbereich
Path	Bleiben Sie auf /, es sei denn, Sie wollen Admin-Tokens isolieren	/	Sekunden bis zum Ablauf
Max-Age	Sitzungscookie	Bevorzugt gegenüber Expires	Absoluter Ablaufdatum
Expires	Verwenden Sie Max-Age stattdessen	Bevorzugt gegenüber Expires	Einstellen von Cookies im Code

Node.js (Express)

Python (FastAPI)

app.post('/login', (req, res) => {
  // ... verify credentials ...

  res.cookie('sessionId', token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 86400 * 1000, // milliseconds in Express
    path: '/',
  });

  res.json({ ok: true });
});

Manuelle Parsee von Cookie-Header

from fastapi import FastAPI, Response

app = FastAPI()

@app.post("/login")
def login(response: Response):
    # ... verify credentials ...

    response.set_cookie(
        key="sessionId",
        value=token,
        httponly=True,
        secure=True,
        samesite="lax",
        max_age=86400,
        path="/",
    )
    return {"ok": True}

Der Header, den der Server erhält, enthält nur

Der Cookie Paare, getrennt durch name=value Um ihn manuell zu parsen: teilen Sie durch ; :

Cookie: sessionId=abc123; theme=dark; lang=en

(Semicolon + Space), dann teilen Sie jedes Paar durch das erste ; nur. Wichtige Ausnahmefälle zu wissen: Werte können enthalten sein = (Base64-Zeichenketten, die häufig vorkommen) – teilen Sie immer nur durch das erste

• nur = Cookie-Namen sind fallensensitiv = Leerzeichen um den Trenner können variieren – trimmen Sie beide Seiten vorsichtig
• Stattdessen schreiben Sie das Split-Logik selbst, verwenden Sie das
• um jeden

Header zu decodieren und jedes Wert zu überprüfen, oder das Cookie Builder IO Tools Cookie Builder Cookie um einen gültigen Header mit den richtigen Attributen zu erstellen. Cookies und CSRF Set-Cookie Cross-Site Request Forgery nutzt die Tatsache, dass Browser automatisch Cookies bei Anfragen an einen Domain einfügen, selbst wenn diese von einer anderen Website initiiert werden. Eine bösartige Seite an

kann ein Formular an

senden, und wenn der Benutzer angemeldet ist, sendet der Browser ihren Sitzungscookie mit der gefälschten Anfrage. evil.com defeiten die meisten CSRF-Vektoren, weil Quer-Website-POST-Anfragen – das typische Angriffsmuster – den Cookie nicht enthalten. bank.com/transferist noch gründlicher, kann aber die Benutzererfahrung beeinträchtigen.

SameSite=Lax CSRF-Tokens bleiben gültig als zusätzliche Verteidigung, besonders bei hochwichtigen Operationen und wenn SameSite=Strict für den Drittanbieterkontext erforderlich ist. Die beiden Verteidigungen ergänzen sich.

HTTP-Cookies: Wie man sie richtig erstellt und parsiert SameSite=None HTTP-Cookies: Wie man sie richtig erstellt und parsiert 1

Das könnte Ihnen auch gefallen