Schützt das Aktivieren von CORS vor CSRF?

Dies ist eine Falle auf Senior-Niveau, weil die beiden Akronyme verwandt klingen und beide mit „Cross-Origin“ zu tun haben. Viele Ingenieure nehmen an, CORS sei eine Sicherheitsmauer. In Wirklichkeit lockert CORS eine Mauer, und es adressiert ein anderes Problem als CSRF.

Was CORS tatsächlich macht

Die Same-Origin-Policy hindert JavaScript auf Seite A normalerweise daran, die Antwort einer Anfrage an Seite B zu lesen. CORS ist der Mechanismus, mit dem Seite B sich bereit erklären kann, Seite A das Lesen ihrer Antworten zu erlauben. CORS geht es also um das Lockern von Leserestriktionen, nicht um das Blockieren von Anfragen. Eine restriktive CORS-Konfiguration bedeutet lediglich, dass andere Origins Ihre Antworten nicht lesen können — sie tut nichts, um zu verhindern, dass eine Anfrage gesendet wird.

Warum CSRF das egal ist

Ein CSRF-Angriff reitet auf der bereits authentifizierten Sitzung des Opfers. Die Seite des Angreifers löst eine zustandsändernde Anfrage aus (Geld überweisen, E-Mail ändern), und der Browser hängt automatisch die Cookies des Opfers an. Der Angreifer muss die Antwort nie lesen — der Schaden entsteht durch den Seiteneffekt. Viele solcher Anfragen (ein einfacher Formular-POST, ein Bild-GET) sind „einfache Anfragen“, die nicht einmal einen CORS-Preflight auslösen. CORS, das nur das Lesen regelt, ist für den Angriff also irrelevant. Der Ablenker „stoppt GET, aber nicht POST“ versteht völlig falsch, wie das funktioniert.

Die echten Abwehrmechanismen

• Anti-CSRF-Tokens — ein unvorhersehbares Token pro Sitzung/pro Anfrage, das der Angreifer nicht erraten kann.
• SameSite-Cookies (Lax/Strict) — der Browser hält das Cookie bei seitenübergreifenden Anfragen zurück.
• Validierung von Origin/Referer an zustandsändernden Endpunkten.

Worauf Interviewer achten

Ein klares „Nein“, die Unterscheidung Lesen-versus-Senden und die richtigen Gegenmaßnahmen. CORS mit einer CSRF-Abwehr zu verwechseln ist ein häufiger und aufschlussreicher Fehler.