Die Anwendung akzeptiert die Anfrage, weil Credentials wie Cookies automatisch mitgesendet werden, ohne ausreichend zu bestätigen, dass der Benutzer die Aktion beabsichtigte. Die Auswirkung ist durch die Privilegien des Benutzers und die verwundbare Operation begrenzt.
Abwehrmaßnahmen sollten beabsichtigte, anwendungsinterne Aktionen von Anfragen unterscheiden, die andernorts initiiert oder beeinflusst wurden. Framework-bereitgestellter Schutz ist vorzuziehen, wenn sein Scope und seine Konfiguration verstanden sind, und sensible Aktionen können zusätzlich explizite Re-Authentifizierung oder Bestätigung erfordern.
Wichtigste Punkte
AnfrageintegritätUnvorhersehbare Anti-CSRF-Tokens verwenden, die an die Sitzung des Benutzers gebunden sind, und sie serverseitig bei zustandsändernden Anfragen validieren — oder ein anderes framework-unterstütztes Muster mit gleichwertigen Eigenschaften einsetzen.
Browser-SignaleSameSite-Cookies angemessen konfigurieren und Origin-, Fetch-Metadata- oder erwartete Custom Header validieren, wo geeignet; diese als geschichtete Signale mit dokumentiertem Kompatibilitäts- und Proxy-Verhalten behandeln.
Workflow-DesignNominell schreibgeschützte Anfragemethoden dürfen keinen Zustand ändern, aktuelle Autorisierung für jede Aktion verlangen, Sitzungsprivilegien und -dauer begrenzen sowie Step-up-Prüfungen für folgenreiche Operationen ergänzen.
Wichtige EinschränkungSameSite-Cookies oder das bloße Vorhandensein von Tokens garantieren keinen Schutz. Tokens können auslaufen, vorhersagbar oder falsch gebunden sein, und Cross-Site Scripting (XSS) innerhalb der vertrauenswürdigen Anwendung kann viele CSRF-Abwehrmaßnahmen aushebeln.