SSRF hunting
Server-side request forgery is a fetch you do not control. Prove the server made the request with a canary, then decide whether it is metadata, an internal app, or a file handler.
Skill
No skill is linked for this class yet. Start with the playbook on this page.
Practice the class in the browser: PortSwigger Web Security Academy. The lab is theirs. This page is the stop condition and the disclosures.
Checklists
- SSRF - Canary first. Metadata second. File handlers last.
Disclosures
- An SSRF filter allowed a prefix that still maps inside - Server-side request forgery
Playbooks
- SSRF Hunting - Confirm the server requests a host you control. Cloud metadata is a later step, and only when the program allows it. In the 2025 OWASP list, SSRF sits under broken access control.
Payloads
- Server-Side Request Forgery - Point the server inward. Cloud metadata endpoints leak credentials; the bypass block (decimal/hex IP, IPv6, enclosed-alphanumerics, DNS rebinding hosts) defeats common allow-list filters.
Bypasses
- SSRF filter bypass - Defeat allow-list / blocklist URL validation to reach internal or cloud-metadata endpoints. IP-format tricks and parser confusion are the highest-yield.
Questions
When is SSRF actually high impact?
When you can show the server fetched a URL you control, then a second hop to metadata, an internal admin, or a file parser. A DNS callback alone is the primitive, not the report.
Should I hit cloud metadata first?
No. Canary first. Metadata second, and only if the program allows it. IMDSv2 and header-gated metadata are harder gadgets, not 'safe'.
This page is the linked pack hunt_brief("ssrf") returns on the MCP connector. Authorized testing only.