SSRF Defense in Depth
URL parsing is only one layer; destination policy, DNS/IP checks, redirect handling, egress rules and workload identity constrain the real capability.
Frame the problem
Security starts with a concrete asset, attacker capability and trust crossing.
Why the system fails
A syntactically valid URL reaches a forbidden IP after DNS resolution or redirect, or the fetcher can access far more than its job requires.
The important question is not “what is SSRF Defense in Depth?” but “which assumption let untrusted data or an over-scoped identity cross fetch service → internal network and internet?” Trace the decision at the boundary, then constrain what can happen after the first control fails.
Design the control in layers
Start with the control closest to the interpretation or privilege boundary: Use a dedicated fetch service with no sensitive credentials Then add a control that reduces blast radius and telemetry that proves the decision was enforced.
The resulting design is not labelled secure. Record the identified controls, the known failure paths, the remaining exposure, and the evidence you would need during an incident.
| Prevent | Detect | Recover |
|---|---|---|
| Use a dedicated fetch service with no sensitive credentials · Allowlist destinations and re-check every redirect · Deny internal and metadata ranges at the network layer | Egress policy denials and internal-destination attempts | Contain the affected identity or component, scope impact from audit evidence, and preserve a regression test. |
Key points
- Asset: The backend’s ability to reach networks and act with machine credentials.
- Boundary: Fetch service → internal network and internet
- Primary control: Use a dedicated fetch service with no sensitive credentials
- Detection signal: Egress policy denials and internal-destination attempts
- Always ask what limits damage when the primary control fails.
SSRF Network Boundary
Change the system and observe which assumption moves.
Follow the attack
Safe conceptual simulation: capability → missing control → crossed boundary → asset impact.
- 1Attacker starts with: A caller able to influence a server-side fetch.
- 2A syntactically valid URL reaches a forbidden IP after DNS resolution or redirect, or the fetcher can access far more than its job requires.
- 3The weak or missing boundary control is crossed: Fetch service → internal network and internet
- 4Impact: The fetch service becomes a pivot into private infrastructure.
- The fetch service becomes a pivot into private infrastructure.
Defend, detect, recover
One prevention is a single point of security failure. Layer it and make failure observable.
- • Use a dedicated fetch service with no sensitive credentials
- • Allowlist destinations and re-check every redirect
- • Deny internal and metadata ranges at the network layer
- • Egress policy denials and internal-destination attempts
- • Contain the affected identity or component.
- • Scope access from audit evidence.
- • Fix the boundary and add a regression test.
- • Misconfiguration and new access paths can bypass the intended control.
- • A privileged insider or compromised control plane may still reach the asset.