SSRF Explained: How to Secure URL Fetchers, Webhooks, and Server-Side Requests

Server-Side Request Forgery (SSRF) happens when an application fetches a user-influenced URL and can be tricked into reaching destinations the user should not access directly.

Common risk surfaces include URL previews, remote-image imports, webhooks, SSO metadata, PDF/rendering services, and “fetch from URL” features.

flowchart LR
    U[User URL] --> V[Validate + Resolve]
    V -->|Allowed| F[Restricted Fetcher]
    V -->|Private / unsafe| D[Deny]
    F --> E[External Destination]

Prefer Allowlists

If the feature only needs known partners or domains, explicitly allow those destinations. This is much stronger than trying to maintain an endless deny-list.

Restrict URL Schemes

If the feature is an HTTP fetcher, allow only https and possibly http where genuinely required. Reject unexpected schemes and embedded credentials.

Use a mature URL parser instead of home-grown string checks.

Validate the Resolved Address

A hostname can resolve to loopback, private, link-local, multicast, or cloud-metadata addresses.

Resolve and classify the destination before connecting. When redirects are allowed, validate every redirect target again rather than trusting only the first URL.

Be aware of DNS-rebinding/time-of-check issues when designing high-risk fetchers.

Restrict Network Egress

Application validation should be backed by network policy where practical. A fetcher that never needs internal network access should not have unrestricted routes to databases, control planes, or cloud metadata services.

Cloud metadata protections such as AWS IMDSv2 are useful defense in depth, not a replacement for SSRF-safe application design.

Bound the Fetch

Apply:

• connection/read timeouts
• response-size limits
• redirect limits or disabled redirects
• allowed content types where relevant
• controlled DNS/network behavior

The server should not become an unlimited proxy or download engine.

Final Takeaway

SSRF prevention is strongest when destination validation and network isolation work together. Allowlist known targets where possible, validate schemes and resolved IPs, re-check redirects, block internal/metadata networks, and tightly bound every outbound request.

References

• OWASP SSRF Prevention Cheat Sheet
• OWASP API7: SSRF