Home / Knowledge hub / SSRF in APIs
Knowledge hub
SSRF in APIs
API features that fetch a caller-supplied address, such as import by URL or webhooks.
What it means
Server-side request forgery, or SSRF, is when an attacker gets your server to send a request to an address they choose. In an API it often hides in features that fetch a URL for the caller: import from a link, a webhook address, a profile picture URL, a link preview or a document converter. Any feature that says "give us a link and we will fetch it" is a candidate, and most products have at least one.
The server makes the request from inside your network, with your network's reach and sometimes your cloud credentials. The caller never needs direct access to the target. That makes the server a stepping stone, and it is why the caller's own access does not limit the damage.
Why it matters
Your server can reach things the internet cannot: internal admin tools, databases, other services and cloud metadata that holds credentials. If a caller can point your fetcher at those, they can read data or trigger actions from behind your firewall. OWASP lists SSRF in its API top ten for this reason.
Cloud environments raise the stakes, because a fetched metadata address can return temporary keys. The result may be a breach that started with an innocent-looking import feature, and it is hard to spot afterwards because the traffic originated from your own server.
How it shows up
Look for any parameter that holds a URL or hostname, then trace what the server does with it. Common mistakes are checking only the text of the address, so a redirect or a DNS trick still reaches an internal target, following redirects freely, and allowing any port or protocol.
Defence works best in layers. Prefer an allowlist of permitted destinations, resolve the address and check the result is not internal, disable redirects or re-check each one, block cloud metadata ranges, and run fetchers with no standing credentials. See SSRF and the metadata service.
Questions people ask
SSRF in APIs, answered
How is SSRF in an API different from normal SSRF?
The weakness is the same. In APIs it tends to hide in machine-to-machine features such as webhook addresses, imports and integrations, where a URL is expected input.
Because these are normal functions, they are easy to skip in review.
Why are webhook addresses a common SSRF route?
Because the feature's purpose is to make your server call a URL the customer supplies. If you do not limit where that URL may point, a customer can aim it inward.
Validate the destination when it is saved and again when it is called.
Does blocking private IP addresses fix SSRF?
It helps but is not enough. Redirects, DNS names that resolve to internal addresses, and alternative address formats can slip past a simple text check.
Check the resolved address at the time of the request, and limit redirects.
Can SSRF steal cloud credentials?
It can, when a server is allowed to reach the cloud's metadata service. The response may include temporary keys for the machine's role.
Requiring a session token for that service and limiting the role's permissions both reduce the damage.
How do we test an API for SSRF?
Find every field that accepts a URL, then supply an address you control and watch for a callback. Try internal addresses and redirects in a safe, authorised test.
A response or timing change that depends on the target is a signal.
Related
Terms that sit next to this one
SSRF
Making your server fetch a URL of the attacker's choosing.
Instance metadata service
A cloud server's local service that hands out its own credentials to whoever asks.
Webhook
A URL you hand to another service so it can call you when something happens.
Allowlist
A list of what you permit, with everything else refused by default.
Cloud credentials leak
Cloud access keys exposed in code, images or logs and then used by others.
Where will your server go if asked?
Import by URL and webhook features are where SSRF hides. We test every field that takes an address and report what your server really reached, with the request and response as proof. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.