Design an outbound fetch service that contains SSRF

Decide which destinations the feature actually needs

An outbound fetch service needs to authorize the destination it will actually contact, not merely accept a URL that looks harmless. That decision must survive parsing, DNS resolution, proxy behavior and redirects. The worker should also have narrower network and credential authority than the surrounding application. These controls address server-side request forgery, in which untrusted input causes a server to make requests outside the authority intended for the feature. ^[1][2]

Start with the product requirement. A service that fetches documents from a small set of approved partners can use a destination allowlist tied to those partners. A preview service that accepts arbitrary public URLs needs a different policy and carries different residual risks. OWASP explicitly separates these cases in its prevention guidance. Do not adopt arbitrary external fetching merely because a general-purpose HTTP client makes it easy, or promise that a short hostname list can serve a feature whose requirements are broader. ^[1]

Consider a hypothetical document-preview feature. The main application can reach internal services and carries credentials for its own APIs. Giving that process an unrestricted fetch function exposes more request authority than the preview feature needs. A proposed design uses a dedicated worker that receives a limited fetch request, enforces its destination policy and returns a bounded representation. The example is an architecture proposal, not a claim that a particular deployment has been tested.

Define what the fetch request is allowed to contain. The caller may need to supply a URL, but it usually should not control arbitrary authentication headers, cookies, proxy settings or a request body. Choose the required methods and supported response types explicitly. The more client configuration the feature accepts from untrusted input, the more of the HTTP client's authority becomes part of the authorization surface. Keep unnecessary options outside the request contract.

A successful fetch does not establish that the destination was appropriate. The acceptance question is whether the service contacted an authorized destination using the intended method, credentials and resource limits. A response from an internal endpoint can be technically successful while violating that contract. This is why the procedure below treats connectivity and authorization as separate observations rather than measuring success only through an HTTP status code.

Authorize a parsed destination instead of a string

Use a well-defined URI parser and evaluate the parsed components. RFC 3986 distinguishes the scheme, authority, path and other URI components; the authority can contain user information, a host and a port. A policy that searches the original string for an approved hostname can misinterpret those components. Decide which schemes, host forms and ports the feature supports, and reject unsupported structures before network access rather than trying to repair every ambiguous input. ^[6]

For known destinations, tie the allowlist to the actual service contract. An approved hostname may still expose more paths or methods than the feature requires. The application should decide whether a partner integration needs the entire origin or only a constrained operation. OWASP recommends allowlisting when the required destinations can be identified. The local policy should make that list reviewable and explain who can change it, rather than hiding an expanding set of exceptions inside URL-validation code. ^[1]

For arbitrary public destinations, address classification becomes necessary but remains insufficient. The policy should consider both IPv4 and IPv6 and the relevant special-purpose ranges, including destinations that are not appropriate for the worker's external-fetch role. IANA's registries describe address properties; they are authoritative classification inputs, not a ready-made list of application-safe servers. An address classified as globally reachable can still belong to an organizational system that the feature should not contact. ^[4][5][8]

Evaluate the resolver's complete relevant result set under the chosen policy. A hostname can yield addresses from more than one family, and a check that covers only IPv4 leaves the IPv6 path unexplained. The HTTP client may choose a different address from the one the validation code happened to inspect. OWASP's guidance discusses DNS and address-validation concerns for this reason. The policy must remain connected to the address selection that the actual client uses. ^[1]

Keep organizational restrictions separate from public registry facts. A company may have publicly addressed administrative endpoints, private routing arrangements or proxy-mediated destinations that are sensitive in its environment. IANA cannot supply that local authorization policy. Record those restrictions with an owner and an update process. Do not claim that excluding a few familiar private ranges establishes a complete SSRF boundary for every cloud and network design.

Canonicalization also needs consistency. The parser used for policy decisions and the component that constructs the outgoing request must agree on what the destination means. If one normalizes a host or address differently from the other, the checked value can diverge from the contacted value. OWASP's implementation guidance highlights parser and address-family pitfalls. Validate the chosen library behavior with controlled cases instead of publishing a universal regular expression as a complete defense. ^[1][3]

Carry the authorization into the actual connection

A DNS check made before the HTTP request is not enough if the client later resolves the hostname again without the same restriction. The result may change between validation and connection, or the client may select another address. The design should bind the authorization decision to the address actually used for the connection. This is the essential operational consequence of OWASP's DNS rebinding and pinning guidance, not a guarantee supplied by the initial URL parser. ^[1][3]

Choose a client or connection layer that can preserve that relationship while still performing correct TLS server-name verification. Connecting to a validated address must not become an excuse to disable certificate or hostname checks. The intended server name and the permitted network address serve different purposes. Verify how the actual library supports that combination and test it against owned endpoints. This article does not offer a supposedly universal client snippet whose resolver behavior has not been checked.

Proxies can move the relevant decision. If the outbound proxy performs its own destination resolution, an address checked in the application may not be the address the proxy contacts. The authorization boundary must therefore be enforced at the point that resolves and connects, or through a contract that reliably constrains that point. Inventory system proxy settings, service-mesh routing and managed outbound services rather than assuming that the application socket is the final network authority.

Redirects create new requests and need new decisions. OWASP recommends disabling automatic redirect following where appropriate; when the feature requires redirects, revalidate each permitted hop before sending it. The next Location value can change the scheme, hostname, port or path. A policy that validates only the first URL and then delegates unrestricted redirects to the HTTP client does not preserve its original destination boundary. ^[1][7]

Review the method and credentials on a redirect as well as the destination. HTTP redirect behavior varies by status and client policy, and the feature should not forward ambient application credentials to a newly selected origin. Prefer a request contract that supplies no unrelated cookies or authorization headers in the first place. If a known partner integration needs credentials, scope them to that integration and define how redirects are handled rather than extending credential authority to arbitrary external fetching. ^[7]

Use a total request budget across the chain. A per-hop timeout can still allow a long sequence of redirects or retries to consume more time than the caller intended. Set a supported maximum redirect count and an overall deadline based on the feature's requirements, then test cancellation behavior. These are proposed operational controls, not benchmark-derived values. The article deliberately supplies no invented universal timeout that would fit every document size and network condition.

The data-flow figure marks the connection and redirect boundaries separately because both can invalidate an earlier decision. A URL may pass the initial policy, resolve to an approved address and still leave the contract on a later hop. The implementation's evidence should identify the destination decision for the request actually sent, with sensitive input minimized in logs and no assumption that the first hostname describes the whole exchange.

Source. OWASP SSRF Prevention Cheat Sheet ^[1]; RFC 3986 URI syntax ^[6]; RFC 9110 HTTP semantics ^[7]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 1 accessible table

Boundary	Input	Decision	Output
Parse	Untrusted URL	Allowed URI structure and scheme	Canonical destination candidate
Authorize	Host, port and requested function	Known-host or public-destination policy	Approved destination intent
Resolve	Hostname	All address-family results satisfy policy	Validated connect addresses
Connect	Validated address and original server name	Preserve address authorization and TLS verification	Bound connection
Redirect	Location and next method	Reauthorize the next hop or refuse	Approved next request
Return	Response stream	Duration and size limits	Bounded response without ambient credentials

Figure 1 accessible table

Boundary	Input	Decision	Output
Parse	Untrusted URL	Allowed URI structure and scheme	Canonical destination candidate
Authorize	Host, port and requested function	Known-host or public-destination policy	Approved destination intent
Resolve	Hostname	All address-family results satisfy policy	Validated connect addresses
Connect	Validated address and original server name	Preserve address authorization and TLS verification	Bound connection
Redirect	Location and next method	Reauthorize the next hop or refuse	Approved next request
Return	Response stream	Duration and size limits	Bounded response without ambient credentials

Download imageDownload table CSV

Give the fetch worker a narrow response contract

Place network restrictions around the worker in addition to application validation. OWASP treats network-layer controls as a complementary defense, especially where a server could otherwise reach internal resources. The worker should have only the outbound access needed for its defined function. That does not replace parsing or redirect policy, but it reduces the authority available if an application-level check fails. Review the actual route and enforcement point rather than treating an architectural box labeled isolated as proof. ^[1]

Do not give the worker unrelated cloud or application credentials. A document-fetch feature should not automatically inherit the main application's administrative identity, service cookies or internal authentication headers. If the runtime needs an identity for its own storage or queue access, scope that identity to those operations and keep it out of outgoing fetch requests. This is a design recommendation derived from the SSRF authority problem: the feature should carry only the authority it needs.

Define what comes back to the caller. Returning an unrestricted response body can expose more data and resource consumption than a preview feature requires. Set limits for response size, processing time and supported representation, using controls available in the chosen client and parser. If decompression or document parsing changes the amount of data processed, test the relevant limit at that stage as well. A bound on one stream is not proof that every later transformation is bounded.

Treat fetched content as untrusted input. Destination authorization answers whether the worker may contact a server; it does not certify the safety of a returned document, markup fragment or model-readable instruction. The application still needs appropriate validation before rendering, parsing or acting on the result. Keep that downstream responsibility explicit so the fetch service does not become an informal trust label attached to everything it downloads.

Separate known authenticated integrations from anonymous arbitrary fetching when their authority requirements differ. One route may have an approved partner, a narrowly scoped credential and a specific response contract. Another may allow public documents but no application credentials. Combining them behind an unrestricted configuration object makes it harder to reason about which rules apply. A small number of explicit feature contracts is easier to test than a general-purpose HTTP client exposed as a service.

The worker's own logs should support a policy investigation without retaining unnecessary secrets or sensitive document contents. Record the decision reason, relevant destination classification, redirect outcome and resource-limit result in the organization's approved form. If a URL can contain confidential query parameters, handle that data deliberately. Observability should explain why a fetch was allowed or denied, not create a new uncontrolled copy of the material being fetched.

Test each bypass path on infrastructure you control

Build the test suite with owned or explicitly authorized endpoints. There is no need to probe real internal services, cloud metadata endpoints or third-party infrastructure to verify the policy machinery. Controlled servers and resolver fixtures can represent the relevant cases while keeping the exercise bounded. Every test should identify the request contract, expected decision and observation that proves whether a network request was sent.

Start with parser and policy cases. Include an unsupported scheme, a disallowed port, unexpected user information, an unapproved host and the address-family combinations relevant to the implementation. Test the parsed result and the outgoing destination together. A validator returning false is useful, but a complete denied-path test also confirms that the client did not make an unintended request. Keep the expected result distinct from an actual recorded result until the test runs. ^[1][3][6]

Test resolution changes and address selection through the client's real connection path. The controlled setup should show whether the validated address remains the one used by the connector or proxy. If the library performs an additional resolution, the test should expose that behavior instead of assuming it away. Verify TLS name checking at the same time so a fix for destination binding does not quietly weaken server authentication.

Exercise redirects to both allowed and disallowed next hops. Confirm that a denied hop stops before the next request, that credentials are not forwarded outside their scope and that the total redirect or time budget is enforced. Use response codes and methods supported by the feature's documented contract. RFC 9110 supplies HTTP semantics, but the actual client's redirect behavior still needs implementation-specific verification. ^[7]

Test bounded responses and cancellation. A controlled endpoint can return a response larger than the permitted representation or delay its response beyond the configured deadline. Observe whether the worker stops the relevant network and processing work, and whether the caller receives a useful failure without leaked content. Do not infer production performance from this fixture. The test establishes enforcement behavior for a particular implementation, not a throughput or latency benchmark.

Retain a compact evidence record for each policy boundary and repeat the affected cases when the parser, HTTP client, proxy or resolver changes. The decision tree is a conceptual test framework, not a list of attacks performed against a live environment. Its value is that a reviewer can trace every new outbound request through the same explicit authorization questions.

Source. OWASP SSRF Prevention Cheat Sheet ^[1]; IANA IPv4 special-purpose registry ^[4]; IANA IPv6 special-purpose registry ^[5]; RFC 9110 HTTP semantics ^[7]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 2 accessible table

Question	If yes	If no
Does the URI use an allowed scheme and port?	Evaluate destination policy	Reject before network access
Does the destination meet the selected host or public-address rule?	Resolve and check all address families	Reject the destination
Will the connection use the validated address with correct TLS checks?	Make the bounded request	Reject or use a supported client path
Is a redirect permitted and independently reauthorized?	Evaluate the next hop from the start	Stop redirect processing
Does the response stay within the contract?	Return the bounded result	Abort and record the policy reason

Figure 2 accessible table

Question	If yes	If no
Does the URI use an allowed scheme and port?	Evaluate destination policy	Reject before network access
Does the destination meet the selected host or public-address rule?	Resolve and check all address families	Reject the destination
Will the connection use the validated address with correct TLS checks?	Make the bounded request	Reject or use a supported client path
Is a redirect permitted and independently reauthorized?	Evaluate the next hop from the start	Stop redirect processing
Does the response stay within the contract?	Return the bounded result	Abort and record the policy reason

Download imageDownload table CSV

Document what the boundary still cannot promise

Arbitrary public fetching retains risk even when the destination policy works. Public servers can return hostile content, consume resources or behave differently over time. Address classification does not establish business trust, and a permitted HTTP request does not establish that its response is safe to display or act upon. State the remaining processing controls and ownership rather than presenting SSRF prevention as a single completed checkbox. ^[1][4][5]

Document unsupported behavior clearly. If the worker refuses unusual schemes, authenticated redirects or response formats that cannot be bounded safely, those limits are part of the feature contract. A future request to relax them should trigger a design review and new tests, not an ad hoc exception in validation code. Keep the implementation narrow enough that its permitted authority can still be explained.

The decisive question is whether the request that left the worker was the request the policy authorized. Parsing, DNS checks, connection binding, redirect handling and network restrictions each support that answer. A dedicated fetch service is useful when those relationships are explicit and observable, with no implied guarantee about destinations or content outside its stated contract.