Cross-Site Request Forgery: When Authentication Does Not Prove Intent

A browser automatically attaches some credentials, especially cookies, when sending requests to a matching site.

A malicious page can attempt to cause that browser to submit a request while the victim is logged in elsewhere.

Authentication proves which session sent a request; CSRF defenses help prove that the intended site initiated the sensitive action.

The attack exploits ambient authority, not password theft.

A concrete example: a hidden transfer form

A victim is logged into a bank.

Another website contains a hidden form targeting the bank's transfer endpoint. The browser submits it and includes the bank session cookie automatically.

If the bank checks only the cookie, it may treat the request as an intentional transfer.

Same-origin policy

The browser's same-origin policy prevents a malicious page from freely reading another site's response.

It does not prevent every cross-origin request from being sent. Forms, images, and navigation have long supported cross-origin requests.

CSRF can succeed without reading the response.

Ambient credentials

CSRF primarily affects credentials the browser attaches automatically:

• session cookies,
• some client certificates,
• and integrated authentication.

If an API requires an authorization header that malicious pages cannot obtain or set freely, classic CSRF risk is lower.

XSS can still steal or use tokens.

Anti-CSRF tokens

The application issues a random token tied to the user's session or request context.

Sensitive forms include the token, and the server verifies it. A foreign site can submit a request but cannot read the legitimate page to learn the token because of same-origin restrictions.

Tokens need strong randomness and safe comparison.

Synchronizer token pattern

The server stores a CSRF secret in the session and renders it into forms or exposes it through a same-origin endpoint.

The client returns it in:

• hidden form field,
• custom header,
• or request body.

The token should not appear in URLs, where it can leak through history and referrers.

Double-submit cookie

The server sets a token cookie readable by the application, and the client copies the value into a request field or header.

The server verifies both values match, often with a signed token.

Cookie scope and injection risks need careful design.

SameSite cookies

The SameSite attribute controls when browsers send cookies in cross-site contexts.

Modes broadly include:

• Strict,
• Lax,
• None with Secure.

SameSite provides strong defense for many flows, but compatibility, top-level navigation, subdomains, and legitimate cross-site use need evaluation.

Safe HTTP methods

GET, HEAD, and other safe methods should not change server state.

If a deletion occurs through a link:

GET /delete-account

cross-site images, crawlers, prefetching, and users can trigger it unexpectedly.

Use state-changing methods and CSRF protection.

Custom headers

JavaScript APIs can send a CSRF token in a custom header.

Cross-origin custom headers usually trigger a CORS preflight, giving the server another policy boundary. The server must not allow arbitrary origins with credentialed requests.

Headers are not available to ordinary HTML forms.

Origin and Referer checks

Servers can validate the Origin header or fall back to Referer for sensitive requests.

These checks provide defense in depth. Handle missing values deliberately and compare exact normalized origins, not substring matches.

Privacy tools and legacy clients can affect header availability.

CORS is not CSRF protection by itself

CORS controls whether browser JavaScript can read responses and send certain requests.

Simple cross-origin forms may still be sent. A permissive credentialed CORS policy can make attacks easier.

Configure exact trusted origins and retain explicit CSRF defenses for cookie-authenticated state changes.

Login CSRF

An attacker can force a victim's browser to log into the attacker's account.

The victim may then enter sensitive data into that account, which the attacker can view later.

Login forms can require CSRF tokens or pre-session binding too.

Logout and preference changes

Not every CSRF target moves money.

Attackers may:

• disable security settings,
• change email,
• connect an external account,
• alter shipping address,
• or log the victim out.

Protect actions according to consequence.

Step-up and confirmation

High-risk actions can require:

• recent authentication,
• passkey or second factor,
• re-entry of critical details,
• and clear confirmation.

This limits CSRF and stolen-session damage. Confirmation should display the actual recipient or amount.

APIs and mobile clients

Native apps generally do not share browser cookie behavior in the same way.

If an API uses bearer tokens in headers, classic CSRF may not apply, but token storage, deep links, and embedded web views create other risks.

Choose defenses based on the actual client and credential mechanism.

XSS defeats many CSRF controls

An XSS payload runs within the trusted origin.

It can read page tokens and submit valid requests. Preventing XSS remains necessary even with excellent CSRF protection.

Security layers address different attacker positions.

Testing

Test:

• request without token,
• wrong token,
• token from another session,
• cross-site form,
• SameSite behavior,
• missing Origin,
• allowed and denied CORS origins,
• and sensitive state change through safe methods.

Use browser tests because cookie and origin behavior is browser-enforced.

Knowledge check

1. How can CSRF succeed without reading a response?
2. What does an anti-CSRF token prove?
3. Why should GET not delete data?
4. How do SameSite and CORS differ?
5. Why can XSS bypass CSRF tokens?

The one idea to remember

CSRF abuses credentials a browser attaches automatically, so authentication alone does not prove user intent. Protect sensitive browser actions with server-verified tokens, suitable SameSite cookies, safe methods, strict origins, and step-up checks for high-impact changes.