CSRF-Schutz in React- und API-Setups

Cross-Site Request Forgery (CSRF) ist ein Angriff, bei dem eine bösartige Website den Browser des Benutzers dazu bringt, eine authentifizierte Anfrage an Ihre API zu senden. Da der Browser Cookies automatisch an Anfragen anhängt, kann der Server nicht zwischen einer legitimen Anfrage Ihrer Anwendung und einer gefälschten Anfrage von der Website des Angreifers unterscheiden.

Cookies sind die Hauptursache der CSRF-Schwachstelle. Wenn ein Benutzer bei Ihrer Anwendung angemeldet ist, wird sein Sitzungs-Cookie im Browser gespeichert. Wenn er die Seite des Angreifers besucht, kann der Angreifer eine Formularübermittlung oder Fetch-Anfrage an Ihre API auslösen. Der Browser fügt das Sitzungs-Cookie automatisch hinzu und authentifiziert dadurch die bösartige Anfrage.

Das SameSite-Cookie-Attribut legt fest, wann Browser Cookies in websiteübergreifende Anfragen einbeziehen. Es hat drei Werte: Lax (der Standard in modernen Browsern – blockiert websiteübergreifende POST-Anfragen, erlaubt aber GET), Strict (blockiert alle websiteübergreifenden Anfragen einschließlich GET-Navigationen) und None (erlaubt websiteübergreifende Anfragen, erfordert aber das HTTPS-Secure-Flag).

SameSite=Lax blockiert websiteübergreifende POST-, PUT-, DELETE- und PATCH-Anfragen – also die Methoden, die für Mutationen verwendet werden. Wenn Ihre API GET ausschließlich zum Lesen und POST für alle Mutationen verwendet, verhindert SameSite=Lax CSRF für SPAs in modernen Browsern effektiv. Dies ist die grundlegende Schutzmaßnahme, auf die sich die meisten Anwendungen heute verlassen.

Das Double-Submit-Cookie-Muster ist eine CSRF-Schutzmaßnahme, bei der der Server ein zufälliges CSRF-Token in einem nicht-HttpOnly-Cookie setzt. Der Client liest den Wert dieses Cookies und fügt ihn als benutzerdefinierten Request-Header hinzu (z. B. X-CSRF-Token). Der Server prüft, ob der Wert des Headers mit dem Cookie-Wert übereinstimmt. Ein Angreifer kann das Cookie nicht von einer anderen Origin auslesen und daher nicht den korrekten Header setzen.

Das Synchronizer-Token-Muster erzeugt für jede Benutzersitzung serverseitig ein eindeutiges CSRF-Token. Bei HTML-Formularen wird das Token in ein verborgenes Feld eingebettet. Bei SPA-API-Aufrufen wird das Token über einen Endpunkt oder ein Meta-Tag bereitgestellt und in einem benutzerdefinierten Header gesendet. Der Server validiert das Token bei jeder statusändernden Anfrage.

Eine React-SPA, die ihr JWT im Arbeitsspeicher oder in localStorage speichert und es in einem Authorization: Bearer-Header sendet, ist nicht anfällig für klassisches CSRF. CSRF-Angriffe nutzen die cookiebasierte Authentifizierung aus – die Seite eines Angreifers kann aufgrund von CORS-Beschränkungen keine benutzerdefinierten Header bei websiteübergreifenden Anfragen setzen und daher den Authorization-Header nicht fälschen.

Einfache websiteübergreifende Anfragen (Formular-POST, Bildabruf) erlauben keine benutzerdefinierten Header. Nur Anfragen, die ein CORS-Preflight durchlaufen, können benutzerdefinierte Header enthalten – und für Preflight-Anfragen ist eine ausdrückliche Genehmigung durch den Server erforderlich. Eine API, die für alle Mutationen einen benutzerdefinierten Header wie X-Requested-With: XMLHttpRequest verlangt, ist grundsätzlich vor einfachen CSRF-Angriffen geschützt.

CORS steuert, welche Origins die Antwort einer Cross-Origin-Anfrage lesen dürfen. Bei CSRF geht es darum, von welchen Origins zustandsändernde Anfragen gesendet werden können. Die Konfiguration von CORS zur Einschränkung von Origins verhindert CSRF nicht – der Browser sendet die Anfrage und das Cookie weiterhin; CORS steuert nur, ob die Antwort für JavaScript sichtbar ist. Ein CSRF-Angriff muss die Antwort nicht lesen können.

Konfigurieren Sie Session-Cookies mit: HttpOnly: true (verhindert, dass JavaScript das Cookie liest, und blockiert so den auf XSS basierenden Token-Diebstahl), Secure: true (wird nur über HTTPS gesendet), SameSite: Lax oder Strict (verhindert CSRF) sowie einem geeigneten Max-Age oder Ablaufzeitpunkt. Diese vier Attribute härten die Session-Verwaltung erheblich ab.

Next.js verwendet im App Router Server Actions, die POST-Anfragen sind. Next.js implementiert CSRF-Schutz, indem der Origin-Header mit dem Host abgeglichen wird – Anfragen von unerwarteten Origins werden abgelehnt. Diese integrierte Prüfung bietet zusammen mit SameSite=Lax-Session-Cookies einen soliden CSRF-Schutz für Mutationen auf Basis von Server Actions.

Welcher SameSite-Cookie-Wert blockiert Cross-Site-POST-Anfragen, erlaubt aber Cross-Site-GET-Navigationen?

CSRF nutzt cookiebasierte Authentifizierung aus, indem der Browser dazu gebracht wird, authentifizierte Cross-Site-Anfragen zu senden. SameSite=Lax ist die grundlegende Schutzmaßnahme für moderne Browser. Die Muster Double Submit Cookie und Synchronizer Token bieten zusätzlichen Schutz. React-SPAs, die JWT in Authorization-Headern verwenden, sind von Natur aus gegen CSRF geschützt. Benutzerdefinierte erforderliche Header und CORS-Preflight-Anfragen mindern CSRF ebenfalls. Kombinieren Sie in Session-Cookies immer HttpOnly + Secure + SameSite.