Skip to content

What is CSRF (cross-site request forgery)?

Last reviewed June 2, 2026

Cross-site request forgery (CSRF) is an attack that tricks an authenticated user's browser into submitting a request the user did not intend, such as changing their email or transferring funds. It abuses the fact that browsers automatically attach session cookies. The defenses are anti-CSRF tokens and SameSite cookie restrictions.

What CSRF is

Cross-site request forgery, tracked as CWE-352, is a vulnerability where a web application cannot tell whether a state-changing request was genuinely issued by the user or forged by a malicious site. Browsers automatically include a site's cookies with any request to that site, so if authentication relies only on an automatically sent session cookie, an attacker can craft a request that rides on the victim's existing session.

CSRF targets actions, not data theft: the attacker generally cannot read the response, but they can cause the application to perform an action the logged-in victim is authorized to do.

How the attack works

Say a bank processes transfers via POST /transfer with the parameters to and amount, authenticated solely by the session cookie. An attacker hosts a page containing an auto-submitting form that posts to the bank with to=attacker&amount=1000. When a victim who is logged into the bank visits the attacker's page, their browser submits the form and attaches the bank session cookie automatically. The bank sees a valid session and processes the transfer.

The victim never clicked anything on the bank site; a hidden form, an image tag pointing at a GET endpoint, or background JavaScript is enough. The attack works precisely because the request looks authentic to the server.

Real-world impact

  • Account takeover by forcing an email or password change.
  • Unauthorized financial transactions or purchases.
  • Privilege or configuration changes in admin panels.
  • Any state-changing action the victim is authorized to perform.

How to prevent it

Anti-CSRF tokens and SameSite cookies are complementary: tokens are the explicit control, while SameSite provides strong browser-level defense in depth.

  • Use anti-CSRF tokens: a unique, unpredictable, per-session (or per-request) token that the server issues and must accompany every state-changing request. A cross-site attacker cannot read or guess it.
  • Set session cookies to SameSite=Lax or SameSite=Strict so browsers do not send them on cross-site requests.
  • Prefer the double-submit cookie or synchronizer-token patterns provided by your framework rather than rolling your own.
  • Require re-authentication or verification for the most sensitive actions.
  • Never use GET for state-changing operations.

Keep exploring

Frequently asked questions

What is CSRF in simple terms?
It is an attack that makes your browser quietly send a request to a site you are logged into, using your existing session, so the site performs an action you never intended.
How is CSRF different from XSS?
XSS runs the attacker's script inside the trusted site and can read data. CSRF cannot read responses; it only forces the victim's browser to send an authenticated request to perform an action.
How do SameSite cookies stop CSRF?
SameSite=Lax or Strict tells the browser not to attach the session cookie to requests originating from other sites, so the forged cross-site request arrives without valid authentication.
Which CWE covers CSRF?
Cross-site request forgery is CWE-352, Cross-Site Request Forgery.