SSRF becomes much more dangerous when an application can reach cloud metadata and exchange that access for credentials. IMDSv2 reduces that risk by requiring a session token and stricter request behavior.
Require IMDSv2
Make metadata tokens mandatory for every EC2 instance. Do this centrally so new teams and old templates inherit the safer default.
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890abcdef0 \
--http-tokens required \
--http-put-response-hop-limit 1Limit role permissions
IMDSv2 is not a substitute for least privilege. If the instance role can read every secret and assume every deployment role, a single application bug still has a wide blast radius.
Treat metadata access as credential access. Monitor it, restrict it, and assume web-facing workloads will eventually be probed for SSRF.
Audit organization-wide
Track metadata options continuously. The risk often returns through old launch templates, copied AMIs, and emergency deployments.
SSRF kill chain
A typical cloud SSRF chain starts with a web endpoint that fetches attacker-supplied URLs. The attacker points it at metadata, steals temporary credentials, enumerates permissions, and then uses the role to read secrets, buckets, queues, or deployment resources.
Breaking points:
- Block metadata access from application containers.
- Require IMDSv2 tokens.
- Set hop limit to
1. - Restrict instance role permissions.
- Monitor unusual metadata access patterns.
Organization guardrails
Use service control policies, launch template controls, and config rules to prevent IMDSv1 drift. Security should not depend on every application team remembering a checkbox during urgent infrastructure work.
{
"HttpTokens": "required",
"HttpPutResponseHopLimit": 1,
"InstanceMetadataTags": "disabled"
}Detection strategy
Watch for application processes making metadata requests, especially from web-facing workloads. Pair VPC flow logs, host telemetry, and cloud API activity. A metadata request followed by unusual IAM API calls is a strong investigation signal.
IMDSv2 reduces exploitability, but least-privilege IAM determines the blast radius when something still goes wrong.
Container and proxy considerations
Metadata defenses are trickier in containerized environments. A reverse proxy, service mesh sidecar, or SSRF-vulnerable internal service may still reach metadata unless egress is controlled. Do not assume the application container boundary protects metadata by default.
Controls to add:
- Block
169.254.169.254at container egress where possible. - Use network policies for Kubernetes workloads.
- Avoid giving web-facing workloads broad instance roles.
- Prefer task or workload identity scoped to the service.
Post-incident questions
If you suspect metadata credential theft, answer these quickly: which role was exposed, which API calls used it, which region was affected, whether credentials were used outside normal infrastructure, and whether any long-lived secrets were accessed using the temporary role.
Secure development habit
Any feature that fetches URLs should be treated as dangerous. Validate schemes, resolve DNS carefully, block private and link-local ranges, limit redirects, and log destinations. SSRF prevention belongs in shared HTTP client code, not scattered across feature handlers.
Baseline for teams
The most effective IMDSv2 program gives application teams a default secure path. Platform teams should ship hardened launch templates, Terraform modules, and CI checks that make unsafe metadata options difficult to introduce. Security review then focuses on exceptions instead of arguing over every new instance.
For internet-facing workloads, combine metadata hardening with egress controls. Block link-local metadata from containers that do not need it, avoid broad EC2 roles, and prefer workload identity patterns that scope credentials to one service. A small SSRF bug should not become organization-wide cloud access.
Incident response workflow
When metadata abuse is suspected, preserve timelines. Correlate web access logs, metadata access telemetry, STS activity, IAM calls, and CloudTrail events. The goal is to determine whether the attacker only tested metadata or actually used credentials. Temporary credentials expire, but the actions taken with them may have lasting consequences, such as copied secrets, modified policies, or persistence through newly created access paths.
Responder questions:
- Which web request triggered the suspected SSRF?
- Which instance role was exposed?
- Which API calls happened after the metadata request?
- Were secrets, deployment artifacts, or customer data accessed?
- Did the attacker create users, keys, policies, snapshots, or public buckets?
IMDSv2 is a major control, but the full defense comes from layering: safe URL fetchers, metadata enforcement, least privilege, egress filtering, and cloud audit trails that make abuse visible.
