Skip to content
NeuralSkills
Sicherheit

CSRF-Schutz

Cross-Site-Request-Forgery-Schutzmuster implementieren — Tokens, SameSite-Cookies und Origin-Validierung fuer Webanwendungen.

Fortgeschritten Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Cross-Site Request Forgery bringt authentifizierte Nutzer dazu, ohne ihr Wissen boesartige Anfragen abzusenden. Die Seite eines Angreifers kann eine Bankueberweisung ausloesen, eine E-Mail-Adresse aendern oder ein Konto loeschen — alles unter Verwendung des gueltigen Session-Cookies des Opfers. Selbst moderne SPAs mit JWT-Tokens koennen verwundbar sein, wenn Tokens in Cookies ohne korrekte SameSite-Attribute oder CSRF-Token-Validierung gespeichert werden.

Der Prompt

Du bist ein Web-Sicherheitsingenieur mit Spezialisierung auf CSRF-Praevention. Analysiere den CSRF-Schutz meiner Anwendung und identifiziere Luecken.

FRAMEWORK: [z.B. Express, Django, Rails, Next.js, Laravel]
AUTH-METHODE: [z.B. Session-Cookies, JWT in Cookies, JWT in localStorage]
API-STIL: [z.B. REST mit Formularen, REST mit JSON, GraphQL]

CODE:
[Auth-Middleware, Formular-Handling, Cookie-Konfiguration und zustandsaendernde Endpunkte einfuegen]

Diese CSRF-Verteidigungsschichten bewerten:
1. **Token-basierter Schutz**: Synchronizer-Tokens, Double-Submit-Cookies, signierte Double-Submit
2. **SameSite-Cookie-Attribut**: Strict, Lax oder None — und Implikationen
3. **Origin/Referer-Validierung**: Request-Origin gegen erlaubte Domains pruefen
4. **Custom Headers**: X-Requested-With oder aehnliches fuer AJAX-Requests voraussetzen
5. **Content-Type-Einschraenkungen**: Nicht-JSON-Content-Types an API-Endpunkten ablehnen

Fuer jeden gefundenen zustandsaendernden Endpunkt:
- Ist er gegen CSRF geschuetzt? (Ja/Nein/Teilweise)
- Welches Angriffsszenario wuerde die Luecke ausnutzen?
- Empfohlene Loesung mit Codebeispiel

Eine vollstaendige CSRF-Schutz-Implementierung fuer mein spezifisches Framework bereitstellen.

Beispielausgabe

## CSRF-Analyse: 2 ungeschuetzte Endpunkte

### VERWUNDBAR: POST /api/account/email
Kein CSRF-Token erforderlich. Cookie ist SameSite=Lax, aber Endpunkt akzeptiert formularcodierte Daten.
Angriff: Angreiferseite sendet ein verstecktes Formular per POST und aendert die E-Mail des Opfers.
Loesung: csurf-Middleware hinzufuegen und Token bei allen POST/PUT/DELETE-Routen validieren.

### GESCHUETZT: POST /api/transfer (Token validiert)
SameSite=Strict Cookie + CSRF-Token im X-CSRF-Token-Header. Korrekt verteidigt.

Wann verwenden

CSRF-Schutz auditieren, wenn neue zustandsaendernde Endpunkte hinzugefuegt, die Authentifizierungsstrategie geaendert oder Cookie-Einstellungen modifiziert werden. Unverzichtbar bei Sicherheitsreviews von E-Commerce-Checkout-Flows, Kontoverwaltungsseiten und Endpunkten, die Daten aendern. Nach dem Wechsel von serverseitig gerenderten Formularen zu SPA-Architektur ausfuehren.

Profi-Tipps

  • SameSite allein reicht nicht — SameSite=Lax erlaubt weiterhin Top-Level-GET-Navigationen, daher GET-Endpunkte mit Seiteneffekten schuetzen.
  • Mit Cross-Origin-Formularen testen — eine einfache HTML-Seite auf einer anderen Domain erstellen, die Formulare an die eigene API sendet, um den Schutz zu verifizieren.
  • Logout nicht vergessen — CSRF auf Logout-Endpunkten ermoeglicht Login-CSRF-Angriffe, bei denen der Angreifer das Opfer in das Konto des Angreifers einloggt.
  • GraphQL braucht auch CSRF — Mutation-Endpunkte ueber POST sind genauso verwundbar wie REST-Endpunkte, wenn Cookies die Authentifizierung tragen.