SSRF

Server Side Request Forgery is a flaw where an application fetches attacker controlled URLs or network locations on behalf of the server. In JSON-RPC systems, a method that accepts a URL, host, or callback target can be abused to reach internal services, metadata endpoints, or other restricted infrastructure.

Expanded Definition

SSRF is an application-layer abuse pattern where a server is induced to make outbound requests the attacker should not control. The risk is not limited to simple URL fetching. Any feature that accepts a host, callback endpoint, webhook target, file source, or remote import path can become a request pivot. In practice, SSRF often becomes more severe when the application can reach internal services, cloud metadata endpoints, administrative APIs, or flat network segments that are otherwise inaccessible from the internet.

For security teams, SSRF sits at the intersection of input validation, egress control, and trust boundaries. It is best understood as a server-to-server trust failure rather than a browser-side injection issue. Guidance across the industry is still evolving on how aggressively to classify variants such as blind ssrf, cross-protocol SSRF, and cloud metadata abuse, but the core defensive principle is stable: do not let untrusted input determine privileged network destinations. The NIST Cybersecurity Framework 2.0 is useful here because SSRF maps directly to weaknesses in protective architecture, asset control, and monitoring.

The most common misapplication is treating SSRF as a simple URL allowlist problem, which occurs when teams block obvious external domains but leave internal ranges, redirect chains, or alternate schemes reachable.

Examples and Use Cases

Implementing SSRF defences rigorously often introduces friction for legitimate integrations, requiring organisations to weigh user flexibility against tighter destination controls, proxy restrictions, and request verification.

• A document preview feature fetches a user-supplied URL and is abused to request internal admin panels or localhost-only services.
• A webhook registration API accepts a callback URL and is redirected toward cloud instance metadata, exposing temporary credentials or tokens.
• An image import service resolves remote sources and follows redirects into private IP ranges that should never be reachable from the application tier.
• A JSON-RPC endpoint accepts a URL parameter for background processing and is used to probe internal APIs, configuration services, or other restricted systems.
• A partner integration calls back to attacker-controlled infrastructure and is leveraged as a relay to reach non-public network paths.

Effective analysis usually starts with whether the application makes outbound requests at all, then whether it can be forced to reach sensitive destinations. OWASP’s SSRF guidance is useful for recognising patterns such as redirect abuse, DNS rebinding, and metadata endpoint targeting, while the broader attack surface is often clarified by observing request destinations rather than only inspecting the original input.

Why It Matters for Security Teams

SSRF matters because it converts a public application into a network reachability proxy. Once exploited, the issue can expose internal-only services, bypass segmentation assumptions, and turn modest application flaws into infrastructure compromise. This is especially important in cloud environments where metadata services, control plane APIs, and service-to-service trust can be reachable from compromised workloads.

For defenders, SSRF is not only an application security issue but also a governance issue. Egress filtering, DNS policy, service identity design, and logging all affect whether an attacker can pivot after triggering a request. Teams should validate whether outbound calls are constrained to approved destinations, whether redirects are controlled, and whether internal address space is blocked at multiple layers. The OWASP SSRF Prevention Cheat Sheet is especially relevant for engineering teams that need concrete controls, while monitoring guidance in the CISA Secure by Design material reinforces the expectation that dangerous defaults should not be exposed to user input.

Organisations typically encounter the operational impact only after an internal service is accessed unexpectedly or a cloud credential is exposed, at which point SSRF becomes operationally unavoidable to contain.

Related resources from NHI Mgmt Group

• Why do admission controllers make SSRF more dangerous than ordinary application SSRF?
• Why do live secret verification flows create blind SSRF risk?
• How should security teams prevent SSRF in identity APIs?
• Why is SSRF especially dangerous for IAM systems?