Plenty of mobile features quietly hand a URL to the backend and ask it to fetch something: import from a link, generate a preview, pull in an image by URL, call a user-supplied webhook. Whenever your server fetches a destination that ultimately comes from the client, you have the ingredients for server-side request forgery. An attacker, using your app's API directly, supplies a URL pointing not at the intended resource but at your own internal services or a cloud metadata endpoint, and your server, trusted inside your network, makes the request for them. Here is what SSRF is in a mobile context and how to prevent it.
Short answer
Server-side request forgery (SSRF) is a vulnerability where an attacker gets your server to make a request to a destination they choose, typically by supplying a URL that your backend then fetches. Per OWASP, which lists SSRF in its API Security Top 10, the danger is that the server, positioned inside your network, can be tricked into reaching internal services, cloud metadata endpoints, or other resources an external attacker could not reach directly. It is relevant to mobile apps because features like import-from-URL, link previews, or webhooks send a client-supplied URL to the backend to fetch. The defense is server-side: validate and allowlist destinations, block private and internal addresses and metadata endpoints, and do not follow redirects blindly.
What you should know
- SSRF makes your server fetch a chosen destination: from a client-supplied URL.
- The target is internal resources: services or metadata an attacker cannot reach directly.
- Mobile features supply URLs: import-from-URL, previews, webhooks.
- The attacker uses your API directly: not just through the app.
- The defense is server-side: validate, allowlist, and block internal addresses.
What is SSRF in a mobile context?
It is tricking your backend into making a request to a destination the attacker controls. Many mobile features involve the server fetching a resource on the client's behalf: the app sends a URL, to import data, generate a link preview, fetch a profile image, or register a webhook, and the backend makes an HTTP request to it. SSRF arises when an attacker supplies a URL that points not at a legitimate external resource but at something they should not be able to reach, and the server fetches it anyway. The key insight is positioning: your backend sits inside your network, so it can reach internal services, admin endpoints, and cloud provider metadata endpoints that are unreachable from the public internet, and SSRF turns the server into a proxy that makes those requests on the attacker's behalf. And because the attacker calls your API directly rather than through the app, any URL the app would send, they can send too, with values the app never would. So SSRF is about the server fetching attacker-chosen destinations from inside your trusted network.
How does SSRF reach internal resources?
By pointing the fetched URL at things only the server can reach. The table lists common targets.
| Target | Why it is dangerous |
|---|---|
| Cloud metadata endpoint | Can expose instance credentials and configuration |
| Internal services | Admin panels or APIs not exposed publicly |
| Localhost | Services bound to the server's loopback interface |
| Private IP ranges | Other hosts inside the internal network |
| Redirect to internal | An allowed URL redirecting to an internal one |
The most damaging classic target is a cloud provider's metadata endpoint, reachable from inside an instance, which can expose credentials and configuration if the server fetches it. Beyond that, an attacker can aim at internal services and admin interfaces that are not exposed to the internet, at localhost services bound to the server's own loopback, and at other hosts in private IP ranges, using the server's network position to probe and reach them. A subtle variant uses redirects: a URL that passes a naive check but then redirects to an internal address, so the server follows it inward. All of these exploit the same thing, the server's privileged position, which is why limiting where the server may fetch matters more than inspecting the URL once.
How do you prevent SSRF?
Constrain what the server is allowed to fetch, and enforce it on every fetch. The strongest control is an allowlist: permit the server to fetch only destinations you explicitly allow, by host or domain, rather than trying to blocklist bad ones, since allowlisting fails closed. Where an open destination is unavoidable, validate the URL and resolve it, then block requests to private and internal IP ranges, to localhost and the loopback interface, and to cloud metadata endpoints, so the server cannot be steered inward. Do not follow redirects blindly; re-validate the destination after any redirect, since a permitted URL can redirect to an internal one. Restrict the URL schemes you accept to what you need, typically HTTPS, and avoid passing the fetched response back to the client raw, which can leak internal data. Apply these checks on the server for every client-supplied URL it fetches, remembering the attacker calls your API directly, and consider network controls so the backend cannot reach sensitive internal endpoints in the first place. The principle is that the server should fetch only destinations you have decided are safe, never an arbitrary URL from a request.
What to watch out for
The first trap is fetching a client-supplied URL with no destination restriction, the core SSRF bug; allowlist where the server may go. The second is blocking obvious internal addresses but missing redirects, alternate IP encodings, or the cloud metadata endpoint; validate after redirects and block internal ranges thoroughly. The third is returning the fetched content to the client raw, leaking internal responses. SSRF is enforced in your backend, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the binary against OWASP MASVS, surfaces the API endpoints your app calls, including any that take a URL to fetch, as the surface to protect, while the allowlisting and internal-address blocking are yours to implement server-side.
What to take away
- SSRF tricks your backend into making a request to an attacker-chosen destination, typically via a client-supplied URL the server fetches, reaching internal resources from its trusted position.
- It is relevant to mobile apps through features like import-from-URL, link previews, and webhooks, and the attacker supplies URLs by calling your API directly.
- Prevent it by allowlisting permitted destinations, blocking private and internal addresses, localhost, and cloud metadata endpoints, re-validating after redirects, and not returning fetched content raw.
- SSRF is enforced server-side; use a pre-submission scan such as PTKD.com to surface the endpoints your app calls, including URL-fetching ones, then protect them on the backend.
