Prevent SSRF Attacks on Cloud Metadata Services

Server-Side Request Forgery (SSRF) represents a severe security risk in cloud environments when vulnerable web applications are manipulated into querying internal infrastructure. Attackers frequently target instance metadata services (typically reachable via the link-local IP 169.254.169.254) to steal temporary IAM credentials, access tokens, and environment configurations. Securing these endpoints requires a defense-in-depth approach combining metadata service hardening, network filtering, application-layer validation, and least-privilege identity management.

Upgrade to Session-Oriented Metadata Services (IMDSv2)

Major cloud providers offer hardened versions of their metadata services to defeat basic SSRF attacks:

  • AWS IMDSv2: Mandates session-oriented requests. Applications must first send a PUT request with an X-aws-ec2-metadata-token-ttl-seconds header to obtain a session token, and then include that token in an X-aws-ec2-metadata-token header in subsequent GET requests. Because simple SSRF vulnerabilities typically cannot initiate arbitrary PUT requests or inject custom headers, IMDSv2 effectively blocks unauthorized access.
  • Hop Limit Restriction: In AWS, set the metadata response hop limit to 1. This prevents containerized workloads (such as Docker or Kubernetes pods running on an EC2 instance) from accessing the host's metadata service if the traffic must traverse a virtual bridge.
  • GCP and Azure Protections: Google Cloud requires the Metadata-Flavor: Google header on all requests to metadata.google.internal, while Azure requires the Metadata: true header for its Instance Metadata Service (IMDS). Ensure these requirements are strictly enforced and cannot be bypassed by your application's client libraries.

Apply Network-Level Egress Filtering

Do not rely solely on application logic to block unauthorized requests; enforce boundaries at the operating system and network levels:

  • Firewall Rules (iptables / nftables): Block or redirect outbound traffic destined for 169.254.169.254. If specific local processes need access, restrict access exclusively to the process user ID (UID) of that authorized daemon.
  • Container Isolation: In Kubernetes or Docker environments, block access to link-local IP addresses using NetworkPolicies or service meshes (e.g., Istio, Cilium) so application pods cannot communicate directly with the underlying node's metadata IP.
  • Null Routing: If an instance does not require local metadata access, create a null route on the operating system for 169.254.169.254/32 to discard all outgoing packets to that address immediately.

Implement Strict Application-Level Validation

Mitigate the vulnerability directly within the application's request-handling logic:

  • Strict Allowlisting: Only permit requests to explicit, pre-approved domain names or IP addresses. Reject any user input containing generic schemes or arbitrary target addresses.
  • Resolve and Verify IPs: Resolve target hostnames to their IP addresses before dispatching the request. Verify that the resolved IP does not belong to link-local ranges (169.254.0.0/16), private networks (RFC 1918), or loopback interfaces (127.0.0.0/8).
  • Prevent DNS Rebinding: Ensure that the IP address validated by your security logic is the exact IP used for the connection, avoiding a secondary DNS resolution that could point to a malicious address during runtime.
  • Disable HTTP Redirects: Disable automatic redirect following in HTTP client libraries. Attackers often provide a benign URL that responds with a 301 or 302 redirect pointing to http://169.254.169.254/.

Enforce Least Privilege on Compute Roles

Treat metadata protection as a multi-layered boundary where identity boundaries serve as the final backstop:

  • Assign only the minimal IAM roles and permissions necessary for the application instance to function.
  • Avoid granting administrator, credential management, or privilege-escalation permissions to compute instances.
  • Ensure that even if an attacker successfully extracts temporary credentials via an SSRF vulnerability, the blast radius is strictly constrained to read-only or low-impact operational tasks.