Cross-site request forgery is a web-application flaw that tricks a user's authenticated browser into sending an unintended request.
Cross-site request forgery (CSRF) is a web-application vulnerability where a user’s browser sends an unintended, authenticated request to a site the user is already logged into. In plain language, the application treats a forged request as if the user clicked a real button in the trusted workflow.
CSRF matters because web applications often trust an existing session cookie. If a state-changing request is not strongly tied to the user’s intended action, the application can be tricked into processing it anyway.
It also matters because CSRF shows that authentication is not enough by itself. A user can be logged in, but the application still needs to verify that sensitive requests came from the correct workflow.
CSRF appears in web applications with browser-based sessions, account settings, administrative consoles, and any workflow that changes data or permissions. Teams review CSRF risk during secure coding review, DAST, and targeted testing of authenticated request handling.
Security teams often review CSRF alongside session management, Authorization, and sensitive action workflows because those controls need to work together.
A user is already signed in to a web admin console in one browser tab. Another page triggers a request that changes an account setting. If the application does not verify the request origin or include a CSRF token, the change is accepted even though the user never intended it.
| Protection | How it helps |
|---|---|
| Anti-CSRF tokens | Tie each sensitive request to a user-initiated page and session. |
| SameSite cookies | Reduce cross-site request leakage by default. |
| Step-up or re-auth | Require explicit user confirmation for sensitive changes. |
| Safe request design | Keep state-changing actions out of simple GET requests. |
CSRF is not the same as Cross-Site Scripting. CSRF abuses an authenticated session to trigger unintended actions, while XSS runs unsafe script in the browser.
It is also different from SQL Injection, which targets database query handling rather than browser-authenticated request trust.