# From Custom Code to Mature Library: Why I Replaced My SSRF Protection with requests-hardened

> Source: <https://dev.to/truongsontung/from-custom-code-to-mature-library-why-i-replaced-my-ssrf-protection-with-requests-hardened-3kd6>
> Published: 2026-09-10 00:51:11+00:00

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](https://dev.to/truongsontung)