CSRF Bug Bounty 2026 — Find, Exploit & Report CSRF That Pays

🎯 BUG BOUNTY COURSE
FREE

Part of the 60-Day Bug Bounty Mastery Course

Day 19 of 60 · 31.7% complete

⚠️ Authorised Testing Only: CSRF testing must only be performed against applications within your authorised bug bounty scope. Never craft CSRF payloads targeting real users — demonstrate impact using your own test accounts only.

CSRF Bug Bounty 2026 :— Every time a user clicks a link or loads a page, their browser dutifully sends all cookies for the relevant domain. CSRF exploits this: an attacker crafts a page that causes the victim’s authenticated browser to make requests to the target application as if the victim initiated them. No credentials needed. No phishing for passwords. Just a link, a forged request, and all the actions the victim’s session is authorised to perform. On Day 19 you learn to find CSRF, bypass the defences that should stop it but often don’t, and chain it into account takeover scenarios that pay High to Critical in most programmes.

🎯 What You’ll Master in Day 19

Identify every state-changing request that could be CSRF-vulnerable

Test CSRF token validation — the 6 bypasses that work in 2026

Understand SameSite cookie protections and their limitations

Build PoC CSRF payloads for GET, POST, and JSON endpoints

Chain CSRF to email change and account takeover for High/Critical severity

⏱️ 50 min read · 3 exercises

📋 CSRF Bug Bounty 2026 — Complete Guide

How CSRF Works and Why It Still Exists in 2026
Finding CSRF — Every State-Changing Request Is a Target
CSRF Token Bypass — 6 Techniques That Work
SameSite Cookies — Understanding the Gaps
Chaining CSRF to Account Takeover

In Day 18 you found CSRF in OAuth flows via missing state parameters. Day 19 covers CSRF as a vulnerability class in its own right — the broader technique that OAuth CSRF is a specific instance of. Understanding CSRF deeply unlocks a finding category that appears in nearly every web application in the 60-Day Bug Bounty Mastery Course.

How CSRF Works and Why It Still Exists in 2026

CSRF exploits the browser’s automatic cookie inclusion behaviour. When a user is authenticated to target.com, every request their browser makes to target.com includes the session cookie — regardless of whether the request originates from target.com or from an attacker-controlled page. The application cannot distinguish between a request the user intentionally made and a request that an attacker’s page caused their browser to make. Without an additional verification mechanism (a CSRF token, or SameSite cookie restriction), the application processes both identically.

CSRF PROOF OF CONCEPT — HTML FORM TEMPLATE

# Basic POST CSRF PoC — use for demonstrating email change vulnerability

</form>

</body></html>

# Auto-submit version (victim never sees the form)

# GET-based CSRF (for GET state-changing actions)

# JSON body CSRF (for APIs with Content-Type: application/json)

# Requires: CORS misconfiguration OR application accepts text/plain

</form>

🛠️ EXERCISE 1 — BROWSER (12 MIN)

Identify CSRF-Vulnerable Endpoints on a Bug Bounty Target

⏱️ Time: 12 minutes · Browser DevTools · in-scope target

Step 1: Log into an in-scope bug bounty target with your test account
Open DevTools → Network tab → check Preserve log

Step 2: Perform every state-changing action you can find:
– Update profile (name, email, phone)
– Change notification settings
– Update password (if current password not required)
– Add/remove 2FA
– Connect/disconnect third-party apps
– Change privacy settings

Step 3: For each request in the Network tab:
□ Is it GET or POST?
□ Does it include a CSRF token parameter?
□ What are the Cookie headers? Do they have SameSite set?
□ Does it accept JSON? Or form-encoded data?

Step 4: Create a shortlist of endpoints with:
– No visible CSRF token → high priority test
– CSRF token present → still test for validation bypass
– SameSite not set → no cookie-level protection

Step 5: For your highest-priority finding, write:
The endpoint URL, HTTP method, parameters,
and why it appears CSRF-vulnerable.

✅ What you just learned: The endpoint mapping exercise reveals that most applications have inconsistent CSRF protection — some endpoints have tokens, others don’t, some have SameSite cookies set correctly, others don’t. The inconsistency is typically because CSRF protection was added to some endpoints over time without a systematic audit. The highest-value targets are account settings endpoints without CSRF tokens: email change, password change (without current password), and OAuth account linking. These are the endpoints where CSRF leads directly to account takeover.

📸 Share your shortlist of potential CSRF endpoints in #day-19-csrf on Discord.

CSRF Token Bypass — 6 Techniques That Work

CSRF TOKEN BYPASS TECHNIQUES

# 1. Delete the token entirely

POST /settings/email (remove csrf_token parameter completely)

# 2. Submit empty token value

csrf_token=

# 3. Use another user’s valid token

csrf_token=[token from your other test account]

# 4. Submit wrong-length token

csrf_token=abc123

# 5. Reuse a previously used (expired) token

csrf_token=[copy token before submission, reuse after]

# 6. Change request method (POST → GET)

GET /settings/email?email=attacker@evil.com&csrf_token=ignored

# For each: does the application return 200 and process the action?

# Any success = CSRF token validation bypass = reportable finding

SameSite Cookies — Understanding the Gaps

SameSite cookie attributes are the modern browser-level CSRF defence. SameSite=Strict never sends cookies on cross-origin requests. SameSite=Lax (now Chrome’s default) sends cookies on top-level GET navigation but not on cross-origin POST. SameSite=None sends cookies on all cross-origin requests (requires Secure flag). The gaps: applications using SameSite=None (often for CORS or embed scenarios), GET-based state changes vulnerable under Lax, subdomains bypassing SameSite restrictions via XSS, and older browsers ignoring SameSite entirely.

🌐 EXERCISE 2 — PORTSWIGGER (20 MIN)

Complete CSRF Labs on PortSwigger Web Academy

⏱️ Time: 20 minutes · Free PortSwigger account

Step 1: Go to portswigger.net/web-security/csrf
Step 2: Complete: “CSRF vulnerability with no defenses”
This confirms the baseline — no token, simple PoC works

Step 3: Complete: “CSRF where token validation depends on request method”
This demonstrates the method-switch bypass (#6 above)

Step 4: Complete: “CSRF where token is tied to non-session cookie”
This shows cookie-based CSRF token weaknesses

Step 5: For each completed lab, note:
– The specific bypass technique used
– The exact PoC HTML you submitted
– What the vulnerability enabled (email change, etc.)

Advanced (if time): “CSRF with broken token validation”
These labs cover every token bypass from the command block above
in an interactive environment with confirmed impact.

✅ What you just learned: PortSwigger CSRF labs teach each bypass in isolation with confirmed exploitation — you know exactly what worked and what the impact was. The method-switch lab is particularly important: many applications validate CSRF tokens on POST but not on GET, and switching the request method bypasses the entire token validation. This single technique has been the bypass in more real bug bounty CSRF reports than any other. The cookie-tied token lab reveals a subtle weakness that is often missed by developers who implement CSRF tokens correctly in concept but store them in cookies instead of server-side sessions.

📸 Screenshot completed CSRF labs and share in #day-19-csrf on Discord.

Chaining CSRF to Account Takeover

Standalone CSRF against a low-impact action (changing notification preferences) is typically Low severity. CSRF against an account settings endpoint that enables account takeover is Critical. The highest-value chains: CSRF on email change → attacker receives verification email → resets password → account takeover. CSRF on disabling 2FA → removes authentication factor from victim’s account. CSRF on OAuth account linking → links attacker’s OAuth identity to victim’s account (the Day 18 attack applied without OAuth-specific bypass).

⚡ EXERCISE 3 — BURP SUITE (12 MIN)

Generate a CSRF PoC Using Burp Suite’s Built-In Tool

⏱️ Time: 12 minutes · Burp Suite · own test account only

BURP CSRF POC GENERATOR

# Step 1: Intercept a state-changing POST request in Burp Proxy

# Step 2: Send to Repeater, confirm it works with your session

# Step 3: In Repeater — Right-click → Engagement Tools → Generate CSRF PoC

# Or: Right-click on request → Generate CSRF PoC

Burp generates an HTML form that replicates the request

# Step 4: Test the token bypass variants

# In the generated PoC, modify/remove the CSRF token and test each bypass

# Step 5: Open the generated PoC HTML in a browser

# while logged in as victim account in same browser

# Confirm the action executed on the victim account

# Step 6: Document for report

cat csrf_poc.html | python3 -m http.server 8080

# Serve PoC locally, load from http://localhost:8080/csrf_poc.html

# Screenshot the victim account state BEFORE and AFTER loading the PoC

✅ What you just learned: Burp’s CSRF PoC generator eliminates the manual work of writing the HTML form — it captures the exact request parameters and produces a ready-to-test PoC in seconds. The before/after screenshot documentation is the evidence chain that makes a CSRF report compelling: screenshot victim account with original email → load PoC from cross-origin page → screenshot victim account with attacker’s email. Two screenshots plus the PoC HTML is a complete, triageable CSRF report. The local HTTP server step is important for testing — browsers block file:// CSRF because it is not a real origin, but localhost:8080 is treated as a proper cross-origin request that proves the attack works from an attacker-controlled domain.

📸 Screenshot your Burp-generated CSRF PoC and the before/after account state in #day-19-csrf on Discord. Tag #csrf2026

🧠 QUICK CHECK — Day 19

An application includes a CSRF token in every POST request. When you delete the token parameter entirely from the request and resubmit in Burp Repeater, the server returns 200 OK and processes the action. What is the finding and what does it mean for severity?

📚 Further Reading

OAuth 2.0 Bug Bounty 2026 — Day 18 covers OAuth CSRF via missing state parameter — the specific CSRF variant in OAuth flows that chains to account takeover via account linking.
Authentication Bypass Hub — The complete authentication bypass category covering CSRF, OAuth, JWT, and session management attacks with chaining examples.
60-Day Bug Bounty Mastery Course — The complete course hub — Day 19 CSRF is part of the authentication vulnerability phase covering Days 16-22.
PortSwigger CSRF Labs — Six interactive CSRF labs covering all bypass techniques — the most effective hands-on practice for mastering CSRF exploitation and understanding every token validation weakness.
OWASP CSRF Prevention Cheat Sheet — The definitive CSRF defence reference — understanding what correct implementation looks like helps identify exactly where implementations fall short during bug bounty testing.

Mr Elite

Owner, SecurityElites.com

The CSRF finding that changed how I approach this vulnerability class was an email change endpoint that had a CSRF token — so I almost moved on. Out of habit I ran the deletion bypass anyway: removed the token from the Burp request, resubmitted. 200 OK. Email changed. The development team had implemented the token generation correctly but had not implemented the server-side validation step. The token appeared in the form, which looked correct to any reviewer, but the server never checked it. This pattern — token generated but not validated — is more common than no token at all, because it passes a cursory security review. Test every token bypass variant on every endpoint. Do not assume presence of a token means presence of validation.

BB Day19: CSRF Bug Bounty 2026 — Find Cross-Site Request Forgery That Pays and Chain It to Account Takeover