Prevent SSRF in APIs: process target URLs securely

Which function opens the trust boundary?

Typical cases include document import by URL, link previews or an API sending notifications to a customer-registered callback address. The incoming call and later outbound fetch are two separate connections. Authenticating the user does not establish whether they may send your server to every reachable destination. OWASP API7:2023.

First examine the actual path: which component resolves names? Which HTTP client opens the connection? Is there an outbound proxy? Which internal networks, management services and credentials are reachable there? A web application without direct database permissions can still have dangerous network access.

A public destination is not automatically an authorised recipient of confidential information either. For callbacks, destination registration, customer authority and transmitted data must agree. A technically permissible connection does not replace data-sharing authorisation.

Prefer known sources; deliberately isolate arbitrary destinations

The first two variants reduce possible destinations. They are not a blanket ban on customer integrations. In the third variant, the additional effort must form part of the product decision. OWASP similarly distinguishes known permitted applications from the much harder task of fetching arbitrary external destinations. OWASP: SSRF Prevention, ‘Cases’.

Even with a fixed host, construct path and query from allowed components. If users can supply a whole path rather than a document identifier, they might select functions outside the import. Correctly encoding URL components and defining allowed operations are separate tasks.

Treat URL, DNS and connection as one operation

Use a URL parser appropriate to your runtime and check its parsed components. A text-prefix rule such as ‘contains our partner's name’ is not a host check. Permit only required protocols and ports; embedded credentials normally do not belong in a user-defined import target. Reject ambiguous or malformed input.

Name checking alone is insufficient. The same hostname may resolve to different IPv4 or IPv6 addresses. A pre-checked resolution helps little if the connection library resolves again and uses a different destination. Check every address usable by the connection path against your policy and ensure the actual connection cannot bypass that decision.

For a service intended to fetch only public sources, internal, local and link-local address ranges are among those outside its permitted destination space. This includes management and metadata services in your environment. Do not adopt a short handwritten blocklist as a supposedly complete solution. Selecting and maintaining suitable address classification and network rules belongs to implementation.

If a checked destination is pinned for connection, hostname, TLS server name and certificate verification must still remain correct. Simply replacing the URL with an IP and ignoring certificate errors would introduce another weakness. Include proxies and connection pools: what matters is which component actually resolves and connects. This is an integration point for your platform, not a universally usable code block.

Limit redirects and transmitted data

Disable automatic redirects if the feature does not need them. If required, check every new destination against the same policy and limit the number of hops. An approved starting address does not make a redirect destination trustworthy.

Do not transmit credentials or sensitive payloads to a new destination unchecked. This includes request bodies as well as headers. Depending on status and client, a redirect may continue the method with its body. OWASP specifically describes these risks from blindly following redirects when consuming external APIs. OWASP API10:2023.

Allow the fetching service only required methods. A read-only preview normally has no reason to forward arbitrary write methods or credentials belonging to the main service. Also limit response size, decompressed volume, runtime and concurrent fetches. An allowed destination may be slow or return unexpectedly large data.

Received content remains external data. Neither an allowed domain nor successful TLS makes a document automatically safe for parsers, HTML output or further processing. Continue with integrating external APIs securely.

Separate the fetching service from other operations

An additional network boundary limits consequences of faulty application checks. An isolated fetching service, for example, needs no access to internal management interfaces, production databases or every other service's network. It should hold only secrets needed for its narrow task.

Outbound network rules, a suitable egress proxy or equivalent platform features can enforce this boundary. Check both IP families and the actual path. A rule on the wrong container or covering only some connections provides incomplete evidence. Even strict outbound rules do not replace the input decision about which public destinations and data this user may use.

For known partners, destination-range changes may cause operational incidents. Define how required extensions are checked and who approves them. Generously ‘allowing everything temporarily’ should not become the normal response to a failed import.

Verify your safeguards in a controlled way

Create a small decision matrix for the platform. Start with simulated resolution and a connection adapter that merely records which destination would be selected. Suitable cases include an allowed source, unknown host, forbidden protocol, multiple DNS answers containing a forbidden destination, a changed destination at connection time and a redirect outside permission.

Success means that no forbidden connection attempt reaches the adapter. Merely seeing a subsequent error message is insufficient. Add response-size and duration limits. These logical cases do not yet prove actual network isolation.

Then test the real connection path exclusively in an authorised environment of your own with designated test services. No targets were contacted for SSRF testing, no internal addresses tested and no SSRF payload collection executed for this article. A parser example without the network path would not be a reliable protection implementation; this guide therefore contains no such universal recipe.

Introduce a new destination policy first with inventoried permitted integrations. For a legitimate false rejection, correct the specific entry or function. Preserve the last secure configuration. If protection is uncertain, temporarily pausing URL imports may be more appropriate than fully opening destination checks.

What an API check cannot answer here

An ordinary public response check does not inspect where your application later connects server-side. Even SSRF protection in the scanner itself would only protect it against forbidden target calls; it does not mean your API is examined for SSRF.

The API Security Check therefore provides no evidence for this flow. Use code, configuration and your own integration tests along the actual fetching path. Inventory and versioning helps find every import and callback feature; logging and monitoring shows how legitimate rejections remain traceable in operation.

Next steps