How a Single CSRF Vulnerability Can Lead to a Huge Bug Bounty

Disclaimer

This article is written strictly for educational and defensive security purposes.
All examples are simplified, hypothetical, and sanitized.
Only test applications you own or have explicit written permission to assess.

Introduction

Cross-Site Request Forgery (CSRF) is often treated as a “basic” vulnerability — something juniors learn early and seniors mentally deprioritize.

That mindset is exactly why CSRF continues to generate high-impact bug bounties.

When CSRF is chained with sensitive actions like email changes, financial operations, or admin workflows, it becomes a silent and extremely powerful attack primitive.

This write-up walks step by step through why CSRF still exists, how attackers exploit it, and how a single missing protection can translate into real money and real damage.

What Is CSRF (In One Sentence)

CSRF occurs when a victim’s browser — already authenticated to a website — is tricked into sending a state-changing request without the user’s intent, simply because the browser automatically attaches session cookies.

Why CSRF Still Works in Modern Applications

Despite years of awareness, CSRF persists due to a dangerous assumption:

“If the user is authenticated, the request must be legitimate.”

That assumption ignores how browsers actually work.

How Browsers Enable CSRF by Design

Automatic Cookie Attachment

Browsers automatically attach cookies to every request sent to a domain — regardless of where the request originated.

This means:

• Requests from attacker.com
• Requests from emails
• Requests from malicious ads
• Requests from hidden HTML elements

All carry the victim’s authenticated session cookies.

The browser does not know intent.
It only knows destination.

The CSRF Attack Flow (Clear and Practical)

Step 1: Victim Logs In

The victim authenticates to example.com.

The browser stores:

• Session cookie
• Authentication state

Step 2: Attacker Prepares a Malicious Request

The attacker crafts a request that performs a state-changing action, such as:

• Changing an email address
• Transferring funds
• Disabling MFA
• Adding an admin user

No authentication headers are required — cookies handle that automatically.

Step 3: Attacker Delivers the Trap

The malicious request is embedded in:

• A hidden HTML form
• A link
• An image request
• JavaScript auto-submission
• A compromised website

Step 4: Victim Triggers the Request

If the victim:

• Visits the attacker’s page
• Opens a malicious email
• Loads an injected script

The browser sends the request with valid cookies attached.

Step 5: Server Executes the Action

The server sees:

• A valid session cookie
• A correctly structured request

It assumes legitimacy — and executes the action.

Why the Server Is Fooled

The server never verifies intent.

It checks:

• “Is the user logged in?” → Yes

It does not check:

• “Did this request originate from my site?”
• “Was this action intentionally initiated?”
• “Does this request contain a valid CSRF token?”

Real-World Endpoints Commonly Affected

CSRF frequently appears in:

• Change email
• Change password
• Update phone number
• Disable MFA
• Money transfer
• Subscription changes
• Admin actions
• OAuth authorization flows
• Profile updates

Any state-changing endpoint relying only on cookies is a candidate.

Why CSRF Bounties Can Be High

CSRF bounties spike when the vulnerable endpoint affects:

• Financial operations
• Authentication data
• Account recovery
• Admin privileges
• Business-critical workflows

Many programs rate such CSRF issues as high severity, often rewarding $800–$2000+.

A Full CSRF Example (Educational)

Vulnerable Endpoint (Hypothetical)

The application allows transfers via:

POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: session=VALID_SESSION
Content-Type: application/x-www-form-urlencoded

amount=1000&to_account=ATTACKER_ACCOUNT

The server:

• Checks only the session cookie
• Performs no CSRF validation

Attacker-Controlled Page

<!-- EDUCATIONAL EXAMPLE ONLY -->
<form action="https://bank.example.com/transfer" method="POST">
  <input type="hidden" name="amount" value="1000">
  <input type="hidden" name="to_account" value="1234567890">
</form>

<script>
  document.forms[0].submit();
</script>

Why This Works

• Browser automatically attaches cookies
• Server trusts cookies as intent
• No CSRF token is required
• Action executes silently

The victim never clicks “Transfer”.

Root Causes of CSRF in Real Applications

Missing Anti-CSRF Tokens

No unpredictable token → no proof of intent.

State-Changing GET Requests

GET /deleteAccount?id=5

This can be triggered via:

• <img>
• <iframe>
• <link>

No Origin or Referer Validation

The server never checks:

Origin: https://example.com

Misconfigured SameSite Cookies

Cookies set as:

• SameSite=None
• Or missing SameSite

Allow cross-site requests.

CORS Misconfigurations

Allowing:

• Access-Control-Allow-Credentials: true
• With untrusted origins

How to Defend Against CSRF (Correctly)

1. Use Anti-CSRF Tokens

• Unique
• Unpredictable
• Validated server-side

2. Enforce SameSite Cookies

Set-Cookie: session=XYZ; Secure; HttpOnly; SameSite=Lax

3. Validate Origin and Referer

Reject requests where:

• Origin is missing or mismatched
• Referer is invalid

4. Never Use GET for State Changes

GET must be idempotent and safe.

5. Protect APIs Separately

APIs using cookies must:

• Enforce CSRF protection
• Or switch to token-based authentication

Lessons for Bug Hunters

• Don’t ignore “basic” vulnerabilities
• Always test sensitive endpoints
• Look for cookie-only authentication
• Check for missing CSRF tokens
• Think in impact, not exploit complexity

Lessons for Developers

• Cookies do not equal intent
• Authentication ≠ authorization ≠ intent
• CSRF protection is mandatory, not optional
• Security controls must be layered

Conclusion

CSRF is not obsolete.
It is not boring.
It is not low impact by default.

When paired with sensitive functionality, a single missing control can become a high-value vulnerability with real-world consequences.

CSRF doesn’t rely on clever payloads — it relies on trust assumptions.

And trust assumptions are where systems fail most often.

References

• OWASP Top 10 – Cross-Site Request Forgery
• OWASP CSRF Cheat Sheet
• RFC 6265 – HTTP State Management
• Real-world bug bounty disclosures on CSRF