What Is SSRF? The dangerous Server-Side Request Forgery vulnerability

1. What is SSRF?

SSRF (Server-Side Request Forgery) is a security vulnerability that allows an attacker to abuse a web application's server to send requests to internal resources that normally cannot be accessed from outside. In other words, the attacker turns the server into a “proxy” that serves the attack.

Rather than attacking the internal system directly, the attacker sends a specially crafted request to the web application, instructing it to make another request to an address the attacker specifies. Because the request originates from the server itself, the internal system typically trusts it and grants access without close inspection.

In the OWASP Top 10 2021 edition, SSRF is classified under A10:2021 - Server-Side Request Forgery, a new category added because of the increasing severity of this type of vulnerability in cloud computing and microservices architectures.

SSRF differs entirely from client-side vulnerabilities such as XSS or CSRF in that the entire attack takes place on the server side, requires no interaction from the end user, and is not blocked by browser-side protection mechanisms.

2. Why is SSRF a dangerous vulnerability?

SSRF is dangerous not only because of its severe consequences but also because its very nature makes detection and prevention far more complex than typical web vulnerabilities.

2.1. Exploiting the system's trust boundary from within

Requests generated through SSRF originate from the application server itself, not from an external IP. This causes internal systems, backend services, databases, and API gateways to treat the traffic as legitimate and allow access. Traditional firewalls, built to block inbound connections from outside, become nearly useless here because the request has already bypassed that protective layer from the start.

2.2. Hard to detect because the request looks technically valid

Requests routed through SSRF have a completely valid HTTP structure with no obvious malicious payload. Standard monitoring systems can easily miss them without in-depth rules analyzing the destination URL. This is especially true for Blind SSRF, where no response is returned yet the attacker can still gather information through side channels.

2.3. Especially dangerous in microservices and cloud environments

In microservices architectures, services often communicate internally over HTTP without strong authentication because they trust each other within the same internal network. SSRF lets an attacker reach that entire ecosystem through just one compromised application endpoint. On cloud platforms, this is even more dangerous, since metadata endpoints (such as a cloud provider's internal address) often hold credentials that can be stolen through SSRF.

2.4. Blind SSRF returns no response, making it even harder to detect

Not every SSRF attack returns a direct result to the attacker. With Blind SSRF, the attacker cannot see the response but can still confirm that an internal service exists, gather information about the network structure, or trigger side-effect actions through secondary channels such as DNS lookups or system state changes. This makes Blind SSRF very difficult to detect early, especially when application-layer monitoring is lacking.

3. How an SSRF attack works

SSRF is exploited when a web application makes a request to an address controlled by the user without properly validating the destination. The entire attack flow happens on the server side, causing the internal system to trust and process the request as legitimate traffic.

To visualize the mechanism, consider a web application with a feature for loading images from an external URL, one of the most common points where SSRF can be exploited:

• The attacker replaces a valid image URL with an internal address of interest, such as a cloud metadata address or the IP of a database server.
• The web application receives the parameter and makes an HTTP request to that address without validating the destination.
• The internal server receives the request from the application server, which is trusted within the internal network, and returns the data.
• The response, containing sensitive information such as authentication tokens, system configuration, or a list of internal services, is passed back to the attacker through the web application.

The key point in this mechanism is that the web application unintentionally acts as a proxy. The entire process happens on the server side, requires no interaction from the end user, and is not blocked by browser-side protection mechanisms.

To dive deeper into real-world SSRF exploitation techniques, PortSwigger Web Security's technical documentation is one of the most highly regarded resources in the security community today.

4. Types of SSRF

SSRF is not a single uniform type of attack. There are two main variants with different mechanisms and different levels of detection difficulty, each requiring its own detection and prevention strategy.

4.1. Basic SSRF

With Basic SSRF, the attacker receives a direct response from the web application after the server makes a request to the internal address. This is the most straightforward form of the attack: the attacker reads the returned content and gathers credentials, configuration file contents, or data from an internal API within the same request session.

Basic SSRF is relatively easier to detect through logs, since abnormal responses are visible. However, without application-layer monitoring, standard logs can still miss it, because the request looks technically legitimate.

4.2. Blind SSRF

Blind SSRF is more dangerous because there is no clear output returned to the attacker. Instead, the attacker infers information through side channels: response latency reveals whether a port is open, an outbound DNS lookup confirms the server actually connected to the specified address, or an indirect system state change reveals the result of the attack.

Blind SSRF is especially hard to detect using standard monitoring methods. Attackers can use it to map an entire internal network structure and identify which services run where, before moving on to a deeper attack without the security team's knowledge.

Detailed comparison of the two SSRF variants:

5. Protocols exploited in SSRF attacks

Attackers don't rely solely on HTTP/HTTPS to exploit SSRF. Depending on how an application handles input URLs, several other protocols can be abused, each opening a different attack path with a different level of damage.

5.1. HTTP and HTTPS

This is the most commonly used protocol in SSRF exploitation. Attackers use HTTP/HTTPS to access unauthenticated internal APIs, read information from cloud metadata endpoints, or scan web services running inside the internal network. Because this is an entirely ordinary protocol, requests of this kind rarely trigger alerts from monitoring systems unless in-depth rules analyzing the destination URL are in place.

5.2. file://

The file:// protocol allows reading local files directly on the server without going through the network. Attackers use it to read sensitive files such as application configuration files, files containing environment variables, or system files containing account information. This is a dangerous protocol, and there is no legitimate reason a web application should accept a file:// URL from user input.

5.3. dict://

The dict:// protocol was originally designed for querying dictionaries over a network, but in the context of SSRF it can be used to send arbitrary strings to an internal service port. Attackers exploit dict:// to probe internal services, gather software version information, or confirm the existence of a service at a given address and port.

5.4. gopher://

Gopher:// is the most dangerous protocol on this list because of its high flexibility. It lets an attacker build and send arbitrary data to any port, including services such as Redis, Memcached, SMTP, or FastCGI, which often lack authentication within an internal network. Combined with SSRF, gopher:// can lead directly to Remote Code Execution (RCE) without exploiting any additional vulnerability.

Danger level summary by protocol:

6. Real-world SSRF attack examples

Understanding SSRF through concrete scenarios helps technical teams identify risks in real systems and prioritize patching the right spots.

6.1. Attacking cloud metadata

This is the most dangerous and most common scenario in cloud environments. Cloud providers all expose an internal metadata endpoint (usually at a special link-local IP address) so instances can query their own configuration and temporary credentials.

If a web application running on the cloud has an SSRF vulnerability, an attacker can make the application send a request to that metadata endpoint and receive an access token, secret key, or IAM role credentials. With these credentials, the attacker can escalate privileges to take control of the entire cloud account, access storage, view or delete data, or even launch additional instances for further attacks.

6.2. Scanning the internal network via SSRF

Attackers can turn SSRF into a tool for scanning internal ports and services without direct access to the network. By changing the IP address and port number in the request, the attacker relies on differences in response time or error codes to determine which services are running where. From the internal network map gathered this way, the attacker plans the next stage of the attack, targeting the weakest service.

6.3. SSRF in microservices environments

In microservices architectures, services typically communicate internally through REST APIs without strong authentication, based on the assumption that this is trusted traffic from within the network. When a service is exploited via SSRF, the attacker can call other services' APIs without credentials, access user data, change configurations, or read credentials stored in container environment variables.

The damage in a microservices environment is usually greater than in a monolithic application, because a single compromised point can lead to lateral movement across the entire service ecosystem.

7. Consequences of the SSRF vulnerability

When an SSRF vulnerability is successfully exploited, the damage rarely stops at exposing a bit of information; it usually leads to a chain of serious consequences affecting technical operations as well as legal standing and business reputation.

7.1. Exposure of internal data and credentials

The first direct consequence is that the attacker gains access to internal resources that should never be reachable from outside: configuration files, environment variables containing database passwords, private keys, third-party service authentication tokens, and sensitive user information. This information becomes a stepping stone for more dangerous follow-up attacks. This is also a form of data breach that can carry serious legal liability for a business.

7.2. Privilege escalation via cloud metadata

In cloud environments, the most severe consequence of SSRF is the ability to steal credentials from the metadata endpoint to escalate privileges. From a simple SSRF vulnerability, an attacker can gain control of an entire cloud account, including access to storage buckets, databases, and other internal services within the same infrastructure.

7.3. SSRF as a stepping stone for further attacks

SSRF is rarely the endpoint of an attack. Attackers often use it as a first step toward Remote Code Execution (RCE), especially when combined with protocols such as gopher:// targeting unauthenticated services like Redis or Memcached. SSRF is also used for lateral movement, moving across internal services to expand control without exploiting any new vulnerability. In severe cases, an SSRF chain combined with a broken access control vulnerability can lead to a complete system compromise.

7.4. Impact on security compliance

According to MITRE's CWE-918, SSRF is classified as a critical application-layer vulnerability because of its ability to bypass network access controls, creating direct compliance risk with standards such as PCI-DSS (for fintech and electronic payments) and ISO 27001.

In Vietnam, businesses also face compliance requirements under the Cybersecurity Law. In particular, since the Personal Data Protection Law took effect, organizations that process user data have clearer legal obligations to protect personal information from violations, including attacks that exploit security vulnerabilities such as SSRF. Legal consequences for violations include fines, mandatory audits, and in some cases a requirement to publicly disclose the security incident.

8. Effective ways to prevent SSRF

Preventing SSRF requires combining multiple layers of defense across the application, network, and operations levels. No single measure is effective enough on its own without the others.

8.1. Validate and whitelist URLs on the server side

The most basic measure is to carefully validate every URL or IP address supplied by users before making any request. Rather than using a blacklist (blocking known dangerous addresses), it's better to apply a whitelist, allowing requests only to explicitly approved domains, IPs, and ports. Any URL not on the whitelist is rejected without returning detailed information to the user.

8.2. Network segmentation

Apply network segmentation so the web application cannot freely access sensitive internal services. Set up firewalls and access control lists at the network layer to restrict which services can communicate with each other. Even if SSRF is exploited, the attacker will only reach a limited network segment rather than the entire infrastructure.

8.3. Disable or control redirects

HTTP redirects can be abused to bypass a URL whitelist. An attacker points a request to an approved domain, but that domain then redirects to an internal address. To prevent this, disable automatic redirect-following in the server-side HTTP client, or re-validate the destination URL after every redirect.

8.4. Regular testing and patching

Regular pentesting and security reviews help identify points that accept URLs from users without adequate protection. Features such as loading images from a URL, webhooks, website previews, or third-party service integrations are often where SSRF hides the most.

Regular SSRF prevention checklist:

• All user-supplied input URLs are validated and whitelisted before the server makes a request
• The server-side HTTP client does not automatically follow redirects, or the URL is re-validated after redirects
• The web application has no direct access to subnets containing databases, internal APIs, and sensitive services
• Cloud metadata endpoints are blocked or protected with IMDSv2
• Internal services require authentication even for requests from applications on the same network
• The WAF is configured with SSRF detection rules that are updated regularly
• All outbound requests from the server are logged to detect abnormal behavior

9. How VNIS helps businesses prevent SSRF

Effectively preventing SSRF requires a multi-layered defense strategy, from application-side URL validation and network segmentation to an advanced WAF layer capable of analyzing HTTP/HTTPS traffic at the application layer. This is where VNIS (VNETWORK Internet Security) acts as the first and most important line of defense against OWASP Top 10 vulnerabilities, including SSRF.

The WAF within VNIS operates as an intermediary control layer between the internet and the application server, analyzing all HTTP/HTTPS requests in real time before they reach the server. With a continuously updated security ruleset, VNIS can detect and block requests bearing signs of SSRF right at the entry point, including requests containing internal IP addresses, loopback addresses, unusual protocol schemas, or URLs pointing to cloud metadata endpoints. Note that for comprehensive protection, VNIS should be combined with application-side measures such as URL whitelisting and network segmentation.

Beyond SSRF detection at the application layer, VNIS also provides:

• AI-integrated WAAP with a continuously updated security ruleset, directly protecting the processing logic of web, app, and API at the application layer, where SSRF is often exploited most deeply and is hardest to detect
• A 24/7 SOC team that detects and alerts on abnormal behavior in real time, helping technical teams respond promptly before damage occurs
• AI Smart Load Balancing combined with a global Multi-CDN to maintain application speed and stability even under attack, without requiring infrastructure upgrades
• Simultaneous protection for websites, applications, and APIs on a single unified platform, well suited to microservices architectures, the environment where SSRF is most easily exploited

10. Conclusion

SSRF is a dangerous security vulnerability not only because of its severe consequences but also because of how difficult it is to detect. When a request originates from the application server itself, traditional protective layers are easily bypassed. With the growing adoption of microservices architectures and cloud environments, the attack surface related to SSRF continues to expand and demands a multi-layered defense approach. Effective prevention requires combining strict URL validation, Zero Trust-based network segmentation, regular security testing, and an advanced WAF layer.

Contact the VNETWORK team today for a free consultation:

• Hotline: 028 7306 8789
• Email: contact@vnetwork.vn

FAQ - Frequently asked questions about SSRF

1. Which category does SSRF fall under in the OWASP Top 10?

SSRF is classified under category A10:2021 in the 2021 OWASP Top 10 list of security vulnerabilities. This category was newly added based on data from the global security community, reflecting the growing severity of this vulnerability in modern cloud and microservices environments.

2. How does Blind SSRF differ from Basic SSRF?

Basic SSRF returns a direct result to the attacker through the application's response, while Blind SSRF has no clear output. With Blind SSRF, the attacker must infer results through side channels such as response latency, outbound DNS lookups, or system state changes. Blind SSRF is more dangerous because it is much harder to detect, even with standard monitoring systems.

3. Can SSRF lead to RCE?

Yes. SSRF can lead to Remote Code Execution (RCE) in certain situations, especially when an attacker uses the gopher:// protocol to send commands to unauthenticated internal services such as Redis, Memcached, or FastCGI. This is why SSRF should never be underestimated just because it superficially looks like a simple information-disclosure vulnerability.

4. Can a WAF block SSRF?

Next-generation WAFs can detect and block many SSRF variants by analyzing request content, inspecting the destination URL, and identifying unusual protocol schemas. However, a WAF does not fully replace application-layer URL validation and network segmentation. The best protection is achieved when the WAF is one layer within a multi-layered defense strategy, not the sole solution.

5. How can I test whether my application has an SSRF vulnerability?

There are several ways to test: manual pentesting by finding parameters that accept URLs and replacing them with internal addresses or DNS addresses from an external testing toolkit (such as Burp Collaborator); using automated SSRF scanning tools in the CI/CD pipeline; and reviewing the server's outbound request logs to detect unusual connections to internal addresses. It's best to combine all three methods and perform them regularly, not just once at product launch.