CSRF Schutz im Web – Formulare und APIs richtig absichern

Ein Klick auf einen harmlosen Link, und plötzlich wird im eigenen Konto etwas geändert? Genau dieses Muster steckt oft hinter CSRF. Der Angriff nutzt aus, dass Browser bei einer Anfrage automatisch Cookies mitsenden. Wenn eine Anwendung nicht prüft, ob eine Aktion wirklich vom eigenen Frontend kommt, können Fremdseiten ungewollt Aktionen auslösen.

Der Fokus liegt hier auf pragmatischen Maßnahmen, die in der Webentwicklung zuverlässig funktionieren: verständlich erklärt, ohne Mythen, mit klaren Regeln für Formulare und APIs.

CSRF verstehen: Was genau passiert bei Cross-Site Request Forgery?

CSRF (Cross-Site Request Forgery, auf Deutsch grob „seitenübergreifende Anfragefälschung“) bedeutet: Eine fremde Website bringt den Browser einer eingeloggten Person dazu, eine Aktion auf einer anderen Website auszuführen. Die Person ist dabei im Zielsystem bereits authentifiziert, typischerweise über ein Session-Cookie.

Warum Cookies das Problem (und gleichzeitig nötig) sind

Cookies sind für Logins praktisch: Der Browser sendet sie automatisch an die Domain, zu der die Anfrage geht. Genau das wird ausgenutzt. Wenn eine Anwendung eine gefährliche Aktion nur daran festmacht, dass „ein gültiges Cookie“ mitkommt, fehlt eine zweite Bestätigung, dass die Aktion wirklich aus der eigenen App stammt.

Ein alltagsnahes Beispiel

Angenommen, im Nutzerkonto gibt es einen Endpunkt, der die E-Mail-Adresse ändert. Wenn dieser Endpunkt per POST erreichbar ist und keine zusätzliche Prüfung macht, kann eine Fremdseite ein Formular im Hintergrund absenden. Der Browser hängt das Session-Cookie automatisch dran. Ergebnis: Die E-Mail wird geändert, obwohl niemand im eigenen Frontend geklickt hat.

Wann CSRF besonders gefährlich ist

• Wenn Aktionen den Zustand ändern (z. B. Passwort, E-Mail, Lieferadresse, Zahlungsdaten).
• Wenn Admin-Bereiche erreichbar sind und Admins oft eingeloggt bleiben.
• Wenn eine Anwendung „bequeme“ GET-Links für Änderungen anbietet (z. B. /delete?id=123).

Bin ich betroffen? Der schnelle Check für Formulare und Endpunkte

CSRF ist kein „Framework-Problem“, sondern ein Architektur- und Prüfproblem. Die folgenden Fragen helfen bei der Einordnung:

Die wichtigsten Kriterien

• Nutzt die Anwendung Cookie-basierte Sessions? Dann ist CSRF grundsätzlich ein Thema.
• Gibt es zustandsändernde Endpunkte (POST/PUT/PATCH/DELETE)? Diese sind besonders relevant.
• Werden Anfragen nur über „eingeloggt ja/nein“ freigegeben? Dann fehlt sehr wahrscheinlich eine CSRF-Prüfung.

Typischer Irrtum: „Wir haben doch CORS“

CORS regelt, ob ein Browser JavaScript-Antworten von einer fremden Origin lesen darf. CSRF braucht aber häufig gar kein Lesen der Antwort, sondern nur das Auslösen der Anfrage. Deshalb ist CORS allein kein CSRF-Schutz. Wer das sauber trennen will, findet praktische Hintergründe in CORS verstehen – typische Fehler lösen und sicher konfigurieren.

CSRF Tokens richtig einsetzen (klassische Web-Formulare)

Der Standard-Schutz für servergerenderte Formulare ist ein CSRF-Token. Das ist ein zufälliger Wert, den der Server pro Session (oder pro Formular) erzeugt und im Formular als Hidden-Feld mitsendet. Beim Absenden prüft der Server: Kommt das Token korrekt zurück? Wenn nicht, wird die Aktion abgelehnt.

Was ein gutes Token ausmacht

• Zufällig und nicht erratbar (kein Timestamp, keine fortlaufende Nummer).
• Gebunden an die Session oder den Login-Kontext.
• Serverseitig validiert, nicht nur im Frontend „geprüft“.

Token-Check auf dem Server: worauf es ankommt

Wichtig ist eine konsistente Regel: Jede zustandsändernde Route muss den Token-Check haben. Ein häufiger Fehler ist, dass nur „wichtige“ Formulare geschützt werden, während kleinere Admin- oder Profilfunktionen vergessen werden.

Typische Token-Fallen

• Token wird in HTML eingebaut, aber auf dem Server nicht validiert.
• Token wird in JavaScript zwischengespeichert und nie erneuert (Problem bei langen Sessions).
• Mehrere Tabs/Formulare: Token-Strategie führt zu unnötigen Fehlermeldungen, wenn Token zu aggressiv rotiert.

SameSite Cookies: einfacher Basisschutz, aber nicht immer genug

Moderne Browser unterstützen das Cookie-Attribut SameSite. Es steuert, ob ein Cookie bei „Cross-Site“-Anfragen mitgeschickt wird. Das ist ein hilfreicher Basisschutz, ersetzt aber nicht in allen Setups den Token.

SameSite kurz erklärt (ohne Browser-Details)

• SameSite=Lax: Cookie wird bei vielen Cross-Site-Szenarien nicht mitgesendet; oft ein guter Standard für klassische Webapps.
• SameSite=Strict: sehr restriktiv; kann Logins/Flows stören, wenn Nutzer aus externen Quellen kommen.
• SameSite=None: Cookie darf auch Cross-Site gesendet werden, erfordert zusätzlich „Secure“ (nur über HTTPS). Wird z. B. bei eingebetteten Inhalten oder komplexen Auth-Flows gebraucht.

Wann SameSite nicht reicht

Wenn Cookies absichtlich Cross-Site gesendet werden müssen (z. B. SameSite=None), braucht es wieder eine zusätzliche Absicherung. Auch bei älteren Clients oder Sonderfällen ist ein Token-Check robuster.

CSRF Schutz für JSON-APIs: Cookie-Session vs. Bearer Token

APIs sind häufig der Ort, an dem CSRF „aus Versehen“ wieder auftaucht: Das Frontend nutzt Fetch/AJAX, die Auth läuft über Cookies, und plötzlich sind API-Calls genauso angreifbar wie ein HTML-Formular.

Faustregel: Cookie-Auth braucht CSRF-Schutz

Wenn eine API über Cookies authentifiziert (Session-Cookie), dann gelten die gleichen Grundregeln wie bei Formularen: zustandsändernde Requests brauchen eine zusätzliche Bestätigung. Das kann ein CSRF-Token sein, das z. B. als Custom Header mitgeschickt wird.

Alternative: Authorization Header statt Cookie

Wird die Authentifizierung über einen Authorization Header (z. B. „Bearer …“) umgesetzt und das Token wird nicht automatisch vom Browser an Fremdseiten gesendet, sinkt das CSRF-Risiko deutlich. Trotzdem bleiben andere Risiken (z. B. XSS, Token-Diebstahl) relevant.

Pragmatisches Pattern: Double Submit Cookie

Ein verbreitetes Pattern ist „Double Submit“: Der Server setzt ein Cookie mit einem zufälligen Wert und das Frontend sendet denselben Wert zusätzlich in einem Header. Der Server prüft: Stimmt beides überein? Das hilft, weil Fremdseiten typischerweise nicht an den Wert kommen, um ihn korrekt im Header zu setzen. Wichtig bleibt: Der Server muss konsequent validieren.

So geht’s: CSRF-Schutz in bestehende Projekte einbauen

• Alle zustandsändernden Endpunkte sammeln (POST/PUT/PATCH/DELETE) und priorisieren (zuerst Admin/Profile/Payments).
• Wenn Cookie-Session genutzt wird: Token-Mechanismus wählen (Hidden Field bei Formularen, Header bei Fetch-Requests).
• SameSite für Session-Cookies sinnvoll setzen und testen (Login, Checkout, externe Redirects).
• GET-Requests niemals für Änderungen verwenden; Änderungen gehören in POST/PUT/PATCH/DELETE.
• Serverseitig Fehler klar behandeln: bei fehlendem/ungültigem Token eine eindeutige Antwort liefern und nichts verändern.

Mini-Checkliste: typische CSRF-Fehler im Alltag

• Änderungen über GET (z. B. „/unsubscribe?email=…“ ohne Schutz).
• API nutzt Cookies, aber es gibt keine Token-Prüfung.
• Nur einige Formulare geschützt, „kleine“ Endpunkte vergessen.
• Token wird clientseitig generiert (muss serverseitig kontrollierbar sein).
• Fehlermeldung bei Token-Problemen wird unterdrückt, wodurch Debugging schwer wird.

FAQ: häufige Fragen zu CSRF

Reicht es, nur POST zu erlauben?

Nein. CSRF kann auch POST-Requests auslösen (z. B. per verstecktem Formular). Entscheidend ist nicht die Methode, sondern die zusätzliche Prüfung, ob die Anfrage wirklich aus der eigenen Anwendung kommt.

Schützt HTTPS gegen CSRF?

HTTPS schützt die Verbindung (z. B. vor Mitlesen und Manipulation unterwegs). CSRF ist aber ein Logikproblem: Der Browser sendet bei HTTPS genauso Cookies mit, wenn die Domain stimmt. Deshalb bleibt CSRF ohne Token/SameSite ein Thema.

Was ist der Unterschied zu XSS?

XSS (Cross-Site Scripting) bedeutet: Angreifer-Code läuft in der eigenen Seite und kann dann echte, legitime Requests ausführen. CSRF kommt „von außen“ über den Browser. Gegen beide braucht es unterschiedliche Maßnahmen. Wer Sicherheitsregeln für Eingaben sauber umsetzen will, findet dazu passende Grundlagen in Input-Validierung im Backend – saubere Daten statt Sicherheitslücken.

Wie passt das zu JWT?

JWT kann auf verschiedene Arten gespeichert werden. Liegt es in einem Cookie, ist CSRF wieder relevant (wie bei Session-Cookies). Liegt es im Storage und wird als Bearer Token im Header gesendet, sinkt CSRF, dafür wird XSS kritischer. Für den praktischen Einstieg in sichere Token-Setups hilft JWT-Authentifizierung – sicher implementieren, einfach erklärt.

Welche Rolle spielt Content Security Policy?

CSRF und CSP sind unterschiedliche Baustellen. CSP hilft vor allem gegen XSS, was indirekt auch die Missbrauchsmöglichkeiten reduziert. Für eine verständliche Einführung siehe Content Security Policy (CSP) – Header sicher konfigurieren.

Vergleichsbox: Token vs. SameSite vs. Header-Auth