CSRF (Cross-Site Request Forgery): Definition & Prevention

CSRF (cross-site request forgery) is a web attack that tricks a logged-in user’s browser into sending an authenticated request the user didn’t intend. If your application uses cookie-based sessions, CSRF remains a real risk for any state-changing endpoint that doesn’t enforce an anti-CSRF token (or an equivalent control like strict Origin validation).

How CSRF works

At a high level, CSRF abuses a normal browser feature: browsers automatically attach relevant cookies when making requests to a site. If your application authenticates requests primarily via cookies (session cookies, “remember me” cookies, etc.), then any request the browser makes to your domain may be treated as “logged in.”

The typical CSRF flow (step-by-step)

1. Victim is logged in to https://bank.example in their browser.
2. The victim visits an attacker-controlled page, such as https://evil.example.
3. The attacker’s page causes the victim’s browser to submit a request to https://bank.example/transfer (or another state-changing endpoint).
4. The victim’s browser automatically includes bank.example cookies with that request.
5. If the bank’s endpoint does not require a CSRF defense (like a per-request token), the action is performed.

Why CSRF works even though the attacker can’t read responses

The browser’s Same-Origin Policy (SOP) prevents evil.example from reading sensitive responses from bank.example. But in many CSRF cases, the attacker doesn’t need to read the response—only to trigger a state change (transfer funds, change email, add an API key, disable MFA, etc.).

Common delivery mechanisms attackers use

Attackers can trigger cross-site requests using several primitives:

• Auto-submitted HTML forms (classic CSRF): makes POST requests easy.
• GET requests via image/script tags or links: relies on unsafe state changes on GET.
• JavaScript fetch() / XHR: often blocked from reading by CORS, but may still send requests depending on cookie settings and server configuration.
• Clickjacking-assisted CSRF: tricking the user into clicking a legitimate button in a framed page.

What makes an endpoint vulnerable

An endpoint is generally vulnerable to CSRF if all of the following are true:

• Authentication is automatic (typically cookie-based sessions).
• The endpoint performs a state-changing action (create/update/delete, money movement, settings changes).
• The request can be made cross-site without a secret the attacker cannot obtain.
• The application does not validate a CSRF token (or equivalent defense like strict Origin validation).

Technical notes: minimal vulnerable example

A vulnerable app might accept a password change without an anti-CSRF token:

POST /account/change-password HTTP/1.1
Host: app.example
Cookie: session=abc123
Content-Type: application/x-www-form-urlencoded

new_password=Summer2026!

An attacker can host a page that auto-submits a form to your endpoint:

<form action="https://app.example/account/change-password" method="POST">
  <input type="hidden" name="new_password" value="Pwned123!" />
</form>
<script>document.forms[0].submit();</script>

If the victim is logged in, the browser attaches session=abc123 automatically.

When you’ll encounter CSRF in real environments

CSRF shows up most often in environments that use cookies for authentication and have browser-accessible administrative or account-management actions.

1) Traditional web apps with server-side sessions

If your application uses a session cookie like sessionid=... and supports actions such as:

• Changing email/password
• Adding SSH keys
• Creating API tokens
• Updating payment details
• Approving workflows (HR, finance, ticketing)

…then CSRF is a practical concern.

2) Admin panels and internal tools

CSRF against admin interfaces can be especially damaging because admins have elevated privileges. Internal tools are frequently “trusted,” under-hardened, and accessible to staff who browse the web during authenticated sessions.

In practice, many teams pair CSRF hardening with broader endpoint protection/monitoring so suspicious activity is easier to detect and contain. If you’re comparing options for business endpoints, see our guide to the best antivirus for Windows business endpoints: best antivirus for windows business endpoints 2026.

3) Legacy apps that use GET for state changes

If you ever see patterns like:

• GET /user/delete?id=123
• GET /admin/disable?user=bob

…treat them as emergency refactors. GET should be safe and idempotent; state-changing operations should use POST/PUT/PATCH/DELETE and require CSRF defenses.

Technical notes: quick hunting clues in traffic and logs

Look for state changes triggered by requests missing CSRF signals:

• No anti-CSRF token parameter/header
• No Origin/Referer validation
• Cookies present on cross-site navigations

In web logs, you may see suspicious Referer values pointing to non-owned domains on sensitive endpoints:

POST /account/email HTTP/1.1
Referer: https://evil.example/free-stuff
Cookie: session=...

(Absence of Referer is not proof of attack—some clients strip it—so treat this as a signal, not a sole control.)

4) Modern SPAs that still rely on cookies

Single-page applications often use cookie-based auth (for convenience or security properties like httpOnly cookies). CSRF is still relevant unless you have strong defenses:

• Anti-CSRF tokens (synchronizer token pattern) or double-submit cookies
• Strict SameSite cookie settings
• Origin validation for state-changing requests

If the SPA uses bearer tokens in headers (e.g., Authorization: Bearer ...) and those tokens aren’t automatically sent cross-site, CSRF risk is reduced—but other risks (XSS token theft, token leakage) may increase.

5) OAuth and login flows (misconfiguration risk)

CSRF concepts also apply to authentication flows (e.g., “login CSRF” and OAuth state parameter misuse). Even when not “classic CSRF,” you’ll see the same theme: attacker-driven requests accepted due to missing request-specific validation.

How to prevent CSRF (practical checklist)

Use layered controls; don’t rely on only one.

1) Require anti-CSRF tokens on all state-changing endpoints

• Generate unpredictable tokens per session (or per request) and validate them server-side.
• Prefer standard framework features (Django, Rails, Spring Security, ASP.NET, Laravel, etc.).
• Ensure tokens are tied to the session/user context and rotated when appropriate.

2) Validate Origin and/or Referer on unsafe methods

• Enforce Origin for POST/PUT/PATCH/DELETE.
• Allow only your expected scheme/host.
• Decide how to handle missing headers (common: require token; optionally block in high-risk contexts).

3) Set cookies with SameSite (and secure flags)

• SameSite=Lax is a common baseline; it mitigates many cross-site POSTs while preserving typical navigation flows.
• SameSite=Strict is stronger but can break legitimate flows.
• Pair with Secure and HttpOnly where appropriate.

Example hardening:

Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

4) Never use GET for state change

• Ensure GET endpoints are safe (no side effects).
• Use POST/PUT/PATCH/DELETE for changes and protect them with CSRF controls.

5) Add step-up verification for high-risk actions

For actions like changing email, creating API tokens, or disabling MFA, require a second factor such as:

• Password re-entry
• WebAuthn prompt
• Verified email link (with short-lived, single-use token)

6) Reduce account-takeover blast radius with password hygiene

CSRF is a web-layer issue, but account protection still matters when attackers combine techniques (phishing + session abuse + weak passwords). A practical move for teams is standardizing on a business password manager. If you’re evaluating options, see our roundup: password manager for small business 2026.
If you need a widely used option, 1Password is a common pick for businesses and supports strong sharing and admin controls (Try 1Password →).