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.
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
Discussion (0)