Cross-Site Request Forgery
Cross-Site Request Forgery, or CSRF, tricks a signed-in browser into sending an action the person did not choose. The target site trusts cookies or other credentials the browser adds automatically.
Another example
A signed-in payroll admin visits a harmful page that tries to `POST` a bank-account change. The app requires a session CSRF token, checks `Origin`, and uses `SameSite` cookies. It also asks the admin to sign in again. A `GET` link cannot change payroll.
Main parts
- 01Ambient authenticated session
- 02Cross-site forged request
- 03Server-side anti-CSRF validation
Use it when
Protect every browser request that changes data. This includes requests that send saved credentials by themselves. Use suitable tokens and origin checks.
Do not use it when
`POST` alone is not protection, and CORS is not a complete CSRF defense. Never put a CSRF token in a URL or a place another site can read.
Name used in code
synchronizer/double-submit token + Origin/Fetch Metadata checks + SameSite + reauthentication Before you ship
Work only within an explicitly authorized and isolated defense test. Check the trust boundary, inert regression case, mitigation, and handling of secrets and personal data. Check redacted detection signals, safe failure, incident owner, recovery, and rollback. Never test a real target.
Outcome: Assess and mitigate the risk from Cross-Site Request Forgery. Do not implement, enable, or use the attack. User context: A signed-in payroll admin visits a harmful page that tries to `POST` a bank-account change. The app requires a session CSRF token, checks `Origin`, and uses `SameSite` cookies. It also asks the admin to sign in again. A `GET` link cannot change payroll. Risk or control to address: Cross-Site Request Forgery. Why it applies: Protect every browser request that changes data. This includes requests that send saved credentials by themselves. Use suitable tokens and origin checks. Classification boundary: `POST` alone is not protection, and CORS is not a complete CSRF defense. Never put a CSRF token in a URL or a place another site can read. Safety requirements: Test only in an isolated space with explicit permission. Use inert, harmless inputs. Protect secrets and personal data. Name the trust boundary and record the mitigation. Operational safeguards: Set up detection and logs that hide sensitive data. Name the incident owner. Define a safe failure mode and rollback before release. Acceptance criteria: A defensive regression test fails before the mitigation and passes after it. No real target, secret, or personal data is used. Monitoring and rollback are verified. Evidence and limits (evidence boundary): It is official for that source. Other platforms or teams may use the term in another way. Unknowns to confirm: Authorized scope, affected assets, data class, threat actor, incident owner, and rollback limits.
Check this request
Review the current use of Cross-Site Request Forgery. Definition: Cross-Site Request Forgery, or CSRF, tricks a signed-in browser into sending an action the person did not choose. The target site trusts cookies or other credentials the browser adds automatically. Release checks: Work only within an explicitly authorized and isolated defense test. Check the trust boundary, inert regression case, mitigation, and handling of secrets and personal data. Check redacted detection signals, safe failure, incident owner, recovery, and rollback. Never test a real target. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.