SSRF Attacks via Webhooks: How to Protect Your Infrastructure

Server-Side Request Forgery (SSRF) attacks via webhooks are among the most dangerous and frequently exploited vulnerabilities in web applications today. SSRF earned its place on the OWASP Top 10, and webhook endpoints remain a primary attack vector.

This guide covers how SSRF attacks work, why webhook systems are vulnerable, and concrete protection steps. See webhook security best practices for broader security guidance.

What is SSRF?

Server-Side Request Forgery (SSRF) is a vulnerability that allows attackers to induce your server to make HTTP requests to arbitrary destinations. Instead of attacking your application directly, the attacker weaponizes your server to attack other systems—often internal resources that would otherwise be inaccessible from the internet.

The attack flow:

1. Attacker identifies an endpoint that accepts URLs as input
2. Attacker submits a malicious URL pointing to an internal resource
3. Your server fetches the URL, accessing the internal resource
4. Sensitive data is returned to the attacker

Consequences: exposed cloud credentials, internal network mapping, data exfiltration, and full infrastructure compromise.

Why Webhooks Are Prime SSRF Targets

Webhook systems are inherently vulnerable to SSRF because they make HTTP requests to user-provided URLs. When an event occurs, your system sends data to whatever endpoint the user configured.

Without proper validation, an attacker can replace a legitimate URL:

// Legitimate
{
  "event": "payment.completed",
  "url": "https://customer-api.example.com/webhooks/payments"
}

// Malicious
{
  "event": "payment.completed",
  "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
}

Your webhook delivery system sends a request to the malicious URL—the AWS metadata endpoint—potentially exposing IAM credentials.

Real-World Attack Scenarios

1. Cloud Metadata Endpoint Exploitation

Cloud providers expose instance metadata through well-known internal endpoints containing temporary security credentials, instance identity, and configuration data.

AWS Metadata Service:

Google Cloud:

Azure:

A successful attack yields temporary credentials with the instance role's permissions—potentially full access to S3 buckets, databases, and other AWS services.

2. Internal Network Reconnaissance

Attackers use SSRF to map your internal network by probing private IP ranges:

By analyzing response times and error messages, attackers can identify live hosts, open ports, and running services. This reconnaissance enables targeted attacks against internal systems.

3. Internal Service Exploitation

Many internal services lack authentication because they're "protected" by the network perimeter. Common targets include:

• Redis/Memcached: http://localhost:6379/
• Elasticsearch: http://internal-es:9200/_cat/indices
• Internal APIs: http://billing-service.internal/api/invoices
• Admin panels: http://localhost:8080/admin

Once an attacker identifies these services, they can read sensitive data, modify configurations, or pivot to deeper network access.

4. DNS Rebinding Attacks

DNS rebinding bypasses URL validation by exploiting the time gap between URL validation and the actual HTTP request:

1. Attacker controls a domain (e.g., malicious.attacker.com)
2. Initial DNS lookup returns a valid public IP (passes validation)
3. DNS TTL is set very low
4. When your server makes the request, DNS returns 127.0.0.1
5. Your server connects to localhost, bypassing IP-based restrictions

Protection Strategies

1. Strict URL Validation

Implement comprehensive URL validation before accepting webhook destinations:

from urllib.parse import urlparse
import ipaddress
import socket

BLOCKED_SCHEMES = {'file', 'ftp', 'gopher', 'data', 'javascript'}
ALLOWED_SCHEMES = {'http', 'https'}

def validate_webhook_url(url: str) -> bool:
    """Validate webhook URL for SSRF protection."""
    try:
        parsed = urlparse(url)

        # Check scheme
        if parsed.scheme not in ALLOWED_SCHEMES:
            return False

        # Require a hostname
        if not parsed.hostname:
            return False

        # Block localhost variations
        hostname_lower = parsed.hostname.lower()
        blocked_hosts = {'localhost', '127.0.0.1', '0.0.0.0', '::1'}
        if hostname_lower in blocked_hosts:
            return False

        # Resolve hostname and check IP
        resolved_ip = socket.gethostbyname(parsed.hostname)
        ip = ipaddress.ip_address(resolved_ip)

        # Block private and reserved ranges
        if ip.is_private or ip.is_loopback or ip.is_reserved:
            return False

        # Block link-local (metadata endpoints)
        if ip.is_link_local:
            return False

        return True

    except (ValueError, socket.gaierror):
        return False

2. Block Private IP Ranges

Maintain an explicit blocklist of private and special-use IP ranges:

BLOCKED_NETWORKS = [
    ipaddress.ip_network('10.0.0.0/8'),       # Private Class A
    ipaddress.ip_network('172.16.0.0/12'),    # Private Class B
    ipaddress.ip_network('192.168.0.0/16'),   # Private Class C
    ipaddress.ip_network('127.0.0.0/8'),      # Loopback
    ipaddress.ip_network('169.254.0.0/16'),   # Link-local (metadata!)
    ipaddress.ip_network('0.0.0.0/8'),        # Current network
    ipaddress.ip_network('100.64.0.0/10'),    # Carrier-grade NAT
    ipaddress.ip_network('192.0.0.0/24'),     # IETF Protocol Assignments
    ipaddress.ip_network('192.0.2.0/24'),     # TEST-NET-1
    ipaddress.ip_network('198.51.100.0/24'),  # TEST-NET-2
    ipaddress.ip_network('203.0.113.0/24'),   # TEST-NET-3
]

def is_blocked_ip(ip_str: str) -> bool:
    """Check if IP falls within blocked ranges."""
    ip = ipaddress.ip_address(ip_str)
    return any(ip in network for network in BLOCKED_NETWORKS)

3. DNS Rebinding Prevention

Prevent DNS rebinding by resolving the hostname once and using the IP directly:

import requests
from requests.adapters import HTTPAdapter

class SSRFSafeAdapter(HTTPAdapter):
    """HTTP adapter that prevents DNS rebinding attacks."""

    def __init__(self, resolved_ip, hostname, **kwargs):
        self.resolved_ip = resolved_ip
        self.hostname = hostname
        super().__init__(**kwargs)

    def send(self, request, **kwargs):
        # Replace hostname with pre-resolved IP
        connection_url = request.url.replace(
            self.hostname,
            self.resolved_ip
        )
        request.url = connection_url
        # Preserve original Host header
        request.headers['Host'] = self.hostname
        return super().send(request, **kwargs)

4. Network-Level Isolation

Defense in depth requires network-level controls:

• Dedicated webhook workers: Run webhook delivery from isolated instances with no access to internal networks
• Egress filtering: Configure firewalls to block outbound traffic to private IP ranges
• Separate VPC/network: Place webhook infrastructure in a network segment with no routes to internal resources

5. Cloud-Specific Protections

AWS IMDSv2: Require token-based metadata access, which mitigates SSRF since attackers can't obtain the required token:

# Enforce IMDSv2 on EC2 instances
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled

GCP: Require the Metadata-Flavor: Google header, which most SSRF attacks can't set.

Azure: Use managed identities with minimal permissions and consider disabling metadata endpoint access where possible.

Security Best Practices Checklist

Use this checklist to audit your webhook implementation. See our production webhook security checklist for comprehensive pre-production review:

• Validate URL scheme (allow only http and https)
• Resolve hostnames before validation
• Block all private IP ranges (10.x, 172.16-31.x, 192.168.x)
• Block loopback addresses (127.x, ::1)
• Block link-local addresses (169.254.x)
• Implement DNS rebinding protection
• Disable HTTP redirects or re-validate after redirects
• Set reasonable timeouts on outbound requests
• Log all webhook delivery attempts for monitoring
• Use network-level egress filtering
• Enable IMDSv2 on AWS instances
• Run webhook workers in isolated network segments
• Regularly audit and test SSRF protections
• Monitor for unusual webhook destination patterns

How Hook Mesh Protects Against SSRF

Building robust SSRF protection is complex—many teams choose to build vs buy webhook infrastructure. Hook Mesh implements comprehensive safeguards:

Automatic URL Validation: Every webhook destination URL undergoes strict validation. We verify schemes, resolve hostnames, and block dangerous patterns.

Private IP Blocking: Automatically blocks requests to private IP ranges, loopback addresses, and cloud metadata endpoints.

DNS Rebinding Prevention: Resolves DNS once and pins the IP address, preventing time-of-check to time-of-use vulnerabilities.

Network Isolation: Delivery infrastructure runs in isolated network segments with no access to internal resources or metadata services.

Continuous Monitoring: Monitors delivery patterns for SSRF attempts and proactively blocks suspicious behavior.

With Hook Mesh, SSRF protection is built in. Focus on building your integration; we handle the security.

Conclusion

SSRF attacks via webhooks are serious threats. User-controlled URLs and server-side HTTP requests create an attack surface requiring careful protection. Implement strict URL validation, block private IP ranges, prevent DNS rebinding, and use network isolation to significantly reduce SSRF risk. Complete webhook security also requires proper authentication methods like HMAC signatures.

For startups without dedicated security teams, building these protections is complex. Managed webhook services like Hook Mesh handle these concerns out of the box, letting you focus on your core product. For more security guidance, explore our complete webhook security guide.