SSRF: When a URL Fetch Feature Reaches Places It Should Not

A link-preview feature asks the server to fetch a URL supplied by a user. That sounds harmless until the URL points to a service the user cannot reach directly: an internal dashboard, a local admin port, or a cloud metadata endpoint. Server-side request forgery, or SSRF, exploits the server's network position. The attacker does not need to break the target's public firewall if they can persuade a trusted server to make the request. ## Begin with a narrow purpose If the application only needs content from a known provider, allowlist that provider rather than accepting arbitrary destinations. Restrict schemes, ports, and request methods. A web importer rarely needs access to non-HTTP protocols or arbitrary destination ports. Parse URLs with a standards-compliant library. Ad hoc string checks can mishandle user information, encoded characters, unusual address representations, or hostnames crafted to resemble an allowed domain. Do not forward the user's cookies, authorization headers, or internal service credentials to the destination. Outbound requests should start with the minimum headers required for the specific integration. ## Validate the destination throughout the request Blocking the literal string `localhost` does not block loopback addresses, private networks, link-local addresses, or IPv6 equivalents. DNS also complicates the problem: a hostname may resolve to an internal address or change between validation and connection. Apply a network policy that prevents reaching prohibited destinations, not just a text filter. Depending on the infrastructure, a dedicated outbound proxy or isolated fetch service can enforce the boundary more reliably. Redirects require the same scrutiny as the original URL. A public address can redirect to an internal target. Either disable redirects when unnecessary or revalidate every hop and cap their number. ## Bound what a permitted request can consume Even an allowed public site can send an enormous response, respond indefinitely, or return content that attacks a downstream parser. Set connection and response deadlines, response-size limits, and supported content types. Avoid fetching from an environment with unnecessary privileges. A service that only builds previews should not have broad database credentials or administrative network access. Test internal addresses, alternate address formats, redirect chains, DNS changes, and slow responses in a controlled environment. Do not probe unrelated systems while testing. Observe rejected destinations without logging credentials that may appear in URL query strings. Error messages should explain the failure without disclosing internal network details. SSRF prevention is strongest when the server cannot reach sensitive destinations in the first place. Application validation then reinforces a network boundary rather than carrying the whole security burden alone. ## Further reading - [OWASP: SSRF prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) - [PortSwigger: Server-side request forgery](https://portswigger.net/web-security/ssrf)