Frontend Academy · Lektion

CSRF: SameSite-Cookies und Tokens

Verstehen Sie, wie Cross-Site Request Forgery Cookies ausnutzt, verhindern Sie dies mit SameSite=Strict/Lax und fügen Sie zum zusätzlichen Schutz Synchronizer-Tokens hinzu.

CSRF: SameSite-Cookies und Tokens ist eine kostenlose Frontend Academy-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Frontend Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Frontend Academy-Kurs umfasst insgesamt 4 Lektionen.

Was ist CSRF?

Cross-Site Request Forgery: Ein Angreifer bringt den Browser eines authentifizierten Benutzers dazu, eine Anfrage an Ihre Website zu senden. Der Browser hängt die Cookies des Benutzers an — der Server hält die Anfrage für eine legitime Anfrage des Benutzers.

Klassischer CSRF-Angriff

Der Benutzer ist bei bank.com angemeldet. Er besucht evil.com. evil.com sendet ein verstecktes Formular an bank.com/transfer, das die Kontonummer des Angreifers enthält. Der Browser sendet das Sitzungs-Cookie von bank.com automatisch mit. Der Server überweist das Geld.

Das Vertrauensproblem

CSRF funktioniert, weil Browser Cookies automatisch an Cross-Origin-Anfragen anhängen. Ohne zusätzlichen Schutz kann der Server nicht erkennen, dass die Anfrage von einer bösartigen Website stammt.

SameSite-Cookies — die moderne Lösung

Das Cookie-Attribut SameSite steuert, wann Cookies bei Cross-Origin-Anfragen gesendet werden. Strict: wird niemals Cross-Origin gesendet. Lax (Standard in Chrome): wird nur bei einer Top-Level-GET-Navigation gesendet. None: wird immer gesendet (muss außerdem Secure sein).

Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax

SameSite=Lax als Standard

Chrome setzt alle Cookies standardmäßig auf Lax, wenn kein SameSite angegeben ist. Dadurch wird der Großteil von CSRF blockiert — trotzdem sollten Sie den Wert immer ausdrücklich festlegen.

SameSite=Strict für maximale Sicherheit

Verwenden Sie Strict für besonders sensible Cookies (Admin-Sitzungen, Banktransaktionen). Nachteil: Wenn der Benutzer über einen Link von einer anderen Website kommt, scheint er abgemeldet zu sein.

CSRF-Tokens (Synchronisierer-Muster)

Für die Unterstützung älterer Browser oder zusätzliche Sicherheit können Sie CSRF-Tokens verwenden. Der Server erzeugt ein zufälliges Token, bettet es in die Seite ein und verlangt es bei jeder Anfrage, die den Zustand ändert.

// Server embeds token in HTML or sets it as a non-HttpOnly cookie:
<meta name="csrf-token" content="a1b2c3...">

// Client reads token and sends in header:
const token = document.querySelector('meta[name=csrf-token]').content;
fetch('/transfer', {
  method: 'POST',
  headers: { 'X-CSRF-Token': token },
  body: JSON.stringify({ amount: 100 })
});

// Server verifies the X-CSRF-Token header matches the user's session

Double-Submit-Cookie

Der Server setzt ein CSRF-Cookie (nicht HttpOnly, damit JavaScript es lesen kann). Der Client liest es aus und sendet den Wert in einem Header. Der Server prüft, ob Cookie und Header übereinstimmen. Ein Angreifer kann das Cookie nicht Cross-Origin lesen und daher den Header nicht nachbilden.

Warum das funktioniert

Die Website evil.com des Angreifers kann aufgrund der Same-Origin-Policy keine Cookies von bank.com lesen. Daher kann sie den Header X-CSRF-Token nicht setzen. Die Anfrage besteht die Token-Prüfung auf dem Server nicht.

CSRF in SPAs mit Bearer-Tokens

Wenn Sie sich mit Authorization: Bearer <jwt> authentifizieren und das Token im Speicher (nicht in einem Cookie) speichern, ist CSRF nicht relevant — Browser senden Header nicht automatisch. Der Nachteil: Die Anwendung ist anfälliger für XSS, da für JavaScript zugängliche Tokens gestohlen werden können.

Der Trick mit benutzerdefinierten Headern

Bei APIs, die nur JSON mit einem benutzerdefinierten Header akzeptieren (z. B. X-Requested-With), senden Browser zunächst eine OPTIONS-Preflight-Anfrage — und fügen dieser keine Cookies hinzu. Dadurch wird CSRF über einfache Formulare effektiv blockiert.

Idempotente und zustandsändernde Endpunkte

CSRF betrifft hauptsächlich Anfragen, die den Zustand ändern (POST, PUT, DELETE). GET-Endpunkte sollten idempotent sein — also keine Seiteneffekte haben —, damit ein gefälschter GET keinen Schaden anrichten kann.

Kurztest

Welcher SameSite-Cookie-Wert verhindert in modernen Browsern standardmäßig, dass Cookies bei den meisten Cross-Site-Anfragen gesendet werden?

Zusammenfassung: CSRF-Vermeidung

Setzen Sie SameSite=Lax (oder Strict) für Sitzungscookies — dadurch wird der Großteil von CSRF blockiert. Fügen Sie HttpOnly und Secure hinzu. Verwenden Sie für zusätzlichen Schutz CSRF-Tokens (Synchronisierer-Muster oder Double-Submit-Cookie). Bearer-Tokens in Headern vermeiden CSRF, erhöhen aber das XSS-Risiko. Der Trick mit benutzerdefinierten Headern erzwingt eine Preflight-Anfrage. Sorgen Sie dafür, dass GET-Anfragen idempotent sind.

Häufig gestellte Fragen

Ist die Lektion „CSRF: SameSite-Cookies und Tokens“ kostenlos?

Ja — der vollständige Text von „CSRF: SameSite-Cookies und Tokens“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Frontend Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Frontend Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „CSRF: SameSite-Cookies und Tokens“?

Verstehen Sie, wie Cross-Site Request Forgery Cookies ausnutzt, verhindern Sie dies mit SameSite=Strict/Lax und fügen Sie zum zusätzlichen Schutz Synchronizer-Tokens hinzu. Du übst Frontend Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Frontend Academy zu starten?

Keine Vorkenntnisse erforderlich. Frontend Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „CSRF: SameSite-Cookies und Tokens“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Frontend Academy-Lektion Code schreiben und ausführen?

Ja. Jede Frontend Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Frontend Academy