Zennoxa Shield
Application Security Glossary

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is a web vulnerability that tricks an authenticated user's browser into sending an unwanted state-changing request to a site where they are logged in, letting an attacker perform actions as that user without knowing their credentials.

Cross-Site Request Forgery (CSRF) abuses the fact that browsers automatically attach a user's session cookies to every request sent to a site. If an attacker can get a victim to load a malicious page or link while they are authenticated, that page can silently submit a form or fire a request to the target application, and the server will treat it as a legitimate, authenticated action such as changing an email address, transferring funds, or updating settings.

The attack works because the vulnerable server verifies who the user is (via the ambient cookie) but not that the request was intentionally initiated from its own pages. The standard defense is an anti-CSRF token: a per-session or per-request secret embedded in forms and validated on the server, which the attacker's cross-origin page cannot read or guess. Modern mitigations also include the SameSite cookie attribute, verifying Origin/Referer headers, and requiring re-authentication for sensitive operations.

For developers, CSRF matters because it targets authenticated actions and needs no XSS or credential theft to succeed — a single unprotected state-changing endpoint is enough. It appears on the OWASP radar (historically its own Top 10 category, now folded under broken access control) and is cataloged as CWE-352. Framework-level CSRF protection should be enabled by default and never disabled on endpoints that change server state.

Frequently asked questions

What is Cross-Site Request Forgery (CSRF)?
CSRF is an attack that forces a logged-in user's browser to submit a state-changing request to an application they are authenticated to, causing an action the user never intended — such as changing account details — without the attacker needing the user's password.
How do you prevent CSRF?
Use anti-CSRF tokens that the server issues and validates on every state-changing request, set the SameSite attribute on session cookies, verify the Origin or Referer header, and require re-authentication for sensitive actions. Most web frameworks provide built-in CSRF protection that should stay enabled.
CSRF vs XSS: what's the difference?
CSRF tricks a user's browser into sending a forged request using their existing session, exploiting the server's trust in the browser. XSS (cross-site scripting) injects and runs attacker-controlled script in the victim's browser, exploiting the browser's trust in the site. CSRF cannot read responses; XSS can.

Related terms

Cross-Site Request Forgery (CSRF) — Zennoxa Glossary — Zennoxa Shield