SSRF (Server Side Request Forgery)
Server-Side Request Forgery, or SSRF, is a type of security vulnerability that occurs when an attacker manipulates a web application into making requests on their behalf. SSRF exploits the trust relationship between the server and internal or external systems, enabling the attacker to bypass access controls and reach resources they could never reach directly.
Attackers can use SSRF to scan internal networks, bypass firewalls, or interact with services and APIs that only the server can reach, all while masquerading as the server itself. SSRF vulnerabilities typically arise when applications make requests to URLs influenced by user input without validating them.
Why SSRF matters for webhooks
Webhook senders are a textbook SSRF target, because sending webhooks means making HTTP requests to URLs your users provide. An attacker does not need to find an obscure injection point: registering a webhook URL is the product working as intended. If they register an internal address, say a cloud metadata endpoint like http://169.254.169.254/ or an internal admin service, your infrastructure will dutifully deliver requests to it from inside your network, potentially exposing credentials or internal APIs.
This is why any system that delivers webhooks, whether a SaaS product notifying customers or an internal event pipeline, needs SSRF defenses designed in from the start rather than bolted on.
How to defend against SSRF
For webhook senders, the core defense is refusing to deliver to private address space. That means resolving the destination hostname and rejecting private, loopback, and link-local IP ranges, and re-checking after redirects, since a URL that resolves to a public address can redirect to an internal one. DNS rebinding attacks change what a hostname resolves to between validation and delivery, so the check must apply to the connection itself, not just an earlier lookup. Many teams route all webhook egress through a dedicated proxy in an isolated network segment, so even a bypass lands somewhere with nothing to steal.
More generally, applications should validate and sanitize user-supplied URLs, prefer allowlists where destinations are known ahead of time, and follow the principle of least privilege when configuring what the serving infrastructure can reach. Monitoring and logging outbound requests helps detect probing before it becomes a breach.
For more on how Svix prevents SSRF attacks, including our isolated egress architecture, check out our documentation on webhook security and our webhook security best practices.