SaaS SSRF prevention: secure outbound requests and URL fetching
Reduce server-side request forgery risk in SaaS URL previews, imports and callbacks with fixed destinations, strict validation, egress controls and redirect-safe clients.
In this guide
What is server-side request forgery (SSRF)?
Server-side request forgery (SSRF) happens when a service is tricked into making a network request chosen by an attacker. Features such as URL previews, image import, document conversion and custom callbacks can unintentionally let an internet-facing application reach internal services or cloud metadata. Prefer fixed destinations; if user-controlled destinations are essential, validate them and enforce network egress restrictions as separate layers.
Avoid accepting a complete URL when the product can choose the destination
For a known integration, select the provider endpoint in trusted configuration and accept only the business data needed for the request. If a user needs to choose a partner, collect a hostname or provider identifier and match it to an approved list, then construct the scheme, port and path yourself. Full URLs contain parsing edge cases and redirect behavior that are hard to validate safely.
Allow only required schemes, hosts and ports
If arbitrary public URLs are an explicit product feature, allow only the required protocols such as HTTP or HTTPS, reject embedded credentials and unusual ports, and validate the hostname with a maintained URL parser. Do not rely on a simple string prefix or regular expression to decide whether a destination is safe.
Protect internal and metadata networks at the network layer
Restrict outbound connections from URL-fetching workers so they cannot reach internal control planes, private networks, loopback, link-local services or cloud metadata endpoints unless a documented dependency requires it. Use a controlled egress proxy or firewall policy, and do not give a fetch worker broad service credentials.
| Feature / destination | User controls | URL and DNS validation | Egress boundary / identity | Redirect and response limits |
|---|---|---|---|---|
| URL preview | ||||
| Partner callback | ||||
| File or image import |
How should URL validation and redirects work?
Validate resolved addresses and handle DNS changes
A hostname can resolve to more than one IPv4 or IPv6 address, and DNS results can change between validation and connection. Evaluate all resolved addresses against the destination policy and use a client or egress layer that prevents a second resolution from bypassing the check. Reject private or reserved destinations unless the use case explicitly requires them and is separately protected.
Disable automatic redirects or revalidate every hop
A permitted public URL can redirect to a prohibited address. Prefer disabling automatic redirects in the fetching client. If redirects are a product requirement, validate every new scheme, host, port and resolved address before following it, and set a small hop limit.
Use a dedicated, limited fetch client
Allow only necessary protocols and methods, set short connection and total timeouts, cap response size and content types, and avoid forwarding cookies or authorization headers from the user’s session. Keep the fetcher isolated from application credentials and internal service discovery. Return only the processed result, not arbitrary raw responses that may contain sensitive data.
How do you test SSRF defenses in a SaaS application?
Inventory every feature that makes an outbound request
Review webhooks, import tools, URL previews, image and document fetchers, PDF generation, link scanners and integrations. Trace whether a user or customer administrator can influence host, scheme, port, path, redirect or DNS behavior. Include asynchronous jobs because they may run with broader network access than the web server.
Verify blocked destinations using a controlled test environment
Use an authorized test network with safe mock endpoints to confirm that disallowed address ranges, unexpected ports, schemes and redirect targets are rejected. Do not probe real cloud metadata services or third-party internal networks. Check both application validation and the network egress policy.
Limit and monitor outbound behavior
Log the feature, requesting tenant, approved destination and outcome without storing sensitive URL parameters or response bodies unnecessarily. Alert on repeated blocked destinations, unusual request volume and unexpected egress. Keep normal integrations observable so an incident responder can distinguish expected calls from abuse.
SaaS SSRF prevention questions
Is blocking localhost enough to prevent SSRF?
No. Internal IPv4 and IPv6 ranges, link-local addresses, cloud metadata, alternate encodings, DNS changes and redirects can create other paths. Pair careful destination validation with network egress controls.
Can we safely accept any URL if we use HTTPS?
No. HTTPS encrypts a connection but does not make the destination safe. Validate where the server connects, prevent access to internal destinations and avoid forwarding user credentials to the fetched host.
Should redirects be allowed for URL previews?
Only if the feature needs them and every redirect target is revalidated. Disabling automatic redirects is simpler; otherwise limit hops and enforce the same scheme, host, address and port policy at each step.
Does a webhook signature prevent SSRF?
A signature verifies message authenticity or integrity; it does not determine whether the server should connect to the configured destination. Validate and constrain outbound destinations separately, and use the signature to verify inbound webhook deliveries.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OWASP Server-Side Request Forgery Prevention Cheat SheetOWASP Foundation