Server-Side Request Forgery: How SSRF Bypasses Your Network Defenses
SSRF turns your server into a proxy, allowing attackers to scan internal networks and access cloud metadata without ever touching the outside world directly.
Server-side request forgery occurs when your application fetches a URL from an untrusted source without validating it. This lets attackers make your server request internal resources, private cloud data, or other machines, bypassing standard access controls and firewalls.
The Proxy You Did Not Build
Imagine a receptionist who fetches documents from public shelves for clients. A malicious client asks for a document from a locked cabinet in the back office. The receptionist, trusting the request comes from inside the building, retrieves it. The client now has internal data. Your server acts as that receptionist. It has network access that the attacker does not. When you let user input dictate where that server looks, you hand them the keys to your internal infrastructure.
This is not a bug in a library or a framework. It is a logic flaw in how you handle user-supplied URLs. The server performs the request, not the browser. This distinction matters because the server sits behind your firewall. It can reach services that the internet cannot.
| Aspect | Detail |
|---|---|
| Core Mechanism | Application fetches URL from user input without validation |
| Primary Target | Internal services, cloud metadata, local files |
| Key Vector | Unvalidated or insufficiently validated URLs |
| Impact | Data exfiltration, port scanning, further attacks |
| Common Fix | Allowlisting permitted domains and schemes |
How the Forgery Takes Place
The flaw exists when your code takes a string from a user and passes it to a function that opens a network connection. This often happens in features like importing images, fetching webhooks, or checking link validity. The attacker provides a URL. Your server resolves it and sends the traffic.
You might think you are safe because you block external IP addresses. You are not. The server resolves the DNS name. If the name points to an internal IP, the request goes through. Even if you block internal IPs, the attacker can use DNS rebinding. They control a domain that resolves to an external IP first, then changes to an internal IP. The server makes the request after the switch.
This is why understanding API vulnerabilities is part of the broader picture. Many APIs accept URLs as parameters. If those parameters go straight to a fetch function, you have created an SSRF vector. The API does not know the difference between a public image and your internal billing system.
What Internal Resources Are Exposed
The damage depends on what your server can reach. In a traditional data center, this might mean other application servers or databases. In cloud environments, the risk is higher. Cloud providers offer metadata services. These are local HTTP services that return configuration details. They often include temporary credentials.
If an attacker can hit that metadata endpoint, they get those credentials. They can then list storage buckets, create new users, or spin up expensive instances. This leads directly to cryptojacking or data theft. The attacker does not need to break into the server. They just need the server to talk to itself.
Localhost is a frequent target. Services like Redis, MongoDB, or debug interfaces often run on port 8080 or 9200. They rarely have authentication. A single SSRF request can dump the entire database. The attacker never touches the database port. They touch your web port. Your web port talks to the database.
Common Forms of the Attack
Attackers use several tricks to bypass simple filters. Knowing these helps you write better defenses.
- If you do not check for private IP ranges, this works.
- IPv6 and Hex: Some filters only check IPv4.
- File Protocol: The URL
file:///etc/passwdreads local files. This is SSRF if the server supports thefilescheme. - DNS Rebinding: As mentioned, the domain changes its IP after the initial check but before the request.
- Gopher and Dict: These protocols can interact with telnet or SMTP servers, allowing command injection in some cases.
Suppose you block http and https to internal IPs. You might miss gopher://. This protocol can send raw TCP data. If your server supports it, the attacker can talk to internal telnet servers. This is a hidden cost of supporting many URL schemes.
What People Usually Get Wrong
Many teams think input validation is enough. They check that the URL looks like a website. They fail to check where it points. This is the server-side template injection mistake. You treat the input as data, but the server treats it as an instruction.
Another error is relying on blacklisting. You block known bad domains. The attacker registers a new one. You block internal IPs. The attacker uses DNS rebinding. Blacklists are reactive. They always lag behind new tricks.
People also ignore the response. If the server returns the content of the fetched URL, the attacker can see if a port is open. This is blind SSRF. Even if no data is returned, the timing of the response tells the attacker if the service exists. This is how security regression testing often misses these bugs. The test checks for errors, not for successful internal connections.
How to Reduce the Risk
Start with allowlisting. Define which domains your application needs to reach. Only allow those. If a user inputs a URL, check it against this list. Do not check the IP. Check the domain. This blocks DNS rebinding. If you must allow user domains, verify the IP after resolution and ensure it is public.
Disable unused URL schemes. If you do not need file:// or gopher://, turn them off. Most HTTP libraries allow you to restrict schemes. Do this at the library level, not just in your code.
Use network segmentation. Your web servers should not need to talk to databases directly. Put them in different network zones. If SSRF occurs, the request hits a firewall, not the data. This is a defense in depth measure. It does not fix the bug, but it limits the blast radius.
Review your IT asset inventory. Know what services run on your servers. If you have a debug interface on port 8080, remove it in production. Attackers scan for common ports. If the service is not there, the SSRF fails.
Beyond Simple Validation
Validation is the first line, but it is not the last. You need monitoring. Log all outgoing requests from your application. Look for requests to internal IPs or unusual ports. This helps you detect SSRF even if you miss a fix.
Consider using a dedicated proxy for outbound requests. This proxy can enforce policies. It can block internal IPs. It can log traffic. This separates the application logic from the network access. It adds a layer of control that is hard to bypass.
Remember that SSRF is often a stepping stone. It is rarely the end goal. The attacker uses it to get credentials or access other systems. Treat it as a critical finding. Fix it quickly. Use security bulletins to track new bypass techniques. The methods evolve. Your defenses must too.
Key takeaways
- SSRF exploits the trust the application has in its own network position.
- Internal IP addresses and localhost are not the only vectors; DNS rebinding works too.
- Blocking outgoing traffic is difficult; input validation and allowlisting are more reliable.
SSRF turns your server into an unwitting scanner of your own internal network. Implement strict allowlisting for outbound URLs and disable unnecessary URL schemes to stop this at the source.
Frequently asked questions
Is SSRF the same as XSS?
No. XSS runs code in the victim's browser. SSRF makes the server make requests. XSS targets users. SSRF targets the infrastructure.
Can a WAF stop SSRF?
Sometimes. WAFs can block known bad patterns. They often miss new bypasses like DNS rebinding. They are a net, not a wall.
Does HTTPS prevent SSRF?
No. HTTPS encrypts the traffic. It does not stop the server from requesting an internal IP. The server trusts the connection regardless of encryption.
How do I test for SSRF?
Send various URLs to endpoints that fetch content. Try internal IPs, localhost, and file paths. Look for differences in response time or content.
How this guide was produced: written by the Vector Tribune editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
