The application accepts the request because credentials such as cookies accompany it automatically, without adequately confirming that the user intended the action. The impact is limited by the user’s privileges and the vulnerable operation.
Defenses should distinguish intentional, same-application actions from requests initiated or influenced elsewhere. Framework-provided protection is preferable when its scope and configuration are understood, and sensitive actions may also need explicit reauthentication or confirmation.
Key points
Request integrityUse unpredictable anti-CSRF tokens bound to the user’s session and validate them server-side on state-changing requests, or use another framework-supported pattern with equivalent properties.
Browser signalsConfigure SameSite cookies appropriately and validate Origin, Fetch Metadata, or expected custom headers where suitable; treat these as layered signals with documented compatibility and proxy behavior.
Workflow designDo not allow nominally read-only request methods to change state, require current authorization for every action, limit session privileges and duration, and add step-up checks for high-consequence operations.
Important limitationSameSite cookies or token presence alone does not guarantee protection. Tokens can be leaked, predictable, or incorrectly bound, and cross-site scripting (XSS) within the trusted application can defeat many CSRF defenses.