Abusing a vulnerable server to make requests to systems that should not be directly accessible
Introduction
Modern web applications rarely operate in isolation. A typical web application may communicate with:
- Internal APIs
- Databases
- Authentication services
- Cloud services
- Monitoring systems
- File servers
- Management interfaces
- Third-party APIs
- Container platforms
In many cases, the web application itself is responsible for making these requests – For example, a web application might allow a user to enter a URL and retrieve information from that location.
This creates a potential security problem – What happens if an attacker can control where the server sends its request?
Instead of requesting https://legitimate.example, the attacker may attempt to make the server request http://internal-server, or http://localhost
In these scenarios, the server becomes an intermediary between the attacker and systems that the attacker may not be able to access directly.
This is the fundamental concept behind a Server-Side Request Forgery (SSRF) attack.
What is SSRF?
Server-Side Request Forgery (SSRF) is a vulnerability in which an attacker can influence a server into making network requests to an unintended destination – The attacker effectively turns the vulnerable application into a network proxy running commands on the attackers behalf.
How SSRF Works
Consider a web application that retrieves images from URLs. A legitimate user might provide:
https://example.com/image.jpg
The application retrieves the image from the directory where the images are stored.
This becomes dangerous if the application does not properly restrict which URLs can be requested. It may allow an attacker to supply an address belonging to an internal system.
The attacker has effectively used the web application as a requesting agent.
Why SSRF is Dangerous
Servers often have network access that ordinary users do not.
An external attacker may only be able to communicate with the web server. The web server, however, may be trusted to communicate with the internal network.
SSRF attempts to exploit this difference to potentially bypass network-level access restrictions.
SSRF Example
Imagine an application containing a function called ImportFromURL
A legitimate user provides the web requesthttps://trusted-site.example/file.xml
In this case, the server retrieves the file.
However, the application may not verify whether the destination is trustworthy, so an attacker could attempt to make the server request an internal service.
If the internal service responds, the application may return the response to the attacker.
SSRF and Internal Networks
One of the most important characteristics of SSRF is its ability to interact with systems that are not directly exposed to the Internet.
The attacker may have access to the Web Server, but not the Internal API – SSRF attempts to bridge that gap.
SSRF and Localhost
Applications frequently communicate with services running on the same host. These services may listen only on the local interface.
In this scenario, an external attacker cannot necessarily access the internal services directly, but if the web application can be manipulated into making requests to local services, the application may be able to reach them.
SSRF and Private IP Addresses
SSRF vulnerabilities can potentially be used to target private network addresses such as :
10.0.0.0/8172.16.0.0/12192.168.0.0/16
These addresses are commonly used for internal networks. If the attacker can trick the server into communicating on the local network, they may be able to obtain data from it
SSRF and Loopback Addresses
Attackers may also attempt to target the server’s loopback interface (127.0.0.1 or localhost)
Services bound only to localhost are not normally accessible from external systems, but the vulnerable application is running on the server itself, therefore making it possible for an attack to target those services
SSRF and Cloud Environments
SSRF becomes particularly important in cloud environments. Cloud platforms commonly provide services accessible from within cloud workloads. Some environments expose a metadata service that provides information about the instance or workload.
This can potentially include:
- Instance information
- Configuration information
- Temporary credentials
- Identity information
- Cloud environment details
This is one reason SSRF is considered particularly serious in cloud-native environments.
Cloud Metadata Services
Cloud metadata services exist to allow workloads to obtain information about their environment.
This is useful for legitimate applications.
However, if an attacker can force a vulnerable server to query the metadata service, the resulting information may potentially assist further attacks.
SSRF and Credentials
One of the most serious consequences of SSRF is the potential exposure of credentials. Depending on the environment and configuration, an internal service may return information containing:
- API credentials
- Access tokens
- Temporary cloud credentials
- Configuration secrets
- Authentication information
The SSRF vulnerability may therefore be only the first stage of a much larger attack.
SSRF and Internal APIs
Modern applications frequently use internal APIs.
These services may not be exposed directly to the Internet, rather they may rely on the assumption that “Only trusted internal systems can access this service.”
SSRF can challenge that assumption – The vulnerable server may already be trusted by the internal API.
SSRF as a Network Pivot
SSRF can act as a form of network pivoting. The attacker begins outside the network. The vulnerable application then provides access to the Internal Network and Internal Services
The attacker has effectively gained a limited network position without directly connecting to the internal network.
SSRF and Port Scanning
A vulnerable application can potentially be abused to determine whether internal services are reachable.
By making the server conduct internal communications, different responses may reveal whether a service exists.
For example if the response is Connection refused, it usually indicates that a host is reachable but the port is closed. A successful response may indicate an active service, and a timeout may indicate filtering or an unreachable host.
This can allow an attacker to build a picture of the internal network.
SSRF as Internal Reconnaissance
The attacker may use SSRF to discover:
- Internal hosts
- Open ports
- Internal APIs
- Management interfaces
- Monitoring services
- Administrative panels
- Cloud services
This makes SSRF particularly valuable during the reconnaissance phase of an attack.
SSRF and Authentication Bypass
Some internal services may rely on network location as part of their security model.
For example, External users may be denied access, but Internal systems are allowed
If SSRF allows an attacker to make the request originate from the vulnerable server, the internal service may treat the request differently. This can potentially bypass weak network-based access controls.
However, a secure architecture should not rely solely on network location as proof of identity.
SSRF and Internal Administration Interfaces
Management interfaces are particularly attractive targets. A server may have an administrative interface that is intentionally restricted to internal networks. The interface is not directly reachable from the Internet.
However, a vulnerable server may provide a path to it.
If the administrative interface contains sensitive functionality, the consequences can be severe.
SSRF and Containers
Containerised environments can also introduce additional SSRF considerations. A compromised application running inside a container may have access to:
- Internal container services
- Host services
- Kubernetes APIs
- Cloud metadata
- Internal network resources
An SSRF vulnerability in the containerised web application may allow it to communicate with services that should not be directly accessible to users.
SSRF and Kubernetes
Kubernetes environments contain several components that may be relevant to SSRF attacks. Potential targets can include:
- Kubernetes APIs
- Internal services
- Pod interfaces
- Node services
- Cloud metadata
- Service discovery systems
The impact depends heavily on network policies, authentication, service-account permissions, and cluster configuration.
SSRF should therefore be considered as part of the broader cloud-native attack surface.
SSRF and URL Parsers
One of the technical difficulties in preventing SSRF is reliably determining whether a supplied URL is safe or not. Applications may attempt to block:
- Private IP addresses
- Localhost
- Internal hostnames
- Cloud metadata addresses
However, URL handling can be complicated – Different representations of the same destination may be interpreted differently by:
- Applications
- URL parsers
- DNS resolvers
- Proxies
- HTTP clients
- Operating systems
This can create opportunities for security controls to be bypassed.
SSRF and Redirects
Redirects are another important consideration. An application may initially validate a URL as safe – The server then follows a redirect to another destination.
If the application validates only the initial destination, the final request may bypass the intended restriction.
Applications should therefore carefully control how redirects are handled.
SSRF and DNS
DNS can also complicate SSRF protections. An application may resolve a hostname and determine that it points to a permitted public address, however, the destination may subsequently resolve differently.
The security lesson is that SSRF protection should consider the complete request lifecycle rather than simply checking a URL string.
Blind SSRF
Not every SSRF vulnerability returns the response to the attacker – This is known as Blind SSRF.
The attacker may not receive the internal response, but they may still be able to determine that a request occurred through indirect evidence.
For example:
- Timing differences
- DNS interactions
- External callbacks
- Application behaviour
- Network telemetry
Blind SSRF can therefore still represent a significant vulnerability.
SSRF vs CSRF
SSRF and Cross-Site Request Forgery (CSRF) have similar names but are fundamentally different.
| Feature | SSRF | CSRF |
|---|---|---|
| Full name | Server-Side Request Forgery | Cross-Site Request Forgery |
| Attacker abuses | Server | Victim’s browser |
| Main objective | Make server access unintended destination | Make browser perform unintended action |
| Typical target | Internal services | Authenticated web application |
| Network pivot | Yes | Generally no |
| Authentication abuse | May target internal trust | Abuses existing browser session |
The simplest distinction is:
- CSRF abuses the browser.
- SSRF abuses the server.
Detecting SSRF
SSRF can be difficult to identify because requests may originate from legitimate application servers.
Security teams should monitor for:
- Unexpected outbound requests
- Requests to private IP addresses
- Requests to localhost
- Requests to unusual ports
- Requests to cloud metadata services
- Unexpected DNS lookups
- Connections from web servers to internal administration interfaces
- Unusual URL parameters
- Repeated requests to internal address ranges
- Unexpected protocols or schemes
Application and network logs should be correlated.
SSRF Detection Indicators
Security teams should pay particular attention to:
- Destination – Is the server connecting to an unexpected internal address?
- Port – Is the application accessing an unusual service port?
- Frequency – Are there many requests to different internal hosts?
- Parameters – Does a request contain a suspicious URL parameter?
- DNS – Is the application resolving unexpected internal hostnames?
- Cloud – Is the application contacting metadata infrastructure?
- Behaviour – Does the activity begin immediately after unusual web requests?
Correlating these indicators can reveal an SSRF attack.
Preventing SSRF
SSRF prevention should use multiple layers.
- Allow-list destinations – Where possible, applications should define exactly which destinations are permitted. Allow-listing is generally safer than trying to maintain a blacklist of dangerous destinations.
- Validate URLs Carefully – Applications should properly parse and validate URLs. Simply checking whether a URL contains a particular string is unlikely to provide sufficient protection.
- Restrict Outbound Network Access – Applications should not automatically be allowed to communicate with every network.
- Network Segmentation – Internal services should be segmented according to their security requirements.
- Protect Cloud Metadata Services – Cloud environments should use the strongest available metadata protection mechanisms. Where supported, organisations should prefer modern metadata service protections and workload identity mechanisms.
- Authentication for Internal Services – Internal services should not assume that “Internal network = trusted user”. Authentication and authorisation should still be required.
- Restrict Redirects – Applications should carefully control redirects. This reduces opportunities for attackers to turn an apparently safe request into an internal request.
- Protect Against DNS-Based Bypass – SSRF protections should consider DNS resolution.
SSRF Prevention Checklist
Organisations should consider:
- Allow-list permitted destinations.
- Validate URLs server-side.
- Restrict allowed protocols.
- Restrict outbound network access.
- Block unnecessary private network access.
- Block localhost and loopback destinations where appropriate.
- Protect cloud metadata services.
- Restrict redirects.
- Validate DNS resolution.
- Consider IPv4 and IPv6.
- Authenticate internal services.
- Implement network segmentation.
- Monitor outbound requests.
- Monitor unusual DNS activity.
- Log user-controlled URL requests.
- Scan applications for SSRF vulnerabilities.
- Keep frameworks and libraries updated.
- Apply least-privilege network access.
Why SSRF Matters in Modern Infrastructure
SSRF has become particularly important because modern applications increasingly operate inside complex environments. A single application may have access to the Internet, Internal APIs, Cloud Services, Containers, Kubernetes, Databases, and Management Systems.
The more network access the application has, the greater the potential impact of SSRF.
This makes least-privilege network design an important security principle – Applications should only be able to communicate with the systems they actually require.
Restricting unnecessary network access reduces the potential impact of SSRF.
Conclusion
Server-Side Request Forgery (SSRF) is a vulnerability in which an attacker manipulates a server into making network requests on their behalf.
The attacker may be unable to access an internal resource directly, but a vulnerable server may already have access to it.
This creates the fundamental SSRF attack path.
SSRF can potentially be used to:
- Access internal services
- Perform internal reconnaissance
- Reach management interfaces
- Interact with internal APIs
- Access cloud metadata
- Obtain credentials
- Pivot into other systems
- Bypass network-based access restrictions
The risk is particularly significant in cloud, containerised, and Kubernetes environments, where applications may have access to a large number of internal services.
Effective protection requires multiple layers.
Strict URL validation, destination allowlisting, outbound network restrictions, network segmentation, authentication, cloud metadata protection, secure DNS handling, and continuous monitoring can significantly reduce the risk.
The key lesson is simple – Never allow an application to blindly make network requests to destinations controlled by an untrusted user.
A public-facing application may have access to resources that an attacker cannot reach directly.
SSRF turns that trusted access into a potential attack path.