Overview
The primary defense against SSRF is to restrict where the server may make requests using an allowlist of permitted destinations. This lesson applies allowlisting to server-side requests.
Learning objectives
- Apply allowlisting to outbound server requests.
- Explain why allowlisting beats blocklisting internal ranges.
- Describe correct allowlist implementation with canonicalization.
Core concept
An allowlist for SSRF defines the specific destinations the server is permitted to request (particular domains, hosts, or a fixed set of URLs) and rejects everything else. This is far more robust than blocklisting internal ranges (e.g. trying to ban private IPs), because blocklists are easily bypassed via alternate encodings, redirects, DNS tricks, and representations. As throughout web security, allowlist over blocklist: permit only known-good destinations rather than trying to enumerate bad ones.
How it works
With an allowlist, when a server-side request is requested, the destination is checked against the permitted set and only proceeds if it matches. Crucially, this must be done safely: the URL should be parsed and canonicalized, and validation should account for tricks attackers use to evade checks — such as redirects (the server might be sent to an allowed URL that redirects to an internal one), DNS resolution to internal addresses, and unusual encodings/representations of hosts. A robust implementation validates the final resolved destination, not just the initial string, and re-checks after any redirect.
Practical example
A webhook feature should only call a small set of approved partner domains. Instead of trying to block internal IP ranges, the app allowlists those specific partner domains and rejects any other destination. It parses and canonicalizes the URL, resolves and checks the host, and does not blindly follow redirects to non-allowlisted locations. A request aimed at an internal address (or one that redirects there) fails the allowlist check. Restricting to known-good destinations removes the SSRF risk that a blocklist would leave open.
Cybersecurity relevance
Allowlisting permitted destinations is the recommended primary SSRF defense, reflecting the allowlist-over-blocklist principle. Blocklist approaches (banning internal IPs) are notoriously bypassable, so they are not sufficient. Correct allowlisting requires canonicalization and handling of redirects and DNS to validate the actual destination. Combined with network isolation (next lesson), it strongly mitigates SSRF. Testers probe SSRF defenses with encodings, redirects, and DNS tricks; defenders validate the final destination against an allowlist.
Common mistakes
- Blocklisting internal IP ranges instead of allowlisting permitted destinations — easily bypassed.
- Validating only the initial URL string, not the canonicalized/resolved destination or post-redirect target.
- Blindly following redirects to non-allowlisted locations.
Key takeaways
- The primary SSRF defense is an allowlist of permitted destinations, rejecting all others — more robust than blocklisting internal ranges.
- Implement it safely: parse and canonicalize the URL, validate the resolved host, and re-check after redirects (attackers use encodings, DNS, and redirects to evade checks).
- Allowlisting reflects the allowlist-over-blocklist principle and, combined with network isolation, strongly mitigates SSRF.
Check your understanding
- Why is allowlisting permitted destinations more robust than blocklisting internal IP ranges for SSRF?
- Why must SSRF allowlist checks account for redirects and DNS resolution, not just the initial URL string?