Disclaimer: This content is for educational purposes only. The author is not responsible for any misuse of the information. Always act ethically and ensure you have proper authorization when testing or engaging in security activities.

What is CSRF (Cross-Site Request Forgery)?

CSRF (Cross-Site Request Forgery) is a web application vulnerability where an attacker tricks a user’s browser into submitting unintended requests to a web application where the user is authenticated. Essentially, the attacker uses the user’s identity (via their session or credentials) without the user’s knowledge to perform actions that benefit the attacker.

Because the request originates from the victim’s browser and includes their authentication token or cookie, the target server believes the request is legitimate.

Why CSRF Matters in 2025

Most web applications still rely on cookies or bearer tokens, and many workflows involve state-changing actions (profile updates, money transfers, permissions changes). CSRF targets these workflows.

With the rise of Single Page Applications (SPAs), microservices and APIs, security boundaries are shifting — developers sometimes mistakenly believe CSRF is no longer relevant. Actually, APIs and SPAs can still be vulnerable under certain design patterns.

CSRF can lead to serious consequence: unauthorized fund transfers, account takeovers, data corruption or deletion, lateral privilege escalation, or persistent attacker access.

In bug-bounty programs and penetration testing, CSRF remains in the top categories of real-world findings. Enough organizations assume “we use an API so CSRF isn’t an issue” — and that assumption leads to major issues.

CSRF Made Simple — With an Analogy

Analogy: “The Trusted Messenger”
Imagine you’re at home and you’ve given a trusted helper a key to your front door. You ask them: “If someone I didn’t know comes along and says ‘Please go fetch the bike in the shed’, the helper will do it because they hear your voice.”

In a CSRF scenario, the attacker crafts a request that looks like you asking the helper to act — because your session/cookie implies your “voice” is present. The server (the helper) doesn’t verify if you actually intended to send that request — it just trusts the authentication.

Types of CSRF Attacks (With Examples)

Let’s break down the most common and dangerous types of CSRF attacks:

1. Classic (Stored) CSRF

Goal: Victim visits a malicious site/page (or clicks a malicious link) while logged into the target application. The malicious page triggers a request to the target application using the victim’s credentials.

Example:

html

<img src="https://bank.example.com/transfer?amount=10000&to=attacker_account" style="display:none">

If the victim is logged into bank.example.com, this request may execute using their session cookie — transferring money to the attacker.

Risks:

Unauthorized state-changing actions (money transfers, account settings changed)
Data deletion or corruption
Hidden attacker actions under the victim’s identity

2. “Double-Submit”/Token Bypass CSRF

Goal: Some apps implement CSRF tokens but incorrectly — e.g., using predictable tokens, or storing them in a way that the attacker can access/control. The attacker may also exploit mis-configured CORS or API endpoints that accept tokens via GET parameters or headers that are automatically sent.

Example: An API expects a header X-CSRF-Token but also accepts ?csrf_token= in the URL, and the front-end pulls the token from a predictable cookie. An attacker crafts a link like:

text

https://app.example.com/update?csrf_token=knownValue&field=…

The attacker uses the known/predictable token and performs the action.

Risks:

CSRF protection defeated by weak token management
Attack surface increases when API endpoints expose predictable or un-protected parameters

3. API / SPA CSRF (JSON-based)

Goal: Modern web apps using JSON/XHR/Fetch often assume CSRF isn’t relevant because they use JWTs, CORS or authorization headers. But under certain conditions, CSRF still applies — for instance, if credentials are stored in cookies (rather than local storage) and the browser still sends them automatically.

Example:
A single-page app on spa.example.com uses a cookie authToken. A fetch request:

javascript

fetch('https://api.example.com/user/delete', { method: 'POST', credentials: 'include' });

But the backend accepts POST with cookie only. Attacker site triggers:

html

<form action="https://api.example.com/user/delete" method="POST">
  <input type="hidden" name="confirm" value="yes">
</form>
<script>document.forms[0].submit();</script>

If the user is logged in (cookie present), the request executes.

Risks:

Modern frameworks may lull developers into thinking CSRF is solved
Attack surface through JSON endpoints, GraphQL, RPC if cookies are used

4. Blind CSRF / Out-of-Band CSRF

Goal: The attacker triggers a request but doesn’t see the direct response. Instead, they observe side-effects (e.g., changed data, new resource created) or via callback mechanisms (DNS, HTTP) to detect success.

Example: Attacker triggers a CSRF that causes the target to send a callback to a domain under attacker control, or logs a DNS request.

Detection: Monitoring DNS logs, HTTP callbacks, or unusual network traffic.

Risks:

Silent attacks hard to detect without monitoring
Infrastructure misuse (e.g., attacker causes system to make external requests)

5. Advanced CSRF Techniques & Bypass Tricks

Goal: Bypass CSRF protections (SameSite cookies, tokens, origin checks) using creative techniques.

Common tricks:

Submitting via Flash, older plugins, or tags pointing to POST endpoints (historical)
Using embedded iframes + auto-submission + redirect chains
Exploiting mis-configured SameSite cookies (e.g., SameSite=None; Secure without proper domain restrictions)
Leveraging CORS mis-configurations where a non-trusted origin is allowed and credentials sent automatically

Risks:

Even modern protections can be bypassed if not properly implemented or tested
Attack surface multiplies in complex architectures (micro-services, API gateways, cloud functions)

Real-World Examples

Here are a few real-world scenarios illustrating how CSRF can wreck havoc:

Example 1: Banking App Transfer – A victim logged into a banking portal visits a malicious site; the malicious site auto-submits a transfer request using the victim’s session cookie, sending funds to the attacker.

Example 2: Admin Panel Abuse – An internal company admin panel uses cookies for authentication and has a feature “Promote User to Admin” accessible via a simple POST endpoint without CSRF token. An attacker tricks an employee to visit an external page, causing the employee’s browser to promote the attacker’s account.

Example 3: API Endpoint Vulnerability – A SaaS application offers a JSON API protected by a cookie but no CSRF token. Because the cookie is automatically sent, a malicious site binds a hidden form or AJAX that calls the delete endpoint. Accounts are deleted or changed without the victim’s knowledge.

Example 4: Cloud Function Trigger – A cloud-based micro-service endpoint accepts POST requests authenticated via a session cookie. Though intended for internal usage, a mis-exposed endpoint allowed CSRF. The attacker caused the system to initiate expensive compute tasks, incurring significant cost and resource usage.

CSRF Prevention (Best Practices for 2025)

To defend effectively against CSRF, apply layered protections across your application stack:

Use a Strict CSRF Token

Generate a per-session or per-request unpredictable token
Associate the token with the user session, don’t rely on predictable values
Require the token in a request header or POST body, never via URL parameter
Reject requests missing or invalid tokens

Enforce SameSite Cookies

Set SameSite=Lax or Strict on authentication cookies if feasible. SameSite=Strict is ideal for high-risk apps
For cross-site usage (e.g., SSO/multi-domain), use SameSite=None; Secure, but assess risk carefully
Combine with Secure to ensure cookies transmitted only over HTTPS

Validate Origin and Referrer Headers

On sensitive state-changing requests, verify the Origin header (preferred) or Referrer header matches expected domain(s)
Reject requests where Origin or Referrer is missing or doesn’t match trusted sites

Use Custom Headers and Disallow Simple GET for State-Changes

Design your API endpoints so that state-changing actions require non-simple requests (e.g., POST/PUT/DELETE) and a custom header (e.g., X-Requested-With: XMLHttpRequest)
Browsers do not allow cross-site scripts to send custom headers easily (unless CORS-allowed), giving you extra protection

Avoid Reliance on Cookie-Only Auth for Sensitive Endpoints

If possible, use token‐based auth stored in a non‐automatically‐sent location (e.g., localStorage) and require it in an Authorization header
If you must use cookies, ensure you apply the full CSRF token + SameSite + origin check combo

Regularly Test for CSRF During Pen-Testing and Bug Bounties

Even when frameworks claim to provide CSRF protection, test thoroughly: missing tokens, predictable tokens, CORS mis-settings, cross-domain flows, and API endpoints
Use automated scanning plus manual review of state-changing endpoints, especially hidden or undocumented endpoints

Provide User Education & Logging

Alert users of unexpected high-risk actions (e.g., password changes, banking transfers) via secondary channels (email/SMS)
Log suspicious sequences with missing or invalid CSRF tokens for forensic investigation
Monitor unusual behavior from legitimate sessions (large transfers, unusual endpoints triggered) which may indicate CSRF or session misuse

CSRF Prevention Summary Table

Risk Area	Why It Matters	Recommended Control
Authentication Cookies	Automatically sent by browser, enabling CSRF	SameSite, Secure, HttpOnly
State-Changing Endpoints	Attackers target these to cause damage	CSRF token, Origin/Referrer check, custom header
API / SPA Endpoints	Often omitted from traditional CSRF review	Enforce anti-CSRF in JS/API flows
Token Predictability	Weak tokens are easily bypassed	Use strong randomness, tie to session
Complex Architectures	Micro-services + cloud = many exposed endpoints	Centralised gating, consistent CSRF checks

Final Thoughts

CSRF is a classic vulnerability — but it’s far from obsolete. In fact, as architectures become more distributed (APIs, micro-services, SPAs), the risk of CSRF can grow because developers may assume “we use JWTs so we’re safe” or “we’re purely API, no forms, so no CSRF”.

Don’t let assumptions blind your security posture.

By combining strong CSRF tokens, proper cookie controls (SameSite, Secure), origin/referrer validation, API design discipline, and consistent testing, you can build a robust defense against CSRF attacks.

If you’re a security professional, bug bounty hunter or developer, make CSRF a must-check during your reviews — especially for endpoints that change state, perform admin tasks, or are exposed via APIs.

Stay safe, stay deliberate — and keep pushing your security posture forward.