Server-Side Request Forgery

Attacker-controlled destinations

SSRF occurs when an application fetches a URL supplied by a user (webhooks, image imports, PDF renderers, link previews) without restricting the destination. Attackers point it at internal services, admin panels or cloud metadata endpoints (such as 169.254.169.254) to steal credentials. Defences: allow-list destinations or schemes, resolve the hostname and block private, loopback and link-local addresses (and re-check after redirects), disable unneeded URL schemes, isolate fetchers in a restricted network segment, and require IMDSv2-style protections on cloud metadata services.

Validating a user-supplied URL

Python sketch; also restrict network egress at the infrastructure level.

import ipaddress, socket
from urllib.parse import urlparse

ALLOWED_SCHEMES = {"https"}

def is_safe_url(url: str) -> bool:
    parts = urlparse(url)
    if parts.scheme not in ALLOWED_SCHEMES or not parts.hostname:
        return False
    for info in socket.getaddrinfo(parts.hostname, parts.port or 443):
        ip = ipaddress.ip_address(info[4][0])
        if ip.is_private or ip.is_loopback or ip.is_link_local or ip.is_reserved:
            return False
    return True

# Fetch with redirects disabled (or re-validate each hop), a short timeout,
# and connect to the IP you validated to avoid DNS rebinding.

Block egress by default

A fetcher service that can reach only the public internet, not internal networks, contains SSRF even if validation has a gap.

Quick check: Why are cloud metadata endpoints a common SSRF target?

• They are always rate limited
• They host the public website
• They store user passwords in plain text
• They can return credentials for the server's cloud identity