SSRF: Treating Server-Side Destinations as Untrusted Input
Server-side request forgery turns an application's network client into a tool for reaching destinations an attacker cannot contact directly.
- Author
- absequ
- Published
- Updated
- Category
- Security
- ssrf
- security
- practical guide
Server-side request forgery turns an application's network client into a tool for reaching destinations an attacker cannot contact directly. A URL preview, webhook tester or document importer can become a path into internal services. The risk comes from the server's network position and credentials, not just from the visible form that accepts a URL.
On this page
The mental model
A syntactically valid URL is not necessarily an authorized destination. Attackers may exploit alternate address formats, DNS changes, redirects or internal hostnames. A simple prefix or substring check does not capture the semantics of network routing. Distinguish parsing, destination authorization and the actual connection.
Prefer identifiers for known destinations over accepting complete arbitrary URLs. If an integration needs one approved service, construct requests from a fixed base URL and tightly validated path or identifier. Put network-level egress restrictions around the service as an additional boundary, particularly where internal administration or metadata services are reachable.
A practical workflow
Define the exact protocols, hosts and ports required by the feature. Validate all resolved addresses and consider IPv4, IPv6, loopback, private and link-local ranges. DNS rebinding and the gap between validation and connection require deliberate client/network design; a preliminary lookup alone is not a complete solution.
Disable redirects where possible, or validate every redirected destination with the same policy. Bound connection time, response size and processing work. Do not forward incoming authentication headers to arbitrary remote endpoints. The following pattern avoids a caller-selected host altogether; the identifier still needs an application-specific validation rule.
Worked example
const allowedIds = new Set(['getting-started', 'faq']);
function documentationUrl(id) {
if (!allowedIds.has(id)) throw new Error('Unknown document');
return new URL('/docs/' + id, 'https://docs.example.com');
}
// The caller selects a known document, never the network origin.
// Network requests still need timeouts, size limits and redirect policy.This example is an allowlist of resources, not a production HTTP client. The example.com host is a reserved illustrative domain. In a real service, a trusted configuration value supplies the approved origin and operational controls constrain network access. Do not make configuration itself remotely writable without an appropriate administrative boundary.
Tests should cover rejected schemes, user-info syntax, alternate ports, redirects and DNS behavior using a controlled local resolver or test server. Avoid probing cloud metadata endpoints or private networks just to demonstrate the idea. A security test must not silently become an unauthorized network scan.
Failure modes and security
Blocking a few known internal IP strings is fragile. Parsing differences and address normalization can defeat naive comparisons. Conversely, accepting every HTTPS URL is too broad because TLS says little about whether a destination is appropriate for your server to contact.
Keep responses and errors from exposing internal service details. Log bounded diagnostic metadata rather than credentials or full retrieved documents. If the feature genuinely needs arbitrary internet URLs, isolate it from privileged networks and accept that the design needs a more substantial threat model than a single input validator.
Practice and verification
Design a URL-preview feature in two forms: one limited to approved documentation hosts and one accepting arbitrary public sites. List how the network boundary and operational controls differ. Write tests for redirects and response-size exhaustion without contacting real third parties. Explain how the implementation prevents a validated hostname from resolving to a forbidden address at connection time; if you cannot demonstrate that property, record the remaining risk explicitly.
References
OWASP SSRF prevention — OWASP
MDN URL API — MDN