Who is accountable when a proxy service exposes internal metadata through SSRF?

Why This Matters for Security Teams

SSRF changes accountability because the risky action is not just user input reaching an endpoint. It is a trusted proxy or application reaching internal systems on someone else’s behalf. That means the owner of the service, the team operating the runtime, and the security function that approved the trust boundary all share responsibility for the blast radius. When the target includes cloud metadata, internal APIs, or service account endpoints, a single missed assumption can expose credentials or control-plane data.

This is why NHI governance and trust-boundary review matter as much as application testing. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now highlights that 97% of NHIs carry excessive privileges, which turns SSRF from a simple input flaw into a privilege exposure event. The control question is not only whether the proxy can be abused, but whether its identity, egress paths, and secret scope were designed for the worst-case internal destination. In practice, many security teams encounter this only after metadata access has already been used to pivot into a broader breach.

How It Works in Practice

Accountability should be assigned across three layers. The application owner is responsible for preventing unsafe fetch behavior, validating nested URLs, and ensuring the proxy cannot reach sensitive internal targets. The platform or infrastructure team owns network egress, metadata access restrictions, and runtime controls such as IMDS protections, service mesh policy, and DNS filtering. The security team owns the review standard for trust boundaries, threat modeling, and release gates that verify the service cannot be coerced into internal access.

In operational terms, the service should be treated as a non-human identity with constrained reach rather than as a generic web app. That means the proxy’s workload identity, credentials, and outbound policy must be designed together. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports least privilege, boundary protection, and continuous monitoring, which maps directly to SSRF prevention. For identity-driven environments, NHIMG’s 52 NHI Breaches Analysis is a useful reminder that compromised service identities are often the real consequence after the initial request smuggling or fetch abuse.

• Block access to link-local and metadata IP ranges by default.
• Restrict outbound destinations to allowlists where the proxy has a legitimate business purpose.
• Use separate credentials for the proxy and revoke any secret that can reach management or metadata endpoints.
• Test nested redirects, encoded inputs, and alternative schemes during pre-release security testing.
• Log outbound request targets, not just inbound input, so detection can show where the proxy attempted to reach.

These controls tend to break down in highly dynamic cloud environments where shared egress, permissive DNS resolution, or legacy metadata access prevents reliable destination enforcement.

Common Variations and Edge Cases

Tighter egress control often increases operational overhead, requiring organisations to balance application flexibility against the need to prevent internal data exposure. The accountability model also becomes less clear in multi-tenant platforms, service meshes, and managed proxy layers, where one team may own the code and another team may own the network path.

There is no universal standard for this yet, but current guidance suggests that the service owner remains accountable for the behavior of the proxy, even when another platform team implements the guardrails. In environments with chained services or agent-like components, an SSRF path can become a lateral movement primitive, so the security review must include what the service can reach after a redirect or internal name resolution event. That is especially important when internal metadata contains short-lived tokens or bootstrap credentials. As Ultimate Guide to NHIs — Key Research and Survey Results notes, secrets hygiene is a persistent gap across enterprises, which makes SSRF exposure more likely to become credential compromise rather than a contained fault.

Where shared responsibility is ambiguous, the practical rule is simple: if the service can initiate the request, that service owner is accountable for preventing unsafe destinations, while the platform and security teams are accountable for making unsafe destinations unreachable.

Related resources from NHI Mgmt Group

• Who is accountable when a privileged OT service account is exposed through SSRF?
• Who is accountable when an AI endpoint exposes IAM tokens through metadata access?
• Who is accountable when internal-only resources are exposed through SSRF?
• Who is accountable when a release workflow publishes malicious code through trusted publishing?