An SSRF attack turns a server into your proxy. You feed the application a URL, the application fetches it for you, and suddenly you are reaching internal systems the firewall was built to hide. Server-Side Request Forgery is one of the most impactful web bugs of the cloud era, because a single vulnerable "fetch this URL" feature can expose an entire internal network. The fastest way to understand it is to break one yourself, so open HackerDNA's SSRF Validator lab and follow along as you read.
SSRF is a headline entry in the OWASP Top 10. It earned its own slot in the 2021 list and, in the 2025 revision, was folded into Broken Access Control because the root cause is the same: the server makes a request it should never have been allowed to make. This guide covers what SSRF is, how the attack works step by step, the payloads that matter, and how to shut it down in your own code.
TL;DR: An SSRF attack abuses a server-side feature that fetches a URL, tricking the server into requesting an address the attacker chooses. Point it at http://169.254.169.254 on a cloud host and you can steal instance credentials; point it at http://localhost:6379 and you reach internal services no external user should touch. The fix is not input validation alone, it is a strict allowlist of destinations plus blocking access to internal IP ranges and cloud metadata endpoints. Practice the full attack in a browser lab before you try to defend against it.
What Is SSRF?
Server-Side Request Forgery (SSRF) is a web vulnerability where an attacker makes a server send HTTP requests to a destination the attacker controls. Instead of the attacker's own machine reaching a target, the vulnerable server does it, using its own network position, IP address, and trust relationships.
The danger comes from where the server sits. Application servers usually live inside a network, behind the firewall, next to databases, internal APIs, admin panels, and cloud metadata services. Those systems trust traffic from the application server because it is "inside." SSRF hands an outsider that inside position.
The vulnerable pattern is any feature that takes a URL or hostname from user input and fetches it: webhook senders, URL preview generators, PDF or image renderers that load remote resources, "import from URL" uploaders, and open-graph link unfurlers. Each one is a request the server makes on your behalf, and if you control the target, you control where the server points its own trusted connection.
Where SSRF Shows Up
- URL fetchers - "enter an image URL" or "import from link" fields that pull remote content server-side.
- Webhooks - integrations that POST to a user-supplied callback URL are SSRF by design if the destination is not restricted.
- Document and image processors - HTML-to-PDF converters that follow
<img>and<iframe>sources are a classic blind SSRF surface. - Analytics and preview tools - link unfurlers that fetch a page to build a preview card will happily fetch internal pages too.
How an SSRF Attack Works
An SSRF attack has three moving parts: a feature that fetches a URL, an input you control, and a destination the developer never intended you to reach. The flow is short.
- Find the fetch. Locate a parameter that makes the server request a URL. It might be obvious (
?url=https://example.com/logo.png) or hidden inside JSON, a webhook config, or an XML document. - Redirect it inward. Replace the external URL with an internal target:
http://localhost/admin,http://127.0.0.1:8080, or a private range likehttp://10.0.0.5. - Read the response, or infer it. If the server echoes the fetched content back to you, that is in-band SSRF and you see the result directly. If it does not, you fall back to timing and error differences to confirm the request happened. That is blind SSRF.
Consider a preview feature that calls GET /api/preview?url=https://site.com. The server fetches whatever URL you pass. Send url=http://169.254.169.254/latest/meta-data/ and, on an unprotected AWS instance, the server returns its own cloud metadata. That is the whole attack: you never touched the internal network, the server reached in and handed you the result.
In practice, the first thing worth testing is a URL you control, like a request-logging endpoint. If the target server connects to it, you have proven the fetch happens server-side and the SSRF is real before you spend time on internal targets. It also tells you the server's egress IP, which is useful context for the rest of the test.
In-Band vs Blind SSRF
SSRF splits into two families based on whether you can see the response. The distinction decides your entire testing approach.
In-Band SSRF
In-band SSRF returns the fetched content directly in the HTTP response. You send url=http://localhost/admin and the admin page comes back in the reply. This is the loud, easy case: you read internal responses as plainly as if you had browsed to them yourself. Cloud metadata theft and internal admin-panel access usually happen through in-band SSRF.
Blind SSRF
Blind SSRF makes the server send the request, but the response never comes back to you. The server fetches your URL and discards the body, so you cannot read internal pages directly. It is still dangerous. You confirm it with an out-of-band interaction (point the server at a domain you monitor and watch for the DNS lookup or HTTP hit), then exploit it through side effects: triggering internal actions, port scanning by timing, or reaching services that act on a request without needing to return a body.
Strong opinion: do not write off a blind SSRF as low severity out of habit. Blind SSRF against a cloud metadata endpoint that accepts a request and performs an action, or against an internal service with a dangerous GET handler, can be every bit as serious as the in-band version. The lack of a visible response limits your convenience, not the impact.
SSRF Payloads and Attack Examples
The value of an SSRF depends entirely on what the server can reach that you cannot. These are the targets that turn a "fetches a URL" bug into a real incident.
Cloud Metadata Endpoints
The highest-value SSRF target on a cloud host is the instance metadata service. On AWS, Azure, and Google Cloud it lives at the link-local address 169.254.169.254 and, on older configurations, serves temporary credentials to anything that asks from the instance itself.
# AWS IMDSv1 - dump the instance role credentials
http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Google Cloud - requires a header, but SSRF in a proxy can add it
http://metadata.google.internal/computeMetadata/v1/On an instance still allowing IMDSv1, those credentials let an attacker act as the server's cloud role. This single request is why SSRF is treated as a critical-severity finding on cloud infrastructure, and why AWS pushed IMDSv2 (which requires a session token) as the default.
Internal Services and Port Scanning
Point the fetch at loopback and private ranges to reach services that never expected external traffic:
# Internal admin interfaces
http://127.0.0.1:8080/admin
http://localhost/server-status
# Unauthenticated internal data stores
http://127.0.0.1:6379 # Redis
http://127.0.0.1:9200 # ElasticsearchBy varying the port and measuring response time or error type, you can map which internal ports are open, using the vulnerable server as a scanner it did not sign up to be.
Filter Bypasses
Most SSRF defenses are naive blocklists that check for the strings 127.0.0.1 or localhost. They fall to trivial encoding tricks, which is exactly why blocklists are the wrong approach:
http://127.1 # short form of 127.0.0.1
http://2130706433 # 127.0.0.1 as a decimal integer
http://[::1] # IPv6 loopback
http://0177.0.0.1 # octal notation
http://localhost.attacker.com # DNS record that resolves to 127.0.0.1The file://, gopher://, and dict:// schemes widen the attack further, letting SSRF read local files or craft raw packets to internal services when the fetching library supports them.
SSRF vs CSRF: They Are Not the Same
SSRF forges a request from the server; CSRF forges a request from the victim's browser. The names look alike and the acronyms trip people up in interviews, but the two attacks target opposite ends of the connection.
- SSRF (Server-Side Request Forgery) - the attacker abuses the server to reach internal systems. The server is the confused deputy making requests on the attacker's behalf.
- CSRF (Cross-Site Request Forgery) - the attacker abuses a logged-in user's browser to perform actions on a site where the user is authenticated. The victim's browser is the confused deputy.
SSRF gives you reach into a network; CSRF gives you actions under someone else's session. For the full breakdown of client-side request forgery and its cousin cross-site scripting, see our guide on XSS vs CSRF.
How to Prevent SSRF
How do you prevent SSRF? Enforce a strict allowlist of permitted destinations, block requests to internal IP ranges and the cloud metadata endpoint, and resolve then validate the hostname before the request is made. Input filtering alone does not work, because encoding and DNS tricks defeat every blocklist.
Layer these controls, since no single one is enough on its own:
- Allowlist, do not blocklist. Permit only the specific domains or IPs the feature legitimately needs. Everything else is denied by default. This is the one control that actually holds up.
- Block internal ranges. Reject requests to
127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16, and the link-local169.254.0.0/16that covers cloud metadata. - Resolve before you fetch. Resolve the hostname to an IP, check that IP against your rules, then request that exact IP. This closes the DNS-rebinding gap where a name passes validation but resolves to something internal at fetch time.
- Enforce IMDSv2. On AWS, require session-token-based instance metadata so a bare SSRF GET cannot lift credentials. It is a free, high-impact mitigation.
- Disable dangerous schemes. Allow only
httpandhttps. Rejectfile://,gopher://,dict://, and friends outright.
When testing real applications, the mitigation that fails most often is the "resolve before you fetch" step. Teams add an allowlist and a private-range block, then validate the hostname string but fetch the URL fresh, letting a DNS record flip between the check and the request. Validate the resolved IP, and fetch that IP, not the name.
SSRF in the OWASP Top 10
SSRF has an unusual history in the OWASP Top 10. The 2021 edition promoted it to its own dedicated slot, A10, largely on the strength of the community survey that flagged it as a rising concern for modern, cloud-connected applications.
In the 2025 revision, SSRF lost its standalone entry and moved inside Broken Access Control. This was a reclassification, not a demotion: the data showed SSRF fits naturally as an access-control failure, since it is fundamentally the server making a request it should not have been authorized to make. The OWASP write-up and the corresponding CWE-918 entry remain the reference definitions.
For the full picture of where SSRF sits among the ten risks and what changed between the 2021 and 2025 lists, our OWASP Top 10 guide maps every category with a worked example. SSRF also shows up constantly in API testing, where a server-side fetch parameter is a common finding, which you can drill in the API Breaker lab.
Legal and Ethical Considerations
Critical reminder: Always get explicit written authorization before testing any system for SSRF. Making a server fetch internal URLs on a target you do not own is unauthorized access under the Computer Fraud and Abuse Act (US), the Computer Misuse Act (UK), and equivalent laws in most countries.
- Test for SSRF only on systems you own, in dedicated labs, or within the defined scope of an authorized engagement.
- Cloud metadata credentials are live secrets. If you retrieve them during an authorized test, treat them as sensitive findings, do not use them beyond proof of impact, and report them immediately.
- Blind SSRF confirmation should use a collaborator endpoint you control, never a third party's infrastructure.
- Practice on intentionally vulnerable targets, not random internet applications. The labs below exist for exactly this.
Frequently Asked Questions
What is an SSRF attack in simple terms?
An SSRF attack tricks a server into making a web request to a destination the attacker chooses. Because the server sits inside the network, the attacker can reach internal systems, cloud metadata services, and admin panels that a normal outside user could never connect to directly.
What is the difference between SSRF and CSRF?
SSRF forges a request from the server, letting an attacker reach internal systems. CSRF forges a request from a logged-in victim's browser, letting an attacker perform actions under that user's session. SSRF targets the server side; CSRF targets the client side.
Why is the IP 169.254.169.254 important in SSRF?
That link-local address is the cloud instance metadata endpoint on AWS, Azure, and Google Cloud. On instances still allowing the older IMDSv1, an SSRF request to it can return temporary credentials for the server's cloud role, turning a URL-fetch bug into full cloud account access.
How do you prevent SSRF?
Use a strict allowlist of permitted destinations rather than a blocklist, reject requests to internal and link-local IP ranges, resolve the hostname and validate the resolved IP before fetching it, allow only http and https schemes, and enforce IMDSv2 on AWS so metadata cannot be lifted by a bare request.
What is blind SSRF?
Blind SSRF is when the server makes the attacker-controlled request but does not return the response body. You confirm it with an out-of-band interaction, such as a DNS or HTTP callback to a domain you monitor, then exploit it through side effects like triggering internal actions or timing-based port scanning.
Part of the OWASP Top 10 series
Related articles:
- SQL Injection Tutorial
- XSS vs CSRF
- OWASP Web Security Testing Guide
- SSRF Attack Explained
- Web Application Penetration Testing
Your Next Steps
SSRF clicks the moment you exploit one yourself: point a server at its own metadata endpoint, watch credentials come back, and the reason this bug is rated critical stops being abstract. Reading about the 169.254.169.254 trick is one thing, bypassing a real filter to reach it is another. Start with HackerDNA's free tier, no credit card required, and break your first server in the SSRF Validator lab. When you want SSRF in the context of the full attack surface, the Web Attacks course walks through it alongside SQL injection, XSS, and the rest of the OWASP Top 10 in guided browser labs. Learn how the server can be turned against its own network, then go build the allowlist that stops it.
