Our SSRF guard passed every test we ran — until a stranger's comment pointed out the test we never ran

Three weeks ago, a commenter questioned the SSRF guard's testing process. The commenter specifically asked about testing the hostname-validation and fetch agreement, highlighting a gap in our testing. The commenter was left unsatisfied and returned to the question later, discovering the gap was more significant than anticipated.

The current method of blocking hostnames used regex blocks against known bad hostnames. However, it does not cover hostnames that resolve to these blocklisted IPs, leaving a vulnerability for DNS rebinding attacks. DNS rebinding allows an attacker to manipulate DNS responses, potentially bypassing the regex blocklist. To mitigate this, I implemented a solution that uses Cloudflare Workers' cf.resolveOverride in fetch() request options.

This resolves the hostname yourself, validates the IP obtained, and pins the connection to this specific IP, preventing a second, potentially manipulated DNS lookup. After implementing this fix, the endpoints were tested against a rebinding domain. The fix successfully blocked the attack, rejecting every request with specific error messages identifying the blocked IPs.

This solution ensured that all five endpoints were resolving, validating, and pinning every hop of a fetch, not just the entry URL. The fix was verified by a full endpoint-by-endpoint pass and confirmed against a live rebinding domain. It is worth noting that this solution is specifically applicable to SSRF protection in Workers/edge-function contexts. It is uncertain if there are cleaner patterns for other environments.