This project is read-only.

How To: Validate Input and Data

J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat.


Designing an effective validation mechanism is important for the security and reliability of your application. Failing to do so can make your application vulnerable to cross-site scripting, SQL injection, buffer overflow, and other types of malicious input attack. However, there is no standard definition that can differentiate valid input from malicious input. In addition, how your application actually uses the input influences the risks associated with exploit of the vulnerability.


  • Objectives
  • Overview
  • Summary of Steps
  • Step 1 – Identify your trust boundaries
  • Step 2 – Identify the key scenarios
  • Step 3 – Determine where to do validations
  • Step 4 – Identify validation strategies
  • Additional Resources


  • Identify your trust boundaries and data to validate.
  • Identify the key scenarios to perform validation.
  • Determine where to do validation.
  • Determine validation strategies.


When designing input and data validation for your application, the first task is to identify the trust boundaries and key scenarios when data should be validated. Next, identify the data to be validated and the location where it should be validated. You should also determine how to implement a reusable validation strategy. Finally, determine the validation strategy appropriate for your application.

Summary of Steps

  • Step 1 - Identify your trust boundaries
  • Step 2 - Identify the key scenarios
  • Step 3 - Determine where to do validations
  • Step 4 - Identify validation strategies

Step 1 – Identify your trust boundaries

Trust boundaries indicate how trusted and untrusted data is separated. Data on one side of the trust boundary is trusted and the other side is untrusted. You should first identify the data which is crossing trust boundaries. This will help you to determine the data which you should validate. Consider the use of input validation and data validation at every trust boundary to mitigate security threats such as cross-site scripting and code-injection. Consider the following tasks for identifying the trust boundaries of your application:
  • Identify the systems and subsystems that your application communicates with.
  • Identify your outer system boundaries which are crossed when writing to files on a server, making calls to the database server, or calling a Web service.
  • Identify the entry points at the trust boundaries and implement authentication.
  • Identify the exit points where you write data from client input or from untrusted sources such as shared databases.

Following are few examples of trust boundaries:
  • A perimeter firewall.
  • The boundary between the Web server and database server.
  • The boundary between your application and a third-party service.
  • The data access components trust the business components to pass fully validated data.

Check Point

Before you finish this step, you should be able to answer the following questions:
  • Have you identified the trust boundaries of your application?
  • Have you identified the data which crosses the trust boundary?

Step 2 – Identify the key scenarios

In the first step you have identified the trust boundaries within your application. This step will define the key scenarios where you would need to validate data.

Following is the data on the presentation layer (form validation) should be validated:
  • Form fields: All user entered data should be considered malicious until validated.
  • Parameters like GET, POST data, query strings, hidden fields: Malicious users can intercept HTTP requests and modify the contents, so validate the data before use.
  • Cookies: As cookies reside on the client machine, these are exposed to be modified.

Validation on the business layer:
  • Business logic validation: The business layer provides the business logic for applications. Business rules impose a constraint on the data and violating any constraint is assumed to be a validation error. In case of any business rule violation, the business layer should raise an error to represent the violation.
  • Rules Engine: A rule consists of one or more conditions and a set of actions which should be performed in case the condition satisfies. The rules engine knows by itself when to examine each rule, based upon the information required for that rule and the conclusions made from the evaluation of previous rules. There is no need to procedurally specify the appropriate order and dependencies of the rules.

Common scenarios for validation:
  • To prevent the injection of malicious data by checking to see if a string is too long or if it contains illegal characters.
  • To enforce business rules and to provide responses to user input.
  • To validate data within the same application. For example, you may need to validate data at the UI layer to give immediate feedback when a user enters an invalid data value, and again at the service interface layer for security.

Check Point

Before you finish this step, you should be able to answer the following questions:
  • Have you identified the key scenarios for data validation?
  • Have you identified the data on each layer which needs to be validated?

Step 3 – Determine where to do validations

In this step, you should determine where the validations should be performed. Validation can be performed on the client side or server side or both. Both of these have advantages and disadvantages as mentioned below. Do not depend on the client-side validation alone. Implement server-side validation to securely validate the data.
  • Client-side data validation: Implement client-side validation to reduce round trips to the server and to improve the user experience. The basic condition to implement client side validation is that the client’s browser should support DHTML and JavaScript. Client side validation can also be implemented in VBScript, but it is support only by IE, so it will not work on other browsers. Ideally implement the JavaScript validation in a separate JS file which will provide reusability and also will be cached by the browser. Business rules validation can also be implemented using JavaScript. Another option is to use the ASP.Net validation controls which provide a set of server controls and can be used to validate data in server controls, but not useful with HTML controls. Development effort is reduced using validation controls, but the amount of HTML rendered on the browser increases.
  • Server-side data validation: Even though client-side validation is implemented it might be necessary to implement server-side validation as a malicious user can override the client validation. Also some browsers may not support scripting. Implement the logic to validate the input data when the form is submitted. The sever validation can be implemented using ASP.Net validation controls, within the code of UI process components or using Validation Application Block. Use the VAB for out-of-the-box validation logic which can be reused across layers. The VAB can be used with Windows Forms, ASP.Net as well as WPF.

Centralize input validation

As all applications need to validate input, performing it in a single centralize location which will ensure consistency. Centralization also enables you to change validation standards in a consistent manner whenever data formats change. The development effort reduces and it also enables easy maintainability.

Validation Application Block

The Enterprise Library Validation Application Block provides a library of classes, called validators, that supplies the code for validating .NET Framework data types. For example, one validator checks for null strings and another validator checks that a number falls within a specified range.
By using the Validation Application Block, you can perform validation and create rule sets in the following three ways:
  • Using configuration
  • Using attributes
  • Using code
In addition, the Validation Application Block includes adapters that allow you to use the application block with the following technologies:
  • Windows Forms
  • Windows Communications Framework (WCF)

Check Point

Before you finish this step, you should be able to answer the following questions:
  • Do you need to implement client-side validation?
  • Have you identified how to implement server-side validation?
  • Have you centralized the data validation?

Step 4 – Identify validation strategies

Following are the strategies for data validation. Understand each strategy and decide which one should be applied for each value.
  • Accept known good (Blacklist or positive validation): Allow only the data which satisfies the matching criteria and all other data is rejected. Use this strategy in most cases as it is the safest which will allow only the data which satisfies the condition.
  • Reject known bad (Whitelist or negative validation): Allow data which doesn’t contain a known set of characters. Use this strategy cautiously and as a secondary defense as it is very difficult to create a complete list of known invalid characters.
  • Sanitize: Eliminate or translate characters in an effort to make the input safe. Similar to the negative validation the list of unsafe characters may not be complete.

Following are the best practices for data validation:
  • Assume all input data is malicious.
  • Validate input data, encode output, and do not trust the data retrieved from a shared database.
  • Keep the validation logic separate from the application code. This will allow updating the validation logic without touching the application code.
  • Implement the validation logic so that it can be reused across layers in an application and also across applications.
  • On the UI restrict the user from entering invalid data.
  • Perform client-side validation to catch validation errors as early as possible. It will avoid round trips and improve responsiveness.
  • Do not rely on client side validation – design for server side validation as well – this is important from security perspective as client side validations can be easily compromised.
  • No input validation controls are provided in the Smart Device Extensions for Microsoft Visual Studio .NET, so you must implement your own client-side validation logic to ensure that all data entry is valid.

Following are the common pitfalls for data validation:
  • Allowing user to enter invalid data and validate the data after user submits it.
  • Allowing user to enter data in controls which is not allowed to be modified.
  • Lack of validation across trust boundaries
  • Not validating for all the parameters like “Range” , “Type” and “Format”
  • Not reusing the validation logic

Check Point

Before you finish this step, you should be able to answer the following questions:
  • Have you identified the various validation strategies?
  • Did you choose the appropriate strategy for your application?

Additional Resources

For more information on general data access guidelines, see the following resources:

Last edited Dec 17, 2008 at 10:13 PM by prashantbansode, version 1


No comments yet.