What is API7:2023 Server Side Request Forgery and how do you prevent it?

API7:2023 in the OWASP API Security Top 10 is Server Side Request Forgery (SSRF). It happens when an API fetches a remote resource using a URL the user supplied, without validating it. The attacker then makes your server send requests to places they could not reach directly, such as internal services.

How does SSRF work?

Many features need your server to fetch something: a profile picture from a link, a webhook test, a document import, a link preview. If the address comes from the client and the server trusts it, the client controls where the request goes.

OWASP notes that this can happen even when the API is protected by a firewall or a VPN, because the request originates from inside. Successful exploitation can lead to internal service enumeration such as port scanning, information disclosure and bypassed security controls. In some cases it can cause denial of service or turn the server into a proxy that hides malicious activity.

OWASP also distinguishes basic SSRF, where the response is returned to the attacker, from blind SSRF, where the attacker gets no direct feedback. Basic SSRF is easier to exploit, and blind SSRF is harder to detect.

Why is it more common now?

OWASP points to modern development habits: webhooks, fetching files from URLs, custom single sign on, and URL previewers all encourage code that accesses a resource based on user input. Cloud environments add another angle, since internal services such as instance metadata endpoints may sit at addresses that only the server can reach. That makes an SSRF flaw potentially more dangerous than it was in a traditional data center.

What does the weakness look like in code?

You will usually find a function that accepts a URL field, passes it to an HTTP client and returns or stores the result. The missing step is a decision about which destinations are acceptable. Subtle bugs make it worse: different parsers may read the same URL differently, and an allow list check on the text can be bypassed if the HTTP library resolves the address another way. OWASP cites URL parsing inconsistencies as a reason to use a well tested and maintained parser.

Constructed example: the webhook test button

A dashboard lets customers register a webhook. On saving, the server sends a test request and shows the response body. An attacker registers an address that resolves to an internal admin service. The test request succeeds from the server's network, and the response, containing internal configuration data, appears in the dashboard.

The fix has several layers: only allow https and a known port, resolve the host and refuse private and link local address ranges, do not follow redirects, and show only a success or fail result instead of the raw response.

How do you prevent it?

OWASP's guidance for API7:2023 includes:

• Isolate the resource fetching feature in your network, since these features are meant to retrieve remote resources, not internal ones.
• Use allow lists where possible for remote origins, URL schemes and ports, and accepted media types.
• Disable HTTP redirections.
• Use a well tested and maintained URL parser.
• Validate and sanitize all client supplied input.
• Do not send raw responses to clients.

The OWASP SSRF Prevention Cheat Sheet adds more detail for both simple cases and complex ones. Also apply least privilege on the network: if the server only needs to reach three external hosts, a firewall rule saying so stops most abuse even if the code has a flaw.

How to check or apply this

1. Search your API for parameters named url, uri, link, callback, webhook or image, and list each feature that fetches them.
2. For each, document the legitimate destinations and enforce them with an allow list.
3. Block requests to private, loopback and link local ranges after DNS resolution, and re-check on redirects, or disable redirects.
4. Return minimal responses and avoid echoing fetched content back.
5. Restrict outbound traffic from the server with egress rules.
6. Add a test that tries an internal address on every fetching endpoint and expects a refusal.

Static analysis can flag the pattern of user input flowing into HTTP clients, and dynamic testing can check whether internal destinations are refused.

Quick check

Sources

• OWASP API Security Top 10 2023, API7 Server Side Request Forgery
• OWASP Server Side Request Forgery Prevention Cheat Sheet

Last reviewed: 18 October 2026.