Cross-Site Request Forgery heißt übersetzt etwa "seitenübergreifende Anfragefälschung". Eine fremde Seite bringt den Browser eines angemeldeten Nutzers dazu, im Hintergrund eine Aktion auf einer anderen Website auszulösen, zum Beispiel eine Änderung im Backend. Der Browser schickt die Sitzungsdaten von selbst mit, deshalb sieht die Anfrage für die angegriffene Website echt aus. Abgewehrt wird das mit einem unvorhersehbaren Wert, der in jedem Formular steckt und beim Absenden geprüft wird. Andere Namen sind XSRF, "Sea Surf" und Session Riding [1].
Wie ein CSRF-Angriff abläuft
Das Sicherheitsprojekt OWASP beschreibt CSRF als Angriff, der das Opfer dazu bringt, eine schädliche Anfrage abzuschicken [1]. Das Opfer ist bei einer Website angemeldet, etwa im Redaktionsbereich seines CMS. In einem anderen Tab öffnet es eine präparierte Seite. Diese enthält ein unsichtbares Bild oder ein verstecktes Formular, das sich per JavaScript selbst abschickt, und zwar an die Website, bei der das Opfer angemeldet ist. Der Browser hängt das Sitzungscookie an, und die Website führt die Aktion aus, weil sie nicht unterscheiden kann, ob der Nutzer sie wollte [1].
Ziel sind Anfragen, die etwas verändern: eine E-Mail-Adresse ändern, einen Benutzer anlegen, eine Überweisung auslösen. Lesen kann der Angreifer die Antwort nicht, Datendiebstahl ist deshalb nicht der Zweck [1]. Laut OWASP schützen weder ein geheimes Cookie noch die Beschränkung auf POST-Anfragen, weil Cookies bei jeder Anfrage mitgehen und auch ein verstecktes Formular POST senden kann. HTTPS allein verhindert CSRF ebenfalls nicht [1].
Wie man sich schützt
Die von OWASP empfohlene Abwehr ist ein Token, das der Server erzeugt und bei jeder verändernden Anfrage prüft. Es ist je Sitzung eindeutig, geheim und nicht vorhersagbar und darf nicht in Adressen oder Protokolle gelangen [2]. Das Attribut SameSite an Sitzungscookies (siehe Cookies) ist eine zusätzliche Schutzschicht und reicht laut OWASP in den meisten Fällen allein nicht aus [2]. Ergänzend lässt sich prüfen, von welcher Herkunft eine Anfrage kommt. Verändernde Aktionen dürfen nie über GET laufen, also etwa nicht über einen einfachen Link zum Löschen [2]. Eine Lücke für Cross-Site-Scripting hebelt jeden CSRF-Schutz aus [2], deshalb gehören beide Themen zusammen, ebenso die Content Security Policy.
Nach unserer Erfahrung steckt der Fehler selten im Formular, das jemand bewusst abgesichert hat. Er steckt in dem, das später dazukam: eine Löschfunktion, ein Statuswechsel, ein Abmelden per Link. Deshalb gehört die Prüfung an eine zentrale Stelle, die jede verändernde Anfrage durchläuft. Das SEO CMS setzt in den Formularen des Verwaltungsbereichs ein CSRF-Token.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder du rufst einfach an.
Was CSRF mit SEO zu tun hat
Ein erfolgreicher Angriff auf das Backend kann Inhalte, Weiterleitungen oder Benutzerkonten verändern. Eingeschleuste Links oder Weiterleitungen auf fremde Seiten schaden dann auch der Sichtbarkeit. Was Google bei gehackten Websites meldet, zeigt die Seite Bericht Sicherheitsprobleme.
Wenn du ein eigenes Backend betreibst und nicht sicher bist, ob alle Formulare geschützt sind, sprechen wir in der gratis Sprechstunde darüber, welche Stellen du zuerst prüfen solltest.
- Organisation Cross Site Request Forgery (CSRF). OWASP. Stand ohne Datum. abgerufen am 31.10.2026
- Organisation Cross-Site Request Forgery Prevention Cheat Sheet. OWASP Cheat Sheet Series. Stand ohne Datum. abgerufen am 31.10.2026
Häufige Fragen
Wofür steht CSRF?
Für Cross-Site Request Forgery, also eine seitenübergreifende Anfragefälschung. Andere Namen sind XSRF, Sea Surf und Session Riding.
Was ist ein CSRF-Token?
Ein geheimer, nicht vorhersagbarer Wert, den der Server je Sitzung erzeugt und in Formulare einsetzt. Fehlt er beim Absenden oder stimmt er nicht, lehnt der Server die Anfrage ab.
Reicht SameSite als Schutz gegen CSRF?
Laut OWASP in den meisten Fällen nicht. SameSite ist eine zusätzliche Schutzschicht neben dem Token.
Was ist der Unterschied zwischen CSRF und XSS?
Bei CSRF schickt eine fremde Seite eine Anfrage im Namen des Nutzers. Bei XSS läuft fremder Code direkt in der angegriffenen Website. Eine XSS-Lücke kann den CSRF-Schutz aushebeln.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder du rufst einfach an.
Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Fehler entdeckt? Schreib uns.
