Slide 21 · MIT 03
Allowlist all outbound URLs — including URLs from trusted third-party responses.
SSRF protection must apply to where you go, not just who told you to go there.
The rule
Any URL fetched server-side — regardless of whether it came from a user request, a third-party API response, or a configuration value — must be validated before the fetch. This includes URLs returned in third-party JSON responses, redirect destinations returned by OAuth providers, and callback URLs registered by integrations.
✅
Validate redirect destinations, not just redirect sources
When following HTTP redirects from a third-party API, validate the destination URL of the redirect against the allowlist — not just the initial URL. An attacker who controls a redirect at the trusted domain can point it anywhere. The allowlist check must happen at every hop in the redirect chain, not just the first request.
🚫
Disable redirect following where not needed
HTTP libraries follow redirects automatically by default. For API-to-API calls where a redirect is unexpected, disable automatic redirect following (allow_redirects=False in Python Requests, followRedirects: false in node-fetch). If the third-party legitimately uses redirects, follow them manually — with validation at each step.
📋
Check the resolved IP, not just the domain
After DNS resolution, validate that the resolved IP is not in a private or link-local range (10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x, 169.254.x.x). This catches subdomain takeover attacks where an attacker-controlled subdomain resolves to an internal IP. Resolve once, validate, and connect to the resolved IP directly (bypass DNS rebinding).
Same rule as API7 — applied to a new context
The SSRF mitigation from API7 (URL allowlist + post-DNS IP validation + disable redirects) applies directly here. The difference is context: in API7, the URL came from a user. In API10, the URL comes from a third-party. The control is identical — but it must be applied to all server-side fetches, not just those fed by user input.
💼 Business takeaway
Ask your team: if a third-party API you integrate with was compromised and started returning internal URLs or server addresses in its responses, would your system follow those URLs? The answer should be no — and there should be a technical control enforcing that, not just a policy.