Security
SSRF
Server-Side Request Forgery abuses a server feature that fetches a URL, coaxing it into requesting internal addresses — cloud metadata endpoints, internal admin panels — that the attacker cannot reach directly. It is a common way cloud credentials get stolen. Mitigate by allow-listing destinations, blocking private IP ranges and disabling unused URL schemes.
Purpose
Server-Side Request Forgery (SSRF) abuses any feature where your server fetches a URL — image import, webhook test, PDF renderer — by pointing it at targets only the server can reach: internal admin panels, private services, and above all cloud metadata endpoints (169.254.169.254) that hand out credentials. The attacker borrows your server's network position.
When to Use It
Recognise the risk wherever user-supplied URLs get fetched server-side: 'import from URL' features, webhook verifiers, link previews, file converters. In cloud environments it is a headline path to stolen credentials, which is why it earned its own OWASP Top-10 slot.
Trade-offs
Defence collides with legitimate flexibility — customers genuinely want webhooks to arbitrary endpoints — so controls are layered rather than absolute: validation, network egress rules and platform hardening together. DNS rebinding and redirects defeat naive URL checks, so validate the resolved IP, not just the hostname.
Implementation
Allow-list destinations where possible; otherwise resolve the hostname and reject private, loopback and link-local ranges — after following redirects. Permit only http(s) schemes, enforce IMDSv2 (session-based metadata access) on AWS, and constrain egress with network policy so a bypass still hits a wall.