Browser-APIs mit Cookies: SameSite und CSRF richtig einsetzen

Was bei CSRF schiefgeht

Bei Cross-Site Request Forgery veranlasst ein fremder Kontext den Browser zu einer Anfrage, die der Server als Handlung des angemeldeten Benutzers behandelt. Der auslösende Kontext muss die Antwort nicht lesen können. Deshalb reicht „Unsere CORS-Regel lässt die fremde Website nicht lesen“ allein nicht als Nachweis.

Ein eigenes synthetisches Beispiel: Eine Kontoverwaltung nimmt eine Änderung der Benachrichtigungsadresse allein aufgrund des Sitzungscookies an. Fehlt die Prüfung, ob die Aktion aus dem vorgesehenen Anwendungskontext stammt, kann eine ungewollte Anfrage dieselbe Sitzung benutzen. Die konkrete Gefährdung hängt davon ab, welche Anfragen der Browser zulässt und welche Cookies er dabei mitsendet.

Die OWASP CSRF-Empfehlungen behandeln dafür sowohl tokenbasierte Schutzmechanismen als auch zusätzliche Kontextprüfungen. Sie sind Entwicklungsempfehlungen, keine Behauptung, dass jede Cookie-API auf dieselbe Weise angreifbar ist.

Same-Origin und Same-Site sind unterschiedliche Grenzen

CORS arbeitet mit Origins: Schema, Host und Port. SameSite-Cookies beziehen sich auf einen Sitekontext, bei üblichen Webadressen insbesondere Schema und registrierbare Domain. Zwei HTTPS-Subdomains können deshalb same-site, aber cross-origin sein.

Das ist relevant, wenn weitere Subdomains fremde Inhalte oder andere Mandanten beherbergen. SameSite=Strict macht nicht jede benachbarte Subdomain zu einem unvertrauenswürdigen Cross-Site-Kontext. Dokumentieren Sie deshalb, wer die gesamte betroffene Site kontrolliert, statt nur den API-Host zu betrachten. Die MDN-Cookiebeschreibung erläutert die SameSite-Werte.

Cookieattribute passend zur Sitzung wählen

Ein synthetischer Header für eine serverseitige Sitzung könnte so aussehen:

Set-Cookie: __Host-session=synthetic-session-value; Path=/; Secure; HttpOnly; SameSite=Lax

Der Wert ist ein Anschauungsmarker und kein verwendbarer Sitzungsschlüssel. Das Beispiel ist keine vollständige Sitzungskonfiguration. Die Attribute lösen verschiedene Teilaufgaben:

• Secure begrenzt die Übertragung auf den vorgesehenen sicheren Transport.
• HttpOnly verhindert das unmittelbare Lesen des Cookies durch JavaScript. Browsercode kann trotzdem Requests auslösen, bei denen das Cookie mitgesendet wird.
• SameSite begrenzt bestimmte siteübergreifende Sendekontexte. Lax und Strict haben unterschiedliche Auswirkungen auf legitime Navigationen und Anmeldeabläufe.
• Der Präfix __Host- verlangt in unterstützenden Browsern unter anderem Secure, Path=/ und kein Domain-Attribut; das begrenzt den Cookiebereich auf den setzenden Host.

Für benötigte Cross-Site-Cookies verlangt SameSite=None zusätzlich Secure. Browserrichtlinien können deren Verwendung trotzdem weiter einschränken. Wählen Sie None deshalb nicht als pauschale Reparatur eines Loginfehlers. Prüfen Sie zuerst, ob der tatsächliche Aufbau überhaupt cross-site ist. Die Details und Präfixgrenzen nennt MDN: Set-Cookie.

Einen vollständigen CSRF-Mechanismus verwenden

Prüfen Sie zuerst die vorhandene Frameworkfunktion: Welche Routen schützt sie, wann wird ihr Schutz ausgeführt, wie erhält der eigene Client den benötigten Wert und wie reagiert sie bei Fehlern? Übernehmen Sie nicht nur den Namen eines CSRF-Headers.

Bei einem sitzungsgebundenen Tokenverfahren erzeugt der Server einen nicht vorhersagbaren Wert und bindet ihn an den vorgesehenen Sitzungskontext. Der eigene Client übermittelt ihn bei geschützten Aktionen, häufig in einem Requestheader. Der Server prüft ihn zusätzlich zum Zugangscookie. Ein Token, das nur in einem automatisch gesendeten Cookie ankommt, liefert für sich nicht diese zusätzliche Bindung.

Es gibt auch signierte Double-Submit-Verfahren und für eng definierte AJAX-APIs Schutz über einen verpflichtenden eigenen Header mit strenger Originfreigabe. Deren Voraussetzungen unterscheiden sich. Wählen Sie die dokumentierte Variante Ihres Frameworks; ein naiver Vergleich zweier beliebig setzbarer Cookie-/Formularwerte ist kein universeller Ersatz. Die OWASP-Abschnitte zu Tokenmustern und API-Headern beschreiben diese Unterschiede.

Bei tokenbasiertem CSRF-Schutz gehört der Wert nicht in eine URL. Er kann dadurch in Verlauf oder Logs gelangen. Wird ein eigener Header verwendet, braucht ein Cross-Origin-Frontend die passende CORS-Freigabe für diesen Header. Das erlaubt weiterhin nur vertrauenswürdige Frontends; eine beliebige Originreflexion würde die Abgrenzung untergraben.

JSON, HTTP-Methoden und Kontextprüfungen zusammen betrachten

Ein Endpunkt, der ausschließlich einen korrekt ausgezeichneten JSON-Body akzeptiert und einen passenden eigenen Header verlangt, hat andere Browserbedingungen als ein Formularendpunkt. Daraus folgt aber nicht, dass „JSON“ als Wort CSRF verhindert. Nimmt derselbe Handler auch text/plain oder Formulardaten an, kann die angenommene Grenze entfallen. Prüfen Sie den tatsächlich akzeptierten Medientyp und alle kompatiblen Eingabepfade.

Zustandsänderungen gehören nicht in GET-Handler. Ein Cookie mit SameSite=Lax kann bei bestimmten Navigationen mitgeschickt werden; ein vermeintlich lesender Link darf deshalb keine Kontoeinstellung ändern. Die OWASP-Grenzen von SameSite machen diese Abhängigkeit deutlich.

Origin-/Refererprüfung und Fetch-Metadata können zusätzlichen Kontext liefern. Definieren Sie dafür erlaubte Fälle und den Umgang mit fehlenden Angaben. Eine Ausnahme für bekannte nichtbrowserbasierte Integrationen benötigt ein eigenes begründetes Zugangsmodell; „Header fehlt, also vertrauen“ ist keine allgemeine Regel. Ebenso können Proxyheader nur dann zum Vergleich dienen, wenn die Proxygrenze und deren Bereinigung geklärt sind.

Explizite Token und XSS verändern die Betrachtung

Wird ein Access-Token nur von Ihrem JavaScript ausdrücklich in Authorization gesetzt, besitzt eine fremde Seite dieses Token normalerweise nicht automatisch. Das reduziert den klassischen CSRF-Pfad für diese Requests. Untersuchen Sie trotzdem Login, Refresh und andere Routen, die möglicherweise wieder Cookies verwenden.

Das Verlegen eines Tokens in JavaScript-Speicher tauscht Risiken: Eingeschleuster Code im eigenen Origin kann je nach Speicherung Token lesen oder erlaubte Aktionen auslösen. Auch HttpOnly verhindert nicht jede Handlung solchen Codes. Die CSP-Grundlagen helfen bei einem Teil dieser Browserabsicherung; Eingabe-/Ausgabeverarbeitung und Abhängigkeiten bleiben weitere Aufgaben. Wählen Sie die Authentifizierungsarchitektur daher bewusst.

Einen eigenen Nachweis mit harmlosen Aktionen vorbereiten

Verwenden Sie eine eigene Testanwendung, Testkonten und eine reversible synthetische Änderung. Prüfen Sie den regulären Ablauf, fehlendes oder falsches CSRF-Token, eine fremde eigene Test-Origin, eine benachbarte Subdomain im geplanten Modell und fehlende Kontextheader. Belegen Sie nicht nur den Status, sondern dass die abgewiesene Anfrage den Zustand nicht verändert hat.

Nehmen Sie Login, Sitzungserneuerung, Logout und abgelaufene Sitzungen auf. Ein Schutz, der nur den normalen Bearbeiten-Button abdeckt, kann andere zustandsändernde Pfade übersehen. Führen Sie neue Regeln kontrolliert ein und halten Sie eine sichere vorige Konfiguration bereit. Bei legitimen Ausfällen klären Sie den betroffenen Flow; schalten Sie die Prüfung nicht global aus.

Der API Security Check führt keine Cookie- oder CSRF-Prüfung mit angemeldeten Konten aus. Dafür sind Anwendungskonfiguration, Codeprüfung und eigene Browser-/Integrationstests nötig. Bei blockierter Antwort trotz richtiger Schutzentscheidung hilft die CORS-Fehlerdiagnose. Quellenstand: 27. September 2026.

Passende nächste Schritte