Server-Side Request Forgery (SSRF)
SSRF is a vulnerability where an attacker tricks the server into making HTTP requests to unintended destinations—typically internal services (metadata APIs, databases) that the server can reach but the attacker cannot.
SSRF = tricking your butler (server) into fetching something from the secret room (internal network) by handing him a note that says 'go to 169.254.169.254.' The butler has the keys you don't. DNS rebinding is giving the butler a legit address that magically changes to the secret room's address after the security check.
Vulnerable pattern: `const data = await fetch(req.body.url)`. An attacker provides http://169.254.169.254/latest/meta-data/ (AWS metadata service) or http://internal-db:5432. Node.js will faithfully make the request with the server's credentials and network access. Mitigations: (1) Allowlist permitted domains. (2) Resolve the URL, then check that the resolved IP is not in private ranges (RFC 1918: 10.x.x.x, 172.16-31.x.x, 192.168.x.x) or localhost. (3) Use a network-level firewall to prevent outbound requests to internal ranges.
DNS rebinding is a sophisticated SSRF bypass: the attacker uses a domain they control that initially resolves to a valid public IP (passing allowlist checks), then rapidly changes DNS to resolve to an internal IP. The mitigation is to check the resolved IP at both validation and request time (Time-of-Check-Time-of-Use vulnerability). Libraries like ssrf-req-filter implement this. In cloud environments, block access to the metadata IP (169.254.169.254) at the VPC level (IMDSv2 with session tokens in AWS provides a partial mitigation). Also validate URL scheme (only allow https:), port (disallow 22, 5432, 27017), and consider blocking Referer header leakage.
SSRF allows attackers to make the server fetch internal resources. Mitigate with: URL allowlisting, resolving target IPs and blocking private/loopback ranges (RFC 1918), enforcing https scheme-only, and network-level egress filtering. DNS rebinding bypasses DNS-based checks—validate the resolved IP at request time, not just at allowlist check time.
Checking the hostname against an allowlist before making a request is vulnerable to DNS rebinding. An attacker's domain passes the allowlist check resolving to a public IP, then DNS TTL expires and the attacker changes it to 169.254.169.254. The server makes the request to the now-internal IP. The fix requires checking the resolved IP address at both allowlist validation time and immediately before the TCP connection is established.