SSRF Prevention: How You Actually Close This Off

Three parts covered how bad this gets. This one covers what stops it. Part 4 of the SSRF series.

Part 4 of the SSRF series. Parts 1 through 3 were all about breaking things — finding the parameter, reading internal files, scanning ports blind. This one is for the other side of the table. There are two places you can stop SSRF: inside the application, or at the network level. Ideally both.

At the Application Level: The root of every SSRF we exploited was the same thing: the application was taking a URL from user input and making a request to it with zero checks on where that URL pointed. The fix starts with a whitelist. Instead of accepting any URL and then trying to block the dangerous ones — which is the blacklist approach, and blacklists always have gaps — you define exactly which origins the application is allowed to fetch from. A specific domain, a specific endpoint. Anything outside that list gets rejected before the request is even made. An attacker pointing the parameter at 127.0.0.1 or dateserver.htb/admin.php or their own machine gets nowhere, because none of those are on the list. Same logic applies to URL schemes. The application in this series only needed http:// to do its job. There was no reason it should have accepted file:// or gopher:// — those opened up reading local files and interacting with internal TCP services. Lock the scheme down. Hardcode it if you can, or check it against a whitelist if you can't. Don't let user input decide what protocol the server speaks. Input sanitization matters too — making sure the URL is actually what it claims to be, stripping things like encoded characters that might bypass naive checks. At the Network Level: Application-level fixes are the priority, but network controls are the safety net for when something slips through. Firewall rules that restrict outbound requests from the web server mean that even if an attacker finds an SSRF and points it somewhere they shouldn't, the request gets dropped before it reaches anything. The server tries to talk to the internal admin service — the firewall kills it. Network segmentation takes this further. If the web server simply can't reach internal infrastructure by design — they're on separate network segments with no route between them — then SSRF can't be used to pivot internally regardless of what the application does. The vulnerability exists but has nowhere to go. That's the Series: Four parts. We went from understanding what SSRF is, to reading internal admin panels and system files, to scanning ports without any output at all, to this — what it actually takes to prevent it.