Last week I submitted a PR to pytorch/torchtitan adding SSRF protection to the image decoder URL fetcher. My initial approach was a full custom implementation — resolving DNS, validating each IP against private/loopback/link-local ranges, manually following redirects with per-hop validation, all bounded to 10 hops.
It worked. But a maintainer (@shuhuayu) gave direct feedback: "titan should not re-implement these safety guards — delegate to a mature third-party library like requests-hardened."
My custom implementation had a documented TOCTOU (DNS rebinding) limitation — I noted it in the docstring but couldnt fully fix it without DNS pinning. Every line of custom security code is:
requests-hardened performs IP filtering at the transport adapter level — the HTTP adapter intercepts every connection attempt and rejects private/loopback/link-local addresses (including cloud metadata endpoints like 169.254.169.254).
Key advantages:
The code went from custom DNS resolution + IP validation + manual redirect loop to:
session = requests_hardened.HTTPSession(
requests_hardened.Config(
ip_filter_enable=True,
ip_filter_allow_loopback_ips=False,
never_redirect=False,
default_timeout=(5.0, 10.0),
)
)
Every open-source maintainer knows this rule: if a mature, battle-tested library exists for a security-critical concern, use it. Custom implementations inevitably miss edge cases that the library authors already solved.
The PR went from "custom SSRF protection" to "uses requests-hardened". Smaller diff, stronger security.
Follow my bug bounty journey on GitHub @truongsontung