CSRF Token verstehen – Schutz für Formulare und Sessions

Ein Klick auf einen Link, eine eingeloggte Session im Hintergrund – und plötzlich wird im eigenen Account etwas geändert, ohne dass es beabsichtigt war. Genau hier setzt CSRF an: Angreifer nutzen aus, dass Browser Cookies automatisch mitschicken. Der Schutz ist kein Hexenwerk, aber er muss richtig in die Request-Flows eingebaut werden.

In diesem Artikel wird erklärt, was CSRF (Cross-Site Request Forgery) ist, warum CSRF Token wirken, wie sie in Formularen und APIs eingesetzt werden und welche Fallen im Alltag am häufigsten auftreten.

CSRF kurz erklärt: warum der Browser „zu hilfreich“ ist

CSRF bedeutet, dass ein fremdes Formular oder Skript den Browser dazu bringt, eine Anfrage an eine Website zu senden, bei der man eingeloggt ist. Der Browser hängt dabei automatisch die Session-Cookies an – und der Server glaubt, die Anfrage komme wirklich vom eingeloggten Nutzer.

Ein greifbares Beispiel aus dem Alltag

Angenommen, eine Webapp hat eine Route /account/email, die per POST die E-Mail-Adresse ändert. Ein Angreifer platziert auf einer anderen Seite ein unsichtbares Formular, das beim Laden automatisch abschickt. Wenn der Nutzer parallel bei der Webapp eingeloggt ist, wird das Cookie mitgeschickt – und die E-Mail könnte geändert werden.

Anzeige

Wichtig: CSRF ist kein „Datenklau“ über CORS

Bei CSRF geht es nicht darum, Antworten auszulesen. Der Angriff zielt auf Zustandsänderungen (z. B. „Adresse ändern“, „Passwort zurücksetzen“, „Zahlung auslösen“). Selbst wenn die Antwort wegen Same-Origin-Policy nicht lesbar ist, kann die Aktion trotzdem passieren.

So schützt ein CSRF Token: Idee und Mechanik

Ein CSRF Token ist ein zusätzlicher, schwer erratbarer Wert, den der Client mitsendet und den der Server prüft. Die Kernidee: Ein fremdes Formular kann zwar einen Request auslösen, aber es kann nicht zuverlässig an diesen Token kommen (weil er auf der echten Seite erzeugt und eingebunden wird).

Synchronizer Token Pattern (der Klassiker)

Bei diesem Ansatz wird der Token serverseitig erzeugt, in der Session gespeichert und in jedes Formular (oder in einen Request-Header) eingebettet. Beim Absenden vergleicht der Server: passt der mitgeschickte Token zur Session?

Double Submit Cookie (häufig bei APIs)

Hier wird ein Token als Cookie gesetzt und zusätzlich in einem Header oder Feld mitgeschickt. Der Server vergleicht beide Werte. Vorteil: nicht zwingend Session-State nötig. Nachteil: Das Modell muss sauber mit Cookie-Attributen und XSS-Risiken zusammenspielen (XSS bedeutet: JavaScript wurde eingeschleust und läuft auf der Seite).

Wo CSRF Schutz nötig ist – und wo nicht

CSRF betrifft vor allem Requests, die etwas ändern: POST, PUT, PATCH, DELETE. Für reine Lesezugriffe (GET) sollte ohnehin keine Zustandsänderung passieren. Wenn eine Anwendung trotzdem Änderungen per GET erlaubt (z. B. „/delete?id=…“), ist das ein Design-Problem und macht CSRF praktisch unvermeidbar.

Formulare in klassischen Server-Rendered Apps

Typisch: Login-Session per Cookie, Formulare senden POST. Das ist der ideale Einsatzbereich für CSRF Token direkt im HTML-Formular. Der Token gehört dabei zu jeder Session und sollte regelmäßig erneuert werden (z. B. beim Login oder periodisch).

Single-Page-Apps und JSON-APIs

Bei SPAs gibt es zwei verbreitete Authentifizierungsmodelle:

• Session-Cookies: Dann gilt CSRF weiterhin. Token gehören meist in einen Header (z. B. X-CSRF-Token), den die SPA aus einem initialen HTML-Response oder einem dedizierten Endpoint bezieht.

• Token im Authorization-Header (z. B. Bearer Token): Dann ist CSRF in der Regel kein Thema, weil fremde Seiten diesen Header nicht einfach mitsenden können. Dafür wird XSS umso wichtiger.

SameSite Cookies: guter Basisschutz, aber kein Allheilmittel

SameSite Cookies steuern, ob Cookies bei Cross-Site-Requests mitgeschickt werden. Das hilft direkt gegen viele CSRF-Fälle. Trotzdem sollte SameSite nicht als alleiniger Schutz betrachtet werden, weil:

Anzeige

• es Anwendungsfälle mit Cross-Site-Nutzung gibt (z. B. externe Payment-Flows, SSO, Subdomains), die Ausnahmen erfordern,

• Fehlkonfigurationen schnell passieren (z. B. unklare Subdomain-Strategie),

• ein Token im Request eine explizite, serverseitig prüfbare Sicherheitsschicht bleibt.

Pragmatische Entscheidungshilfe (verschachtelt)

• Werden Zustandsänderungen über Cookies authentifiziert?

  • Ja: CSRF-Schutz einplanen (Token oder robuste SameSite-Strategie, besser beides).

  • Nein, nur Authorization-Header: Fokus auf XSS-Schutz, Token-Lifecycle, sichere Speicherung.

• Gibt es Cross-Site-Flows (SSO, Payment, externe Widgets)?

  • Ja: Token-Strategie bevorzugen, SameSite bewusst konfigurieren.

  • Nein: SameSite kann viel abfangen, Token bleibt als zusätzliche Absicherung sinnvoll.

Typische Fehler bei CSRF Token in der Praxis

Viele CSRF-Lücken entstehen nicht durch fehlende Theorie, sondern durch kleine Details in Templates, Caching oder durch „Ausnahmen“, die später vergessen werden.

Token wird nicht pro Session gebunden

Ein Token muss an einen Kontext gekoppelt sein (meist Session). Wenn ein globaler Token für alle Nutzer gilt, ist er kein Schutz mehr, weil er leicht wiederverwendet werden kann.

Token fehlt bei einzelnen Endpoints

Häufig werden manche Routen „vergessen“: Admin-Aktionen, API-Endpunkte, oder Sonderfälle wie „Einstellungen speichern“. Hier helfen zentrale Middleware-Checks und klare Regeln: jede zustandsändernde Route braucht Schutz.

Token wird durch Caching kaputt gemacht

Wenn HTML-Seiten mit eingebettetem Token gecacht werden (Server-Cache oder Reverse Proxy), kann ein Nutzer den Token eines anderen bekommen. Das führt entweder zu Fehlern oder – im schlimmsten Fall – zu Sicherheitsproblemen. Lösung: Token nicht in öffentlich cachbare Responses einbetten oder Cache-Regeln sauber setzen.

Nur auf Referer/Origin geprüft

Origin- oder Referer-Checks können eine Zusatzprüfung sein, aber sie sind nicht so robust wie ein Token: Header können fehlen (z. B. durch Privacy-Einstellungen) und Sonderfälle machen den Betrieb fehleranfällig. Ein Token-Check ist die stabilere Grundlage.

Kurze Schritte, die in fast jeder Webapp funktionieren

• Für alle zustandsändernden Requests CSRF-Schutz aktivieren (nicht nur für „wichtige“).

• Serverseitig Token erzeugen, pro Session speichern und in Formularen als Hidden Field ausgeben.

• Für JavaScript-Requests Token über einen Header mitsenden und serverseitig gleich prüfen.

• SameSite-Cookies bewusst setzen und testen, besonders wenn Subdomains oder SSO im Spiel sind.

• GET-Requests dürfen keine Änderungen auslösen; problematische Routen umstellen.

Vergleich: Token-Ansatz vs. SameSite-Ansatz

Wie das mit anderen Sicherheitsmaßnahmen zusammenhängt

CSRF ist nur ein Teil. In der Praxis ergänzen sich Maßnahmen:

Anzeige

• XSS-Schutz: Wenn JavaScript eingeschleust werden kann, lassen sich Token oft auslesen oder Requests im Namen des Nutzers ausführen.

• Saubere Cookie-Strategie: Secure (nur HTTPS), HttpOnly (nicht per JS lesbar), SameSite passend zum Flow.

• Klare API-Regeln: State Changes nur über POST/PUT/PATCH/DELETE, konsistente Auth-Mechanik.

Vertiefend passt dazu auch der Artikel HTTP Cookies verstehen: Session, SameSite und Sicherheit sowie HTTP Security Headers – Website-Schutz ohne Overkill.

Häufige Fragen aus Projekten: Debugging und Tests

Warum klappt der Request im Browser, aber nicht im Test?

Integrationstests senden oft keine Cookies oder vergessen den Token-Header. Sinnvoll ist ein Helper, der zuerst die Seite lädt (Token extrahiert) und dann den POST inklusive Session ausführt. So testet es sich näher an der Realität.

Warum gibt es nur bei manchen Nutzern CSRF-Fehler?

Typisch sind mehrere Tabs, parallele Logins oder Token-Rotation ohne Übergangsphase. Wenn Token bei jedem Request neu generiert werden, werden offene Formulare in anderen Tabs sofort ungültig. Besser: Token seltener rotieren (z. B. pro Session) oder eine kurze Übergangslogik erlauben.

Welche Statuscodes sind sinnvoll bei fehlendem Token?

Bei klassischen Formularen ist ein Redirect mit Fehlermeldung üblich. Bei JSON-APIs passt ein 403 (Forbidden). Wichtig ist eine klare, nicht zu „plaudernde“ Fehlermeldung und ein konsistentes Verhalten.

Wer ohnehin an API-Fehlerbildern arbeitet, kann zusätzlich HTTP Statuscodes verstehen – Fehler sauber behandeln lesen.

Anzeige