Who is accountable when internal-only resources are exposed through SSRF?

Why This Matters for Security Teams

SSRF is not just an application bug when internal-only resources are exposed. It becomes an identity and trust failure because the application is effectively allowed to speak on behalf of the attacker, often with access to metadata services, internal APIs, and management planes. That is why accountability usually spans application owners, platform teams, and cloud security owners. The control failure crosses code review, network policy, and service authentication.

The operational lesson is simple: internal network reachability is not the same as authorization. A service that can reach a backend does not automatically deserve to query it, and a request that originates from a trusted app does not automatically deserve trusted outcomes. NIST’s guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because boundary protection and system and service authentication only work when internal trust paths are explicitly constrained.

NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 97% of NHIs carry excessive privileges, which is exactly why SSRF becomes so damaging: the app or workload identity behind the request often has far more reach than the business intended. In practice, many security teams encounter SSRF accountability only after internal data has already been queried through a trusted service path.

How It Works in Practice

Accountability should follow the control boundary, not just the code owner. Application teams are usually accountable for fixing the vulnerable request path, validating URLs, removing unsafe redirects, and preventing arbitrary outbound fetches. Platform and cloud teams are accountable for reducing the blast radius with egress restrictions, workload segmentation, metadata service hardening, and service-to-service authentication. Security architecture owns the policy model that makes those controls coherent across environments.

At the technical level, SSRF response plans usually rely on three layers:

• Input handling that blocks attacker-controlled destinations, IP ranges, and protocol abuse.
• Network controls that prevent workloads from reaching sensitive internal services unless explicitly required.
• Identity controls that require strong service authentication before any internal resource is treated as trusted.

That last point matters because internal-only resources should still verify the caller. A workload identity should prove what the service is, and policy should decide what it may do at request time. For cloud and container environments, this is the same design logic behind zero trust and workload identity patterns discussed in 52 NHI Breaches Analysis and in standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls.

Security teams should also treat metadata endpoints, internal admin APIs, and service discovery routes as high-value targets, because SSRF often turns one exposed request path into indirect access to many privileged systems. These controls tend to break down in legacy monoliths and flat private networks because internal destinations are implicitly trusted and service authentication is inconsistently enforced.

Common Variations and Edge Cases

Tighter internal access controls often increase deployment and maintenance overhead, so organisations must balance isolation against operational speed. That tradeoff is real, especially in microservices, shared Kubernetes clusters, and multi-account cloud environments where teams depend on east-west connectivity to keep systems working.

There is no universal standard for assigning accountability in every SSRF case, but current guidance suggests responsibility should be shared when the exploit path spans multiple control planes. For example, an app team may own the flaw, while the platform team owns the missing network guardrail and the cloud team owns an overly permissive metadata configuration. If a service account or API key is exposed through the path, NHI governance becomes part of the accountability chain as well.

Where organisations get this wrong is by treating SSRF as a point-in-time bug fix instead of a recurring trust boundary issue. The better question is not only who patched the endpoint, but who approved the internal access path, who reviewed the identity permissions, and who confirmed that sensitive internal resources still require explicit authentication. NHIMG’s The 52 NHI Breaches Report shows how often compromised non-human identities amplify what starts as a seemingly narrow exposure.

In practice, accountability becomes clearest after an incident because SSRF usually exposes the gap between application ownership and platform ownership rather than fitting neatly inside either team’s remit.

Related resources from NHI Mgmt Group

• Who is accountable when a privileged OT service account is exposed through SSRF?
• Who is accountable when exposed edge infrastructure stays vulnerable after disclosure?
• How should teams reduce the risk of exposed AI credentials being abused?
• How should teams respond when CI or developer secrets are exposed?