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.

Why you should check values of public m…

Why you should check values of public methods' parameters

Jun 11 2021

This note will answer the question - why PVS-Studio considers parameters of public methods potential sources of tainted data. The analyzer can issue warnings if such parameters haven't been checked before use.


The point is that undue confidence in external data may lead to various vulnerabilities - SQLI, XSS, path traversal and others. Most obvious examples of external data sources: parameter values of requests or text that a user enters (for example, in a text field).

Excessive trust in parameters of public methods can be even more dangerous. Public methods are the ones that can be called from other assemblies. For example, these are public methods of public classes. Most likely, such methods are APIs for interacting with the library.

So, what is the danger?

Developers who use library's APIs may expect data to be verified inside the called method. That's why data from an external source won't be checked before passing to it.

Developers of the library itself may assume that input data is already verified. Therefore, there is no need to check it.

Here's what we may eventually face with. Neither a library user, nor its developer has checked input data. This may lead to vulnerabilities when an attacker passes tainted data.

Note. Below are examples with V5608 diagnostic (search for possible SQL injections). This information relates to other OWASP diagnostics that also consider public methods to be potential sources of tainted data.

Let's see what it might look like in code:

public class DBHelper
  public void ProcessUserInfo(String userName)
    var command = "SELECT * FROM Users WHERE userName = '" + userName + "'";

  private void ExecuteCommand(String rawCommand)
    using (SqlConnection connection = new SqlConnection(_connectionString))
      using (var sqlCommand = new SqlCommand(rawCommand, connection))
        using (var reader = sqlCommand.ExecuteReader())

The DBHelper class provides the ProcessUserInfo method for external use because the method is available from other assemblies. Note that this method's parameter - userName - is not checked before use. The external value is used to create the command directly (command variable). The resulting command is then passed to the ExecuteCommand method. There the command is used without a prior check to create an object of SQLCommand type.

In this case, if you take userName as a source of tainted data, the analyzer will issue a warning about a potential SQLI.

Look at a possible way to use the ProcessUserInfo method by an external application:

static void TestHelper(DBHelper helper)
  var userName = Request.Form["userName"];

The author of this code fragment might not have access to the DBHelper class code and will hope the data is verified inside the ProcessUserInfo method. Neither the current code, nor the ProcessUserInfo method has checked data. This means the application will be vulnerable to SQL injections.

The analyzer won't warn you about potential SQL injection when checking the TestHelper method's code. It is because the tool doesn't have access to the source code of the ProcessUserInfo method. As we see, the case is tricky, so we'd like to let you know about possible dangers beforehand.

Therefore, the analyzer will issue a warning where it will be able to do so. Which is, when analyzing the ProcessUserInfo method's source code. You will get the V5608 warning at the low certainty level.

If you'd like to rid yourself of such warnings, disable them using the comment //-V::5608:3 in the .pvsconfig file. This way, V5608 warnings (SQLI) of low certainty level won't be in the report. Read more about .pvsconfig files in the documentation (section "Suppression of false positives through diagnostic configuration files (.pvsconfig)").

On the other hand, you might want to set high certainty level for such warnings. If so, use the comment //V_LEVEL_1::5608. For details, see ''How to Set Your Level for Specific Diagnostics'' in the documentation.

Popular related articles
Converting string to enum at the cost of 50 GB: let's analyze the CVE-2020-36620 vulnerability

Date: Mar 21 2023

Author: Sergey Vasiliev

In this article, we're going to discuss the CVE-2020-36620 vulnerability and see how a NuGet package for converting string to enum can make a C# application vulnerable to DoS attacks.
Under the hood of SAST: how code analysis tools look for security flaws

Date: Jan 26 2023

Author: Sergey Vasiliev

Here we'll discuss how SAST solutions find security flaws. I'll tell you about different and complementary approaches to detecting potential vulnerabilities, explain why each of them is necessary, an…
Catastrophic backtracking: how can a regular expression cause a ReDoS vulnerability?

Date: Nov 03 2022

Author: Andrey Moskalev

Regular expressions come in handy when you need to search for and replace text. However, in some cases, they may cause the system to slow down or even make vulnerable to ReDoS attacks.
The risks of using vulnerable dependencies in your project, and how SCA helps manage them

Date: Sep 06 2022

Author: Nikita Lipilin

Most applications today use third-party libraries. If such a library contains a vulnerability, an app that uses this library may also be vulnerable. But how can you identify such problematic dependen…
Trojan Source: Invisible Vulnerabilities

Date: Apr 15 2022

Author: Guest

We present a new type of attack in which source code is maliciously encoded so that it appears different to a compiler and to the human eye. This attack exploits subtleties in text-encoding standards…

Comments (0)

Next comments next comments
close comment form
Unicorn with delicious cookie
Our website uses cookies to enhance your browsing experience.