Server-side request forgery (SSRF) is a vulnerability where an attacker supplies a URL to a feature that fetches it, and the server makes that request from inside the network on the attacker’s behalf. Nineteen SSRF flaws sit in CISA’s Known Exploited Vulnerabilities catalog, seven of them flagged for use in ransomware campaigns.
Most vulnerability classes are a mistake. This one is a feature. Here is server-side request forgery explained from the feature side rather than the payload side: somewhere in the application a field accepts a URL and the server was built to go and get it, because that is the entire point of a webhook, an avatar uploader, a link preview, or an “import from URL” button. Nothing has to be broken for it to work, only pointed somewhere it was never meant to reach.
Key takeaways
- The defect is not that the server made a request. It is that it did not check where the request was going first.
- The value of the attack is where the request originates. A request from your application server carries your network position, your source IP, and often your credentials.
- Any feature that fetches a URL is a candidate: webhooks, image and document processors, PDF renderers, link previews, import-from-URL, SSO metadata fetches, reverse proxies.
- Blocklists of internal addresses are the common defense and the one that keeps failing. OWASP’s guidance is blunt about it: “Deny-lists are bypass-prone. Prefer allow-lists.”
- No response on screen is a detection problem, not a safety property. Blind SSRF is the same bug with the feedback channel removed.
Server-side request forgery, explained in one request
MITRE’s CWE-918 states the whole class in a sentence: “The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.”
The parent entry is the more useful one to hold onto. CWE-918 sits under CWE-441, Unintended Proxy or Intermediary (‘Confused Deputy’), a product that forwards a request without “sufficiently preserving the original source,” so that it “appears to be the source of the request.” That is the deputy problem. Your server has authority the attacker does not, and the attacker is not stealing it. They are asking the server to use it.
Take a link-preview feature. A user pastes https://example.com/article, the server fetches it, reads the title tag, renders a card. Now the user pastes http://127.0.0.1:8080/admin, or http://192.168.10.4:9200/_cat/indices. The fetch runs from inside the perimeter, and as PortSwigger’s Web Security Academy puts it, back-end systems on non-routable addresses “are normally protected by the network topology, so they often have a weaker security posture” and expose “sensitive functionality that can be accessed without authentication by anyone who is able to interact with the systems.”
Whatever a firewall was doing for those services, it was doing it based on where the request came from. The request now comes from a machine on the allowed side.
The common thread is a feature that fetches a URL
It helps to stop looking for SSRF as a bug and start looking for it as a capability. Everywhere below, the server acts on an address it was handed:
- Webhooks and callbacks, where the destination is user-supplied by design, which makes an allowlist commercially awkward and the validation weak.
- Media and document processing. CISA’s Known Exploited Vulnerabilities catalog (the counts here are from version 2026.09.02) carries CVE-2016-3718 in ImageMagick, where the request is triggered “via a crafted image.” The user never typed a URL at all. PDF and HTML renderers behave the same way, resolving every reference in the markup they are handed.
- Identity and federation. CVE-2024-21893 is an SSRF in the SAML component of Ivanti Connect Secure, and it carries CISA’s known-ransomware flag. Metadata fetching is a URL fetch.
- Proxies and gateways. CVE-2021-40438 in Apache HTTP Server is the reverse-proxy case, and CVE-2026-83548 in SonicWall SMA1000 is a pre-authentication SSRF scored CVSS 10.0.
That last one carries a footnote for anyone who classifies findings. CISA names it a server-side request forgery; NVD maps it to CWE-441, the confused-deputy parent, not CWE-918. Both are right. The label moves with whether you describe the outcome or the mechanism, which is one reason SSRF is easy to under-count.
The consensus view of the class is stranger than its raw numbers. SSRF entered the OWASP Top 10 for 2021 as A10 on an incidence rate of 2.72 percent, and it got the slot because it finished first in the community survey. The ratings explain why practitioners put it there: an average weighted exploit rating of 8.28 against an incidence rate under three percent. It does not happen often. It matters enormously when it does.
Why the cloud metadata endpoint changed the stakes
For most of its history SSRF was a reconnaissance bug. Cloud hosting turned it into a credential bug, because every major provider put an unauthenticated HTTP service at one fixed link-local address, 169.254.169.254, and had it hand out the instance’s identity on request. A server that will fetch a URL of your choosing will fetch that one.
The clearest evidence of how seriously that was taken is that a cloud provider redesigned the service. In November 2019 AWS published IMDSv2, which requires a session: a PUT request returns a token, and every later request must carry it. The announcement names the threat directly, reporting that “AWS analysis of real-world vulnerabilities found that this combination protects against the vast majority of SSRF vulnerabilities.”
The supporting layers are a short course in how the attack travels. IMDSv2 “will also not issue session tokens to any caller with an X-Forwarded-For header,” because a reverse proxy adds one, and the token response ships with its IP time-to-live “set to ‘1,’” so it cannot survive a single hop off the instance. Each is a countermeasure to a specific way a request that should have been local got made on someone else’s behalf.
The cost of getting this wrong is on the public record. On August 6, 2020 the Office of the Comptroller of the Currency assessed an $80 million penalty against Capital One for “failure to establish effective risk assessment processes prior to migrating significant information technology operations to the public cloud environment.” The Justice Department’s account of the intrusion describes a misconfigured web application firewall as the way in, and the personal information of more than 100 million people taken as a result.
Blind SSRF, and why no response is not no vulnerability
Plenty of these features never show you what came back. The webhook fires into a queue; the thumbnail job runs on a worker. PortSwigger defines the blind case precisely: it “arises when an application can be induced to issue a back-end HTTP request to a supplied URL, but the response from the back-end request is not returned in the application’s front-end response.”
The honest read is that impact is “often lower than fully informed SSRF vulnerabilities because of their one-way nature,” since data cannot be trivially read back. The common misreading is that a blank screen means nothing happened. The request still left the building, still arrived somewhere internal, and still carried whatever the fetching service’s identity is worth. Where the target has a side effect, a POST that restarts a job or a queue that accepts a message, one-way is enough.
Detection changes rather than disappears. The reliable method is out of band: point the fetch at a host you control and watch for the DNS lookup or the connection. If it arrives, the vulnerability is confirmed, whatever the application chose to render.
Where the control belongs
The OWASP SSRF Prevention Cheat Sheet splits the problem by what the feature is for. Case 1 reaches only “identified and trusted applications,” where an allowlist is both possible and correct. Case 2 must reach “ANY external IP address or domain name,” where “the allowlist approach is not a valid solution” and the fallback is a blocklist that “is not an impenetrable wall.” Which case a feature is in determines everything that follows.
| Approach | What it relies on | How it fails |
|---|---|---|
| Blocklist of internal addresses | The attacker writing an address the way you wrote it | Alternative encodings such as the integer form of a loopback address, and attacker-controlled domain names that resolve to a blocked address. OWASP: “Deny-lists are bypass-prone.” |
| Allowlist of permitted destinations | Knowing every legitimate destination in advance | Fails closed, which is why it is the recommended control. Only workable in Case 1, and it must be built from resolved IP addresses, v4 and v6, not from names. |
| Validating the submitted URL string | Your parser agreeing with the HTTP client that will fetch it | Embedded credentials before an @, fragments, and encoded characters make the two disagree. OWASP advises against accepting complete URLs from users at all. |
| Validate, then follow redirects | The validated host staying the destination | An open redirect on an allowed domain passes the check and forwards the fetch anywhere. Either disable redirect following or revalidate every hop. |
| Resolve the name, then connect to the name | DNS returning the same answer twice | A record can answer with an allowed address for the check and a blocked one for the fetch. Resolve once, validate the resolved address, connect to that address. |
| Network egress policy on the fetching service | Routing rather than parsing | Holds when validation is bypassed, because the internal target has no route. The only layer that does not depend on interpreting a string correctly. |
| Session-authenticated metadata service | The metadata endpoint requiring a token | Removes the highest-value target from a simple fetch. Instance-scoped; it protects credentials, not the rest of the internal network. |
The ordering matters. String validation is the layer everyone writes first and the one bypassed most often, because it asks one parser to predict another. Egress policy and a session-authenticated metadata service keep working after validation is beaten. Treat those as the floor, and the URL check as what keeps the floor from being tested.
One practical note for auditing this. An SSRF cannot be confirmed from the fetching code alone, because the answer depends on what the deployed service can actually reach: which addresses resolve, which redirects are followed, what sits on the internal network that day. It shows up when the request is issued against the running system and the destination is observed, whether or not anything comes back on screen.
The server did exactly what the feature asked. The feature took its instructions from a stranger.
Related readingPart of our series on modern application security testing. Start with What You Should Know About Application Security Testing, then read Reverse Proxy Access Control Testing on the layer that forwards requests in front of your code, and Web Cache Deception on a second defect that exists only in the composition of two correct components.
Frequently asked questions
What is server-side request forgery?
It is a vulnerability where an attacker gets a server to make an HTTP request to a destination of the attacker’s choosing. The application fetches URLs legitimately as part of a feature, and does not sufficiently check where the request is going. Because the request originates from the server, it inherits the server’s network position and can reach internal systems unreachable from the internet.
How does SSRF work in a simple example?
A link-preview feature takes a URL, fetches the page, and shows the title. Supply http://127.0.0.1:8080/admin and the server fetches its own admin interface, which may not require authentication for local requests. Supply an internal hostname and it reaches a service protected by nothing more than not being routable from outside.
Which features in my application are most likely to have an SSRF?
Anything that takes an address and acts on it: webhook and callback registration, image fetching from a URL, PDF and HTML rendering, link previews, import-from-URL, document conversion, XML parsing that resolves external entities, SSO and SAML metadata fetching, and any proxying behavior. The submitted value is not always visibly a URL, as the ImageMagick case shows.
Is blind SSRF still a problem if nothing comes back?
Yes. The absence of a response is a limit on reading data back, not on making the request. The request still reaches an internal destination and still carries the fetching service’s identity, which is sufficient wherever the target has a side effect. Confirm it out of band by pointing the fetch at a host you control and watching for the DNS lookup or connection.
Does blocking 127.0.0.1 and 169.254.169.254 stop SSRF?
No, and OWASP’s prevention guidance says so directly: “Deny-lists are bypass-prone. Prefer allow-lists.” A loopback address can be written in alternative encodings, an attacker can register a domain that resolves to a blocked address, and a redirect from an allowed host can land on one. A blocklist raises the effort; it does not close the class.
What is the difference between SSRF and CSRF?
Who makes the request. In cross-site request forgery the victim’s browser is induced to send it, so the attack borrows the victim’s session. In server-side request forgery the server sends it, so the attack borrows the server’s network position and credentials. Anti-CSRF tokens have no bearing on SSRF: the forged request never comes from a browser.