How should application teams design cross-domain access so they do not create SSRF exposure by default?

Application teams should treat any server-side proxy that fetches remote content as a privileged capability, not a convenience feature. The safest pattern is allowlisting exact destinations and request types, then blocking everything else. If a browser needs controlled cross-origin access, use CORS for defined cases. The key principle is to minimize what the server can request on behalf of a client.

Why cross-domain access becomes SSRF when the server fetches on behalf of the client

Cross-domain access is safe only when the browser, API gateway, or integration layer is acting within a tightly bounded trust model. The moment the server is allowed to fetch an arbitrary URL for a user, it becomes a network-capable proxy that can reach internal services, cloud metadata endpoints, and other sensitive targets. That is why default-open fetch behavior is an SSRF problem, not just a convenience feature.

Designing the boundary correctly means separating user-requested data retrieval from server-side network reach. If a request must cross domains, the application should first decide whether the destination is known, necessary, and safe to reach from the server. If the purpose is browser-to-browser access, CORS can define a controlled exception without granting the backend broad outbound capability.

For teams that want a deeper primer on how request scope, authorization, and governance interact, NHIMG’s IAM and IGA Basics helps frame why access should be explicitly bounded rather than assumed.

What secure cross-domain design should allow, and what it should never allow by default

A safe design starts with exact destination allowlisting, exact request-method allowlisting, and strict URL parsing before any outbound call is made. The application should accept only the specific hosts, paths, schemes, and request types it truly needs. If a feature only needs to read a fixed set of partner endpoints, it should not be able to follow redirects, resolve arbitrary DNS names, or pivot to internal ranges.

Equally important, the backend should not be used as a general-purpose relay for arbitrary client-supplied URLs. That pattern makes internal address ranges, link-local targets, and metadata services reachable through a trusted application path. For cloud-heavy environments, the control concern is not just “external website access”, but also whether the server can be tricked into reaching infrastructure that was never meant to be user-influenced.

When the business need is truly browser-originated cross-site access, use CORS for the intended origins and methods rather than building a fetch proxy. CORS limits which browsers may read responses, while a server-side proxy changes the server’s own network authority. Those are not interchangeable controls, and treating them as such is a common design error.

NHIMG’s Capital One breach 2019 illustrates why server-side request reach is a privilege boundary, not a plumbing detail.

Where teams usually get the boundary wrong in practice

The most common failure mode is assuming that “the backend will validate the input” is enough. Validation that only checks for a URL shape does not stop SSRF if the application still accepts attacker-chosen destinations. Another frequent mistake is allowing redirects, because the first URL may look harmless while the redirected target is internal or sensitive.

Teams also underestimate how many secondary paths can turn into SSRF: image fetchers, webhook testers, preview generators, PDF renderers, link unfurlers, and import jobs all tend to fetch remote content. If those features are built to be flexible first and restricted later, the default posture is usually wrong. The safer pattern is to define what may be fetched before the feature is shipped, then make every other destination fail closed.

For teams building platform-wide standards, NHIMG’s The 52 NHI Breaches Report is a useful way to study how exposed credentials and over-broad trust often show up after a proxy-style weakness is abused.

Risk and Threat Considerations

SSRF exposure matters because a server-side fetch path can cross trust boundaries that the browser cannot. Once that path exists, attackers may use it to reach internal services, extract metadata, probe network topology, or pivot into systems that were assumed unreachable from the public application layer.

Failure mechanism: An application accepts attacker-controlled destinations, follows redirects, or reuses broad outbound network permissions, so a request intended for an external resource is turned into an internal or privileged server-side connection.

Impact: The result can be credential theft, internal service exposure, unauthorized data retrieval, and in cloud environments, access to instance or workload metadata that widens blast radius far beyond the original request.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP ASVS	V4 — API and Web Service	Cross-domain fetch endpoints are web-service attack surface and need strict request validation.
Recommendation — Validate outbound request targets, methods, and response handling before allowing server-side fetches.
NIST SP 800-53 Rev 5	AC-4 — Information Flow Enforcement	SSRF prevention depends on enforcing allowed destinations and blocking unintended flows.
	SC-7 — Boundary Protection	Server-side proxies cross trust boundaries and must be constrained to prevent internal reachability.
Recommendation — Enforce information flow rules that restrict which destinations a server may reach. Restrict and monitor network pathways that could expose internal services to untrusted requests.
CIS Controls v8	CIS-12 — Network Infrastructure Management	Outbound proxy behavior and boundary rules are network-control problems with SSRF implications.
Recommendation — Limit egress paths and tightly control network routes used by application services.
ISO/IEC 27001:2022	A.8.20 — Network security	Cross-domain fetches require controlled network communication to reduce unintended exposure.
Recommendation — Limit application network reach to approved destinations and protocols.

Practitioner Guidance

What to verify: Every cross-domain feature should have a documented destination list, request-method list, and redirect policy. If any part of the destination is user-controlled, treat that as a design defect unless it is constrained by an explicit allowlist and a narrowly defined business case.

Decision rule: If the server is making the outbound call, assume the server’s own network reach is at stake and design for deny-by-default. If the browser can do the job with CORS and no privileged backend access, prefer that model over a proxy endpoint.

Common mistake: Teams often secure the visible URL parameter but leave DNS resolution, redirects, internal IP ranges, and metadata endpoints unconstrained. That leaves a “validated” request that is still dangerous in practice.

Practitioner takeaway: Cross-domain access is safe only when the application knows the exact target before any outbound request is made, because every extra degree of fetch freedom becomes a potential SSRF path.