PART 4
Prevention
Slides 18–26 · Seven mitigations + the full picture
Slide 18 · Prevention Overview
Seven ways to protect against SSRF.
URL allowlists. Protocol restrictions. Network isolation. Defense in depth.
✅
MIT 01 — URL Allowlist (Not Blocklist)
Only permit URLs from a pre-approved list of known-good domains. Reject everything else — don’t try to block bad patterns.
🔒
MIT 02 — Block Private and Link-Local IPs After DNS Resolution
Resolve the hostname to its IP. If the resolved IP is RFC 1918 or 169.254.x.x, reject. Prevents DNS-based bypasses of hostname checks.
🚫
MIT 03 — Disable HTTP Redirects
Validate the original URL, then disable redirect-following. A redirect to an internal IP bypasses allowlist checks on the original URL.
🤐
MIT 04 — Never Return Raw Server Responses to Clients
Parse and extract the specific data you need. Return only that. Never proxy the raw response back to the caller — this prevents SSRF results from being exfiltrated.
🔐
MIT 05 — Enforce Authentication on Internal Services
Internal services should require authentication even from internal callers. “It’s internal so it’s trusted” is a false assumption SSRF exploits directly.
🗄️
MIT 06 — Isolate URL-Fetching in a Separate Network Segment
Run the URL-fetching component in an isolated subnet with no access to internal services or cloud metadata. Even if SSRF occurs, there’s nothing to reach.
🚨
MIT 07 — Monitor for Metadata Endpoint Access
Alert on any outbound request to 169.254.169.254 or known internal IP ranges from your API servers. This is a high-confidence SSRF indicator.