SSRF Defense for URL Fetchers, Webhooks, and Preview Services
Design and assess outbound request features so user-controlled URLs cannot silently cross server network trust boundaries.
A URL preview feature looks simple: accept a link, fetch the page, and display a title. The security question is more complicated: what can the application server reach that the user cannot? Server-side request forgery, or SSRF, turns that difference into a trust boundary problem.
Inventory outbound request features
Review link previews, webhook validation, remote image imports, PDF generation, and integrations that fetch customer-supplied URLs. Record the worker or service that performs each request and the network permissions it inherits.
For a fictional preview service, decide whether the product needs arbitrary public websites or only a few business partners. A tightly defined partner integration can often enforce a much narrower destination policy.
Test with controlled destinations
Use an approved endpoint owned by the assessment team and attach a unique marker to each request. The received request can establish which service made the connection and whether redirects are followed. A callback proves outbound connectivity; it does not prove access to internal services.
Use explicitly provisioned internal test endpoints only when the engagement includes that boundary. Do not probe production metadata services or unrelated internal systems to demonstrate a risk that can be established with a controlled target.
Enforce policy throughout the request
Restrict accepted schemes and ports to those the feature requires. Normalize and validate destinations using established parsing and networking libraries. Where feasible, allow only specific approved destinations.
Account for DNS resolution, IPv4 and IPv6, redirects, and changes between validation and connection. A hostname check performed before a separate fetch operation may not describe the address ultimately contacted. Apply network egress restrictions as another control rather than relying entirely on string validation.
Set bounded timeouts, response-size limits, and redirect limits. Avoid forwarding the application's internal authentication headers to user-selected destinations. These measures also make the feature more predictable under ordinary failure conditions.
Retest the complete fetch path
After a fix, check the initial request, redirect handling, and background worker behavior. Confirm that legitimate approved integrations still work. Record residual reachability and the network layer responsible for enforcing the boundary.
The OWASP SSRF Prevention Cheat Sheet discusses application validation and network restrictions.
Comments 0
Share your questions, experiences, or feedback about this article.
Sign in with Google to leave a comment.
Sign in with Google
No comments yet. Be the first to share your feedback.