Cross-Site Request Forgery (CSRF) forces a victim’s browser to perform actions on a website where the victim is already authenticated. The attacker does not steal credentials; instead, they exploit the browser’s automatic behavior of sending cookies, including session cookies, with every request to the target domain.

If the target application does not verify that the request was intentionally made by the user, the attacker can execute actions such as:

• changing passwords

• transferring funds

• updating email addresses

• deleting accounts

• performing admin operations

CSRF attacks succeed because browsers automatically attach cookies, and many applications rely on cookies alone for authentication.

How CSRF Works

When a victim is logged into a website, their browser stores:

• session cookies

• authentication tokens (if cookie-based)

• persistent login data

If the victim visits a malicious website while still logged in, the attacker’s site can send a request:

<img src="https://bank.com/transfer?amount=5000&to=attacker">

The browser automatically includes:

Cookie: session=USER_SESSION

If the bank does not verify the request origin or require an additional token, the transfer executes.

Why CSRF Happens

CSRF occurs due to:

• relying solely on cookies for authentication

• no CSRF tokens

• weak SameSite cookie configuration

• trusting Referer or Origin headers without checking consistency

• missing or weak server-side request validation

• unsafe HTTP methods allowed for state-changing actions

Any endpoint that modifies state and accepts cookie-based authentication is vulnerable.

Common Targets of CSRF

CSRF affects any action that:

• changes user data

• triggers sensitive flows

• performs financial operations

• updates account information

• modifies permissions

• processes stored actions

Typical high-risk endpoints include:

/changePassword
/updateEmail
/deleteAccount
/transferFunds
/upgradePlan
/admin/updateUser

Practical CSRF Attack Construction

Basic CSRF Attack (GET Request)

If the application uses GET for state-changing:

<img src="https://target.com/deleteAccount">

The victim loads the attacker’s page → browser sends authenticated request → account deleted.

Form-Based CSRF (POST Request)

POST requests require a form:

<form action="https://target.com/changeEmail" method="POST">
  <input type="hidden" name="email" value="attacker@example.com">
</form>
<script>document.forms[0].submit();</script>

The victim never sees the form; it auto-submits.

JavaScript-Based CSRF

If CORS allows unsafe cross-origin requests and cookies are sent:

<script>
fetch("https://target.com/api/update", {
  method: "POST",
  credentials: "include",
  body: JSON.stringify({"role":"admin"})
});
</script>

If CORS misconfigured → full account takeover.

Advanced CSRF Techniques

1. CSRF Using Auto-Submitting Iframes

Invisible iframe:

<iframe src="https://target.com/transfer?to=attacker&amount=1000" style="display:none"></iframe>

2. JSON CSRF

Some applications process JSON from form-encoded input.

Exploit:

<form action="https://target.com/api/updateProfile" method="POST" enctype="text/plain">
{ "role": "admin" }
</form>
<script>document.forms[0].submit();</script>

If backend parses incorrectly → unauthorized privilege change.

3. Multi-Step CSRF

Many sensitive workflows contain multiple steps.
Attackers submit them automatically:

Step 1:

<form action="https://target.com/startTransfer" method="POST">
  <input type="hidden" name="amount" value="2000">
</form>

Step 2:

<form action="https://target.com/confirmTransfer" method="POST">
  <input type="hidden" name="confirm" value="yes">
</form>

Both auto-submit.

4. Blind CSRF

If there is no visible result, attacker uses:

• timing differences

• confirmation emails

• account lock triggers

• out-of-band success indicators

to confirm attack success.

5. Login CSRF

Login CSRF forces the victim to unknowingly log into the attacker’s account.

Victim is logged into attacker’s account → attacker later hijacks it by knowing all credentials.

6. CSRF with Cookie Manipulation + CORS

If CORS allows cookies cross-origin:

fetch("https://target.com/admin/promote", {credentials:"include"});

Allows full privilege escalation.

Realistic Example Scenarios

Modify Email Without Verification

Request:

POST /changeEmail
email=attacker@evil.com

Attacker page triggers:

<form action="https://target.com/changeEmail" method="POST">
  <input name="email" value="attacker@evil.com">
</form>
<script>document.forms[0].submit();</script>

Victim’s account now bound to attacker email.

Unauthorized Fund Transfer

POST /transfer
to=attacker&amount=5000

Victim visits malicious page → hidden form executes → money transferred.

Adding an Admin User

POST /admin/createUser
role=admin&username=hacker

Normal users visiting attacker’s page escalate attacker’s privileges.

Why CSRF Becomes Critical

CSRF turns a victim’s browser into a weapon against them.

It succeeds because:

• browser automatically includes cookies

• servers often rely solely on cookies

• browsers trust HTML and form submissions

• users cannot detect invisible requests

• UI cannot defend against backend vulnerabilities

CSRF does not require XSS. It works even on websites with perfect HTML/JS sanitization.

Practical CSRF Testing Workflow

Step 1: Identify State-Changing Endpoints

Examples:

POST /update
POST /delete
POST /transfer

Step 2: Check If Action Works Authenticated Without Additional Tokens

Send authenticated request with:

• no CSRF token

• no Origin

• no Referer

If accepted → vulnerable.

Step 3: Test with Modified Origin Header

Check if the application requires:

Origin: https://target.com

If server accepts requests from attacker origin → CSRF possible.

Step 4: Attempt to Forge Requests

Build proof-of-concept forms:

• GET: <img>

• POST: <form>

• JSON: text/plain forms

Step 5: Combine with Clickjacking

Clickjacking helps trigger CSRF actions requiring manual confirmation.

Step 6: Try CORS-Assisted CSRF for APIs

If Access-Control-Allow-Credentials is enabled → bypasses CSRF entirely.

CSRF Defense Mistakes

Developers often rely on:

• disabling buttons via JavaScript

• client-side validation

• checking user-agent

• checking IP

• checking Referer alone

These are unreliable and fail under malicious conditions.

Impact of CSRF

CSRF allows attackers to perform:

• account manipulation

• password/email changes

• fund transfers

• privilege escalation

• deletion of user accounts

• admin operations

• sensitive configuration changes

It is a silent, powerful attack that uses the victim’s own browser and session.

Intel Dump

• CSRF forces authenticated browsers to perform unauthorized actions.

• The attack works because browsers automatically attach cookies.

• Vulnerable endpoints lack CSRF tokens, SameSite cookies, or Origin checks.

• Techniques include hidden forms, iframes, JSON CSRF, multi-step CSRF, login CSRF, and CORS-assisted CSRF.

• High-impact outcomes include fund transfers, privilege escalation, email changes, and full account takeover.