What is CSRF in one sentence?

CSRF is an attack that tricks a logged-in user's browser into sending a request the user never intended, exploiting the fact that browsers attach session cookies automatically.

How is CSRF different from XSS?

XSS runs the attacker's script inside your site; CSRF makes the victim's browser send a forged request from a different site. XSS abuses code execution, CSRF abuses ambient authentication.

What is the SameSite cookie attribute?

A cookie flag that controls whether a cookie is sent on cross-site requests. SameSite=Lax or Strict blocks most classic CSRF by preventing the session cookie from riding along on a forged cross-site request.

Do APIs that use bearer tokens need CSRF protection?

Generally no. CSRF relies on the browser automatically attaching credentials like cookies. A token sent in an Authorization header is not auto-attached, so token-based APIs are largely immune.

What is a CSRF token?

A secret, per-session or per-request value the server issues and the form must echo back. Because an attacker's site cannot read it, the server can reject any state-changing request that lacks the correct token.

Glossary · Security

What is CSRF (Cross-Site Request Forgery)?

Cross-site request forgery is an attack that abuses a browser's habit of automatically attaching your session cookies to every request it makes to a site. By luring you to a malicious page while you are logged in elsewhere, an attacker can make your own browser fire off a real, authenticated request — changing your email, transferring funds, or updating a setting — without you clicking anything that looks dangerous.

The trick behind it

When you log into a site, the server hands your browser a session cookie, and from then on the browser attaches that cookie to every request bound for that site — including requests triggered by other sites. CSRF weaponizes this “ambient authority.” An attacker hosts a page with a hidden form or image that points at the target site's state-changing endpoint. When your authenticated browser loads it, the cookie rides along, and the server cannot tell the forged request apart from one you made deliberately. The attacker never sees the response — they just need the action to fire.

CSRF versus XSS

The two are often confused but are opposites in mechanism. Cross-site scripting runs the attacker's code inside your site and can read responses, steal tokens, and do nearly anything. CSRF runs nothing inside your site — it simply causes a blind, one-way request from the outside, relying entirely on the credentials the browser sends automatically. That distinction matters for defense: a site fully protected against CSRF can still be wrecked by XSS, because XSS executes within the trusted origin and can forge requests with the correct token already attached.

What it can do

CSRF only matters on requests that change state, but those are the ones that count. A successful attack can change a victim's password or recovery email — quietly taking over the account — move money, alter permissions, post content, or flip a configuration toggle. Because the request is genuine and authenticated, logs show the victim performing the action themselves, which makes these incidents hard to attribute after the fact. The blast radius is whatever the victim's account is authorized to do with a single request.

How to prevent it

The modern baseline is the SameSite cookie attribute: setting session cookies to SameSite=Lax or Strict stops the browser from attaching them to cross-site requests, which neutralizes most classic CSRF for free. On top of that, use anti-CSRF tokens — a secret value the server issues and the form must return, which an attacker's page cannot read or guess. For sensitive actions, validate the Origin or Referer header and require re-authentication. APIs that authenticate with a bearer token in an Authorization header rather than a cookie are largely immune, because that credential is not auto-attached by the browser.

At QUANT LAB

In a web application penetration test we map every state-changing endpoint and check whether each one can be triggered cross-origin — paying special attention to legacy forms, internal admin actions, and endpoints that quietly accept both cookie and header auth. The applications we build default to SameSite cookies, framework-level CSRF tokens, and header-based auth for APIs, so the protection is structural rather than bolted on. CSRF is cheap to prevent and embarrassing to find in production, so we treat it as a default, not an afterthought.

A shrinking but not gone threat

Browsers now default new cookies to SameSite=Lax, which has quietly retired a huge swath of historical CSRF. But the threat is not extinct. Endpoints that explicitly loosen SameSite for cross-origin flows, GET requests that wrongly change state, and subdomains that share cookies can all reopen the door. CSRF remains a standard item on the OWASP Top 10 radar precisely because the defaults help but do not absolve a team from thinking through every authenticated, state-changing path.

Long-form deep-dives that use this term

All posts

Related terms

Unsure if your endpoints are forgeable?

We test every state-changing route for CSRF and build apps with SameSite and token defenses by default. Book a 30-minute call.

Web app pentest