Define the exact set of external domains your URL-fetching feature needs to reach. Reject any URL that isn’t on that list — regardless of whether it looks “safe.”
• File import feature: allowlist = [“supplier-a.com”, “supplier-b.com”]. Any other domain → 400 error.
• Webhook feature: allowlist = customer-configurable, but must resolve to a non-private IP. OR require customers to pre-register and verify their webhook domain.
• Link preview: allowlist = all public HTTPS URLs, but with IP validation after resolution (MIT 02).
A blocklist tries to enumerate every possible internal address and dangerous URL pattern. Attackers bypass blocklists with: decimal IP notation (2130706433 = 127.0.0.1), URL encoding (%31%32%37%2E%30%2E%30%2E%31), IPv6 loopback (::1), octal notation (0177.0.0.1), and DNS rebinding (hostname resolves to internal IP after the check). Allowlists don’t try to enumerate bad inputs — they enumerate good ones. Everything else fails closed.
Some features (link preview, general webhook) genuinely need to accept arbitrary URLs. In this case, combine MIT 02 (IP validation after DNS resolution), MIT 03 (no redirects), and MIT 06 (network isolation) — the allowlist is relaxed, but the other defenses contain the damage.
Ask your team: anywhere your API fetches a URL on a user’s behalf — webhooks, file imports, link previews — is there a strict list of allowed destinations? If the user can supply any URL, that is an SSRF risk.