SSRF Prevention

No Backdoor Through Your Own Server

Secure web development is not about adding extra friction, but about better defaults in design, code, and release flow.

With SSRF Prevention, the greatest gains come from secure defaults that are automatically enforced in every release.

That makes security less of a separate afterthought and more of a standard quality of your product.

Immediate measures (15 minutes)

• Implement input validation, secure output encoding, and parameterized queries first.
• Harden authentication, session management, and security headers as a baseline.
• Enforce measures in CI/CD with tests, linting, and release gates.

Why this matters

The core of SSRF Prevention is risk reduction in practice. Technical context supports the choice of measures, but implementation and enforcement are central.

Defense: how to prevent your server from becoming a proxy

Allowlists, not blocklists

The first and most important rule: use an allowlist, not a blocklist. Define which domains and IP ranges the server may access, and block everything else.

A blocklist that blocks "127.0.0.1" and "169.254.169.254" is like a dam with two fingers in the holes while the rest of the dam is made of cheese. You cannot blocklist all possible bypass variants. There are too many, and more are invented all the time.

An allowlist reverses the logic: only explicitly permitted destinations are reachable. Everything not on the list is blocked. Simple, effective, and resistant to creative bypass techniques.

Validate after DNS resolution

Check not only the URL the user provides, but also the IP address the domain resolves to. And perform that check directly before the request, not earlier. This prevents DNS rebinding attacks.

import socket
import ipaddress

def is_safe_url(url):
    hostname = extract_hostname(url)
    ip = socket.gethostbyname(hostname)
    addr = ipaddress.ip_address(ip)

    # Blokkeer private en reserved ranges
    if addr.is_private or addr.is_reserved or addr.is_loopback:
        return False

    # Blokkeer link-local (169.254.x.x)
    if addr.is_link_local:
        return False

    return True

Disable unnecessary protocols

If your server only needs HTTP and HTTPS, block all other protocols: file://, gopher://, dict://, ftp://. Most HTTP libraries support these protocols by default, but you can disable them via configuration.

Enforce IMDSv2 on AWS

If you run on AWS, disable IMDSv1 and use IMDSv2 exclusively:

aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled

--http-tokens required means the metadata service only responds to requests with a valid token. That token is only obtainable via a PUT request with a custom header – something most SSRF vulnerabilities cannot do.

Egress filtering

Restrict outbound traffic from your servers. If your web server only needs to communicate with your database and a few external APIs, configure the firewall so that only those connections are permitted. All other outbound traffic is blocked.

This does not prevent an SSRF vulnerability from being exploited for internal reconnaissance, but it drastically limits the impact. The server cannot send credentials to an attacker if outbound traffic to arbitrary IPs is blocked.

Separate network segments

The metadata service, the database, the cache server, the admin interface – none of them belong on the same network segment as the web server. Segment your network so that the web server can only reach what it strictly needs.

This is the network equivalent of the principle of least privilege: give each component only access to what it needs and nothing more. It sounds obvious. It almost never happens.

The honest conversation about SSRF in 2026

Here is the thing about SSRF that nobody says out loud: it is an architecture problem that is treated as an application problem.

The reason SSRF works is not that developers are foolish. It is that the architecture of cloud computing – and of internal networks in general – is built on the assumption that internal requests are trusted. The metadata service at 169.254.169.254 has no authentication. Redis on the internal network has no password. The admin interface is reachable without a VPN.

Every time a security incident occurs via SSRF, the blame is placed on the developer who did not validate the URL. But the developer works in an environment where "internal" equals "safe", where the metadata service hands out credentials to everyone who asks, and where network segmentation is something they will "get around to".

SSRF is not the problem. SSRF is the symptom. The real problem is that in 2026 we are still building systems that rely on the question "where does this request come from?" instead of "who is sending this request and are they allowed to do this?"

Until we make that fundamental shift – from network-based trust to identity-based trust, from implicit trust to zero trust – SSRF will continue to exist. And penetration testers will write the same prescription like some kind of digital general practitioners: "You really need to do something about that blood pressure." "Yes doctor, I'll get to it."

The difference is that if you ignore your blood pressure, you bear the consequences yourself. If you ignore SSRF, your customer bears the consequences. And your customer does not even know that the metadata service has no authentication. They trust that you have taken care of it.

The server just does what you ask. Maybe it is time we taught the server to say no.

Summary

SSRF is the vulnerability that shows how fragile the concept of a "trusted internal network" is. It transforms a web server from a controlled entry point into a stepping stone to everything that is internally reachable. Cloud metadata, internal services, databases, caches – everything is one URL away.

Defense requires more than a URL filter. It requires architectural changes: allowlists instead of blocklists, IMDSv2 instead of IMDSv1, network segmentation, egress filtering, and abandoning the assumption that internal traffic is trusted.

References