How to fix SSRF

What an attacker can do

The concrete impact of leaving SSRF unpatched.

How to fix SSRF

6 ordered steps. Apply them in order — each builds on the previous.

1. 1

   Allow-list URLs explicitly — never blocklist

   Maintain an allow-list of permitted destinations. Reject everything else. Allow-listing is harder to bypass than blocklisting — there's no equivalent of 'oh, you forgot 169.254.169.254 in IPv6'.

   If your feature is 'fetch a URL', who legitimately needs this? Often the answer is 'specific 3rd-party APIs you integrate with' (Stripe webhooks, S3 URLs, your own CDN). Define those exact hostnames as the allow-list. Reject everything else. Even 'allow any HTTPS URL' is dangerous if 'any URL' includes IPs and DNS names that resolve to internal addresses.

   TypeScriptStep 1

   const ALLOWED_HOSTS = new Set([
     'api.stripe.com',
     's3.amazonaws.com',
     'cdn.yourdomain.com',
   ]);
   
   function validateUrl(rawUrl: string): URL {
     let url: URL;
     try { url = new URL(rawUrl); }
     catch { throw new Error('Invalid URL'); }
   
     if (url.protocol !== 'https:') throw new Error('Only HTTPS allowed');
     if (!ALLOWED_HOSTS.has(url.hostname)) throw new Error('Host not allowed');
     return url;
   }

2. 2

   Block private/loopback/metadata IPs after DNS resolution

   Allow-listing by hostname isn't enough — attacker.com can resolve to 127.0.0.1. Resolve the hostname to an IP, then verify the IP isn't in a blocked range.

   Common bypass: attacker registers attacker.com pointing to 169.254.169.254 (or a CNAME chain that ends there). Your hostname allow-list doesn't catch it. Fix: resolve the hostname yourself (DNS A/AAAA lookup), check the resolved IP against private/loopback/metadata blocklists, then make the request to that exact IP (so DNS rebinding doesn't change it between resolve and connect).

   Node.jsStep 2

   import { promises as dns } from 'dns';
   import ipaddr from 'ipaddr.js';
   
   const BLOCKED_RANGES = [
     '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16',  // private
     '127.0.0.0/8', '::1/128',                          // loopback
     '169.254.0.0/16', 'fe80::/10',                     // link-local
     '0.0.0.0/8', '100.64.0.0/10',                      // misc
   ];
   
   async function safeResolve(hostname: string): Promise<string> {
     const addrs = await dns.lookup(hostname, { all: true });
     for (const { address } of addrs) {
       const parsed = ipaddr.parse(address);
       if (BLOCKED_RANGES.some((r) =>
         parsed.match(ipaddr.parseCIDR(r))
       )) throw new Error('Blocked IP range');
     }
     return addrs[0].address;
   }

3. 3

   Disable HTTP redirects OR re-validate every redirect target

   Following redirects without re-validation defeats your URL allow-list. The first request goes to allowed.com, the redirect goes to 169.254.169.254.

   HTTP clients commonly follow redirects automatically. The attacker sets up a server that returns a 302 → 169.254.169.254. Your client validates allowed.com, makes the request, then transparently follows the redirect to the metadata service. Two fixes: (a) disable redirect-following entirely and have your code handle 3xx responses manually, or (b) re-validate the redirect target through the same allow-list before following.

   Node.js / undiciStep 3

   import { fetch } from 'undici';
   
   // SECURE — disable redirect following entirely
   const res = await fetch(validatedUrl, {
     redirect: 'manual', // do not follow redirects automatically
     headers: { 'user-agent': 'YourApp/1.0' },
   });
   
   // If you need redirects, re-validate each target:
   let url = validatedUrl;
   for (let i = 0; i < 5; i++) {
     const res = await fetch(url, { redirect: 'manual' });
     if (res.status >= 300 && res.status < 400) {
       const next = res.headers.get('location');
       if (!next) break;
       url = await validateUrl(next); // reuse step 1 + 2 validation
       continue;
     }
     return res; // final, validated response
   }

4. 4

   Enforce IMDSv2 on AWS (or migrate cloud workloads to per-pod credentials)

   Cloud-specific. AWS IMDSv2 requires a session token from PUT request before the metadata service responds — SSRF (which only does GET) can't reach it.

   If you run on AWS EC2/ECS/Fargate, set the instance metadata service to require IMDSv2 (HttpTokens=required). IMDSv2 forces a 2-step protocol: PUT /latest/api/token returns a session token, then GET /latest/meta-data/* with that token. Most SSRF can only do GET, breaking the chain. On Kubernetes, prefer IRSA (IAM Roles for Service Accounts) or Workload Identity (GCP) — neither is reachable via SSRF since the credential vending happens via a Kubernetes ServiceAccount, not the metadata IP.

   Terraform / AWSStep 4

   resource "aws_launch_template" "app" {
     name = "app-secure-imds"
   
     metadata_options {
       http_endpoint               = "enabled"
       http_tokens                 = "required"   # IMDSv2 mandatory
       http_put_response_hop_limit = 1            # block container access
       instance_metadata_tags      = "disabled"
     }
   }
   
   # Better still on EKS — use IAM Roles for Service Accounts (IRSA):
   # attach IAM role via OIDC; pods get credentials via projected
   # ServiceAccount token, not metadata IP.

5. 5

   Add an egress firewall — your server only talks to expected destinations

   Defense in depth. At the network layer, restrict outbound HTTP to ALLOWED destinations. Even if SSRF bypasses application checks, network-level egress rules block the request.

   On Kubernetes, NetworkPolicy with explicit egress rules. On AWS, security group egress rules + VPC endpoints for S3/DynamoDB so traffic stays within AWS. On bare metal, iptables egress rules. For workloads that need to reach 'any third-party API', use a forward proxy (Squid, mitmproxy with allow-list) that you can audit and log. Network egress is the last line of defense — when application code fails, network rules still block.

   Kubernetes / NetworkPolicyStep 5

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: webhook-worker-egress
   spec:
     podSelector:
       matchLabels:
         app: webhook-worker
     policyTypes: ["Egress"]
     egress:
       # Allow DNS
       - to: [{ namespaceSelector: { matchLabels: { name: kube-system } } }]
         ports: [{ protocol: UDP, port: 53 }]
       # Allow HTTPS to specific IP ranges (your allow-listed APIs)
       - to:
           - ipBlock:
               cidr: 0.0.0.0/0
               except:
                 - 169.254.169.254/32  # block AWS metadata
                 - 10.0.0.0/8          # block internal network
                 - 172.16.0.0/12
                 - 192.168.0.0/16
                 - 127.0.0.0/8
         ports: [{ protocol: TCP, port: 443 }]

6. 6

   Add unit + integration tests for known SSRF payloads

   Test every URL-accepting endpoint against the OWASP SSRF cheatsheet payloads. Assert all are rejected.

   Standard pattern: a parameterized test that submits each canonical SSRF payload to your URL handler and asserts the response is 400 (rejected) or empty (downstream returned nothing useful). Covers IPv4, IPv6, decimal/octal/hex IP encoding, DNS rebinding domains, file:// protocol, gopher://, AWS/GCP/Azure metadata. Run on every PR.

   JestStep 6

   const SSRF_PAYLOADS = [
     'http://169.254.169.254/',                  // AWS metadata
     'http://metadata.google.internal/',         // GCP metadata
     'http://localhost:6379/',                   // Redis
     'http://127.0.0.1:8080/admin',
     'http://127.1/',                            // short-form
     'http://[::1]/',                            // IPv6 localhost
     'http://2130706433/',                       // decimal 127.0.0.1
     'http://0177.0.0.1/',                       // octal
     'file:///etc/passwd',
     'gopher://localhost:6379/_FLUSHALL',
   ];
   
   describe.each(SSRF_PAYLOADS)('SSRF payload %s', (payload) => {
     it('rejects via /api/webhook/test', async () => {
       const res = await api.post('/api/webhook/test')
         .send({ url: payload });
       expect(res.status).toBe(400);
       expect(res.body.error).toMatch(/url|host|protocol/i);
     });
   });