📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
⚠️ Authorised Testing Only. This article covers offensive vulnerability techniques including Server-Side Request Forgery (SSRF) and Cross-Site Request Forgery (CSRF). All techniques described are for educational purposes and legal security testing on systems you own or have explicit written permission to test. Unauthorised testing is illegal under the Computer Fraud and Abuse Act, the Computer Misuse Act, and equivalent laws worldwide. Always operate within a programme’s defined scope.
A hunter I know spent three days building a solid report — detailed reproduction steps, impact analysis, the works. He filed it as CSRF. The programme triaged it, came back with a severity downgrade, and paid him $150. Two weeks later, reading someone else’s disclosure, he realised what he’d actually found: an SSRF vulnerability hitting an internal service. Same endpoint, same request manipulation, completely different attack class. That report, filed correctly, would have paid $12,000. The difference between those two payouts is two letters — S and C — and a fundamental misunderstanding of who’s making the request. If you’re hunting bug bounties and you can’t immediately distinguish SSRF from CSRF at the HTTP level, you are leaving serious money on the table. I’ve seen this mistake on HackerOne, on Bugcrowd, and in my own training. It’s one of the most common — and most expensive — classification errors in the game. This article fixes that. And while you’re setting up your testing environment, bookmark the SecurityElites tools hub — the port scanner and DNS lookup tools will come in useful when you’re mapping SSRF attack surface. For programme selection and scope analysis when you’re ready to hunt, the bug bounty pillar is your starting point. Right now, let’s sort out exactly what these two vulnerabilities are, how they differ at the request level, and why programmes treat them so differently on the severity scale.
🎯 What You’ll Be Able to Do After This
Distinguish SSRF from CSRF at the HTTP request level — not just by definition, but by looking at a request and knowing immediately which one you’re dealing with
Identify where each vulnerability lives in a target application and what features to focus on during recon
Understand why SSRF consistently earns critical severity and when CSRF crosses into that same tier
Write bug bounty reports that classify these vulnerabilities correctly — because a misfiled report is a missed payday
⏱️ 18 min read · 3 exercises ### SSRF vs CSRF Bug Bounty— What’s the Difference and Why Both Pay Critical 1. The Core Difference: Who Makes the Request 2. How SSRF Works (And Why It Pays Critical) 3. How CSRF Works (And When It Pays Critical) 4. SSRF vs CSRF Side-by-Side: The Cheat Sheet 5. Writing Reports That Get the Severity Right 6. Exercise 1 — Browser: Map SSRF Attack Surface 7. Exercise 2 — Think Like a Hacker: CSRF Target Analysis 8. Exercise 3 — Browser Advanced: CSRF Token Patterns 9. FAQ Two letters separate these vulnerability names. The attack vectors, the impact profiles, and the payout tiers are completely different. SSRF and CSRF sit at opposite ends of the “who’s doing the attacking” spectrum — and that single distinction is what drives severity scores into critical territory for one and into informational for the other, depending entirely on context. For the full technical deep-dive on each individually, Day 10 covers SSRF and Day 19 covers CSRF in the bug bounty course. This article is what sits between those two — the comparison that teaches you to classify correctly under pressure.
The Core Difference: Who Makes the Request
Here’s the single sentence that will fix your classification problem permanently. CSRF: the victim’s browser makes the request. SSRF: the server makes the request. That’s it. Everything else — severity, impact, where to look, how to exploit — flows from that one distinction.
Most hunters get confused because both vulnerabilities involve manipulating HTTP requests. But they’re being manipulated in completely opposite directions. Let me show you what this looks like at the wire level.
In a CSRF attack, you craft a malicious page or link that triggers the victim’s authenticated browser to fire a request the victim never intended to make. You don’t see the response. You don’t need to. The point is that the victim’s session does something — transfers funds, changes an email address, adds an admin account. The browser is the weapon, and the victim is pulling the trigger without knowing it.
In an SSRF attack, you manipulate a parameter that the server uses to fetch an external resource. Instead of pointing it at the intended destination, you point it at somewhere internal — a cloud metadata endpoint, an internal database, a service that’s only reachable from within the server’s network. The server makes the request on your behalf. You get to see the response. That’s what makes SSRF so devastating — you’re using the server as a proxy into infrastructure that’s completely off-limits to external requests.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)