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

Choosing a Mature Library Over Custom Security Code
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."
Why Custom Security Code Is Risky
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:
A potential vulnerability — did I cover all edge cases? IPv6-mapped IPv4? DNS rebinding between check and fetch? Redirect chains that switch IPs mid-chain?
Maintenance burden — every future developer has to read, understand, and trust this code
Audit liability — security reviewers will scrutinize every branch
The Refactor: requests-hardened
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:
No TOCTOU — the adapter checks the IP at connect time, not before
Redirect-safe — every redirect hop is IP-validated automatically
Well-maintained — battle-tested, used in production
Less code — our 75-line implementation collapsed to about 15 lines
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),
)
)
The Lesson: Dont Reinvent Security Wheels
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
Read original: https://dev.to/truongsontung/from-custom-code-to-mature-library-why-i-replaced-my-ssrf-protection-with-requests-hardened-3kd6
PreviousFrom Code Reviewer to Agent Manager: Lessons from 30 Days of AI-Generated SoftwareNextFrom Fragmented Logs to Full-Stack Visibility with SolarWinds Papertrail
Related posts
Man completes 28-year, 31,000-mile walk around world, returns to mother's house
0Hacker News New
Johnstown, PA will be your best place to live if you make under 100K
0Hacker News New
Cryosphere faces permanent damage when world overshoots 1.5C, scientists warn
0Hacker News New
Nanoparticles for delivering personalized cancer vaccines
0Hacker News New
WTF Ubuntu?
0Hacker News New
Napping Characteristics and Incident Dementia
0Hacker News New