SSRF defence is a layered problem. No single control stops every variant — URL allowlists, IP deny lists, redirect management, network segmentation, and cloud metadata service hardening must work together. The attacker only needs one gap; the defender must close them all.
- Design a layered SSRF defence combining allowlist, deny list, and network controls.
- Explain why IMDSv2 replaces IMDSv1 and how the hop limit token blocks SSRF.
- Apply the principle of least privilege to outbound requests from application servers.
- Evaluate the security posture of a URL-fetching endpoint using a defence-in-depth model.
- Defence in depth
- A security strategy using multiple independent layers of protection so that if one control fails, another blocks the attack (CWE-918).
- IMDSv2
- AWS Instance Metadata Service version 2, which requires a PUT-based session token with a hop limit of 1 — preventing SSRF from accessing the metadata endpoint through a proxy.
- Egress filtering
- Restricting outbound network traffic from the application tier to only allow connections to known, necessary destinations, blocking DNS and HTTP callbacks to attacker-controlled servers.
Defence is a stack, not a single switch
Many teams implement SSRF defence as a single URL allowlist. That allowlist can be bypassed by DNS rebinding, redirects, or IP encoding. A mature defence stacks multiple controls: validate the URL against an allowlist, deny known private IP ranges, disable redirects, enforce egress rules at the network layer, and use cloud metadata service version 2 to prevent token theft.
Each layer addresses a different bypass vector. The allowlist stops obviously malicious hosts. The IP deny list catches decimal and IPv6 encodings of private addresses. Disabling redirects prevents the attacker from chaining through an allowed external server. Egress filtering blocks out-of-band callbacks. And IMDSv2 makes it impossible for an SSRF to read cloud metadata tokens through a simple GET request.
Configure the defences
The sandbox below lets you toggle individual security controls and see how each one affects a simulated SSRF attack. Watch the security score change as you enable or disable each layer.
IMDSv2: born from SSRF
AWS introduced IMDSv2 in 2019 specifically because IMDSv1 made cloud-metadata extraction trivially exploitable through SSRF. In the Capital One breach (2019), the attacker exploited an SSRF in a WAF configuration endpoint to reach the IMDSv1 endpoint and retrieve AWS credentials that gave them access to 140,000 customer records. IMDSv2 requires a PUT request with a session token that includes a hop limit of 1 — meaning the metadata service will reject requests that have passed through any network intermediary, including an SSRF proxy.
The defence checklist
Every URL-fetching endpoint should be reviewed against this checklist: validate the URL against a strict allowlist of hosts (not patterns); resolve the hostname to an IP and verify it is not in a private range; disable HTTP redirect following; apply egress firewall rules that deny all outbound traffic from the application tier except to known services; and ensure cloud metadata endpoints use IMDSv2 with a hop limit of 1.
// VULNERABLE — no defence beyond a basic hostname check
const url = req.query.url;
if (url.startsWith('http://')) {
const resp = await fetch(url);
}
// DEFENDED — layered controls
const parsed = new URL(url);
if (!ALLOWED_HOSTS.has(parsed.hostname)) return res.status(403).end();
const ip = await dnsResolve(parsed.hostname);
if (isPrivateIP(ip)) return res.status(403).end();
if (!isAllowedIP(ip)) return res.status(403).end();
const resp = await fetch(url, { redirect: 'manual' });
// AWS IMDSv2 — enforce hop limit
// IMDS endpoint refuses requests with TTL > 1
// curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"What to remember
- No single control stops all SSRF variants — use layered defence.
- IMDSv2 (PUT + hop limit) is the standard for protecting cloud metadata endpoints from SSRF.
- Egress filtering at the network layer is the last line of defence when all application-layer controls fail.
- Always resolve the target hostname to an IP and validate the IP, not just the hostname string.
- Least privilege applies to the application's network access — if the app does not need to reach the internet, it should not be able to.
Knowledge check
0/3 answered · 0 correct1.Why does IMDSv2 prevent SSRF from extracting cloud metadata when IMDSv1 did not?
2.Which SSRF bypass technique is defeated by disabling HTTP redirects?
3.An allowlist permits "images.example.com". The attacker supplies "http://images.example.com@127.0.0.1/admin". What has the team failed to do?