Our website uses cookies to enhance your browsing experience.
to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

close form
Free PVS‑Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

close form
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

close form
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

close form
check circle
Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

Server-Side Request Forgery (SSRF)

Server-Side Request Forgery (SSRF)

Feb 17 2022

Server-Side Request Forgery is a security vulnerability that allows an attacker to send requests on behalf of a compromised server.

For example, an SSRF attack can occur if an application uses unverified external data to generate requests. Attackers can induce an application to send malicious requests to resources that are not directly accessible but are available to the server.

Another variant of an SSRF exploit is request masking. An attacker "hides" behind a vulnerable (intermediary) server to make requests to another server (target). In this case, the target server assumes that an intermediary induces all the requests.

It's worth noting that an XXE attack can cause SSRF.

Every year, the severity of SSRF is becoming higher due to several factors. Nowadays, developers are trying to provide users with more convenient functions. That's why, getting a user-provided URL becomes more popular. Cloud services are also developing rapidly. Architectures become more complex. This makes it difficult to create an effective protection against this attack.

In OWASP ASVS 4.0.3, SSRF is associated with 5.2.6 and 12.6.1 positions. In the OWASP Top Ten 2021 list, it belongs to the A10:2021 — Server-Side Request Forgery (SSRF) category. In Common Weakness Enumeration, this vulnerability corresponds to CWE-918.

An example of vulnerability

To better understand SSRF, let's consider the following example:

void ServerSideRequestForgery()
  var url = Request.QueryString["url"];
  WebRequest request = WebRequest.Create(url);
  WebResponse response = request.GetResponse();
  using (Stream stream = response.GetResponseStream())
    using (StreamReader reader = new StreamReader(stream))

In the code fragment above, the user creates the URL to request the corresponding resource.

Here's an example of a server request to delete a user:


The server is expected to execute such requests only from itself or from trusted devices. If an attacker tries to send a request to delete a user directly (in the form presented above), the server will not process it.

However, an attacker can form a request in a different way:


Based on the passed address, the server addresses the request to itself. In this case, the request will be executed, and the user will be deleted.

Preventing SSRF

At the server-level configuration

  • Divide the network into segments and restrict access to resources outside of them to reduce the impact of SSRF.
  • Ensure "default deny" in the firewall policy to filter traffic.

At the code level

  • Input validation of data supplied by a user.
  • Use the URL schemas, port, and destination with allow list validation.

Also, to prevent SSRF, you should not use block list validation or regular expressions. Attackers can easily bypass these restrictions. For example, they can use redirection. In this case, an attacker creates an external resource that redirects to another URL as a response. Also, to bypass the restrictions, attackers can use alternative representations:

http://2130706433/ =

http://0x7f000001/ =

An example of SSRF prevention with the help of data verification:

string ServerSideRequestForgery()
  var url = Request.QueryString["url"];
  if (!wList.Contains(url))
    return "Forbidden URL";

  WebRequest request = WebRequest.Create(url);

In this case, only allowed addresses will receive the request. If such a solution is not suitable for some reason, then you should change the application logic. For example, if an image is required, a developer should request not the URL, but the file itself.

Additional links

Popular related articles

Comments (0)

Next comments next comments
close comment form