SSRF (Server-Side Request Forgery): Attacks, Bypasses & Defenses

Server-Side Request Forgery (SSRF)

Server-Side Request Forgery happens when an attacker can make your server send HTTP (or other) requests to a destination the attacker chooses. Features that fetch URLs, such as link previews, image imports by URL, webhooks, PDF generators rendering HTML, integrations that "test a connection", and AI agents browsing the web, all run from inside your network, with your server's network access and cloud credentials. An attacker who supplies http://169.254.169.254/latest/meta-data/iam/security-credentials/ instead of an image URL may walk away with cloud keys.

SSRF has its own category in the OWASP Top 10 (A10:2021) and the API Security Top 10, and it was central to several major cloud breaches. It's hard to fix with input validation alone, because URL parsing, redirects, and DNS offer many bypasses. Robust defenses combine application-level allowlists with network-level egress controls.

TL;DR

SSRF abuses server-side URL fetching to reach internal services, cloud metadata endpoints, or localhost-only admin interfaces.
The biggest cloud risk is stolen credentials from instance metadata. Enforce IMDSv2 on AWS, and equivalent protections elsewhere.
Blind SSRF returns nothing to the attacker directly, but still enables port scanning and triggering internal actions.
Blocklists fail: attackers use redirects, DNS rebinding, alternate IP encodings, IPv6, and odd URL schemes.
Prefer allowlists of destinations, resolve and validate IPs at connect time, disable redirects or re-validate them, and restrict schemes.
Put URL-fetching in isolated workers with egress firewalls or a forwarding proxy that blocks private address ranges.

Quick Example

A vulnerable "import image from URL" endpoint:

An attacker sends url=http://169.254.169.254/latest/meta-data/iam/security-credentials/app-role, or http://localhost:6379/, or http://internal-admin.svc.cluster.local/users.

A safer fetch: scheme and port checks, DNS resolution with IP validation, pinned connection, no redirects, and size limits.

Even with this, run the fetcher in a network segment that can't reach internal services. Network controls are the real safety net.

Core Concepts

Where SSRF Hides

URL previews and unfurling (chat apps, CMSs).
"Import from URL" for images, documents, feeds, and calendars.
Webhooks, where the user specifies callback URLs your server calls. See webhooks.
PDF or screenshot generators rendering attacker-controlled HTML (which then fetches internal resources).
XML parsers resolving external entities (XXE), and SVG and image processors fetching remote references.
Integrations with "test connection" to user-provided hosts (databases, SMTP, LDAP).
AI agents with browsing or HTTP tools, where prompt injection can direct the fetches.

Impact

Blind SSRF

When the response isn't returned to the attacker, SSRF still enables actions with side effects (hitting internal endpoints that change state), timing-based port scanning, and out-of-band detection via DNS lookups to attacker-controlled domains.

Common Bypass Techniques

Redirects: a public URL that 302-redirects to http://169.254.169.254/, which defeats checks done only on the initial URL.
DNS rebinding: a hostname resolves to a public IP during validation, then to an internal IP at connection time.
Alternate encodings: http://2130706433/ (decimal 127.0.0.1), http://0x7f.1/, http://[::ffff:127.0.0.1]/, http://127.1/.
URL parser confusion: http://allowed.com@evil.internal/, backslashes, and fragments, where different parsers disagree about the host.
Other schemes: file://, gopher://, dict://, and ftp:// in libraries that support them.
Open redirects on allowlisted domains.

This is why string-based blocklists ("reject URLs containing localhost") fail.

Defenses

Application Layer

Allowlist destinations where possible: specific domains for integrations, or a fixed set of image CDNs.
Restrict schemes and ports to https (and maybe http) on 80 and 443.
Resolve DNS yourself, validate every resolved IP against private, loopback, link-local, and metadata ranges (IPv4 and IPv6), then connect to the validated IP to prevent rebinding.
Disable automatic redirects, or re-validate each redirect target.
Limit response size, time, and content type; don't return raw responses or detailed errors to users.
Use well-maintained SSRF-safe HTTP libraries or wrappers rather than hand-rolled checks.

Network and Infrastructure Layer (Most Reliable)

Egress filtering: URL-fetching services run in subnets or pods whose outbound traffic can reach only the internet, never internal ranges. Use security groups, Kubernetes NetworkPolicies, or an egress proxy (for example Smokescreen) that enforces the rules centrally.
Protect metadata endpoints: enforce AWS IMDSv2 (session tokens plus a hop limit of 1, which blocks most SSRF-based metadata theft), set GCP metadata header requirements, and block metadata access from containers that don't need it.
Least-privilege cloud roles, so stolen credentials are worth little. See AWS IAM.
Authenticate internal services: don't assume "internal network = trusted". mTLS and service authentication limit what SSRF can reach. See zero trust.

Best Practices

Isolate URL Fetching

Move all user-directed fetching (previews, imports, webhooks) into a dedicated service with no access to internal networks and no powerful credentials. Even a validation bypass then hits a wall.

Treat Webhook Destinations as Hostile

Validate webhook URLs at registration and at delivery time (DNS can change), and send from isolated egress IPs.

Log and Alert on Blocked Destinations

Attempts to reach metadata IPs or private ranges are strong attack signals. Log them with the user and URL, and alert.

Test With Bypass Payloads

Include redirects, encoded IPs, IPv6, rebinding domains, and alternate schemes in security tests of every URL-accepting feature.

Common Mistakes

Blocklisting Strings

Validate resolved IP addresses, pin connections, and enforce egress rules at the network layer.

Validating Before Redirects Only

Checking the submitted URL but letting the HTTP client follow redirects lets attackers bounce to internal targets. Disable redirects, or validate each hop.

Leaving IMDSv1 Enabled

With IMDSv1, a single SSRF GET request can retrieve instance credentials. Require IMDSv2 across all instances and launch templates.

FAQ

What is SSRF in simple terms?

An attacker tricks your server into making a request to a location of the attacker's choosing, typically internal systems that aren't reachable from the internet, like cloud metadata services, databases, or admin panels. The server's trusted network position and credentials are then used against you.

Why is cloud metadata a major SSRF target?

Cloud instances expose a metadata service at a link-local address that can return temporary credentials for the instance's IAM role. If an SSRF lets an attacker read that endpoint, they obtain credentials to access cloud resources, as happened in the 2019 Capital One breach.

Is validating the URL enough to prevent SSRF?

Rarely. Redirects, DNS rebinding, alternate IP formats, and parser differences defeat most URL validation. Combine validation (allowlists, resolved-IP checks, pinned connections, no redirects) with network egress restrictions and hardened metadata services.

How does SSRF relate to AI agents?

Agents with web-browsing or HTTP tools make server-side requests based on model decisions, which prompt injection can influence. Apply the same SSRF defenses to agent tools: isolated egress, blocked private ranges, and allowlists for sensitive integrations.