Input validation is the practice of checking that any input that your website accepts is what you expect it to be.
For a website to provide almost any kind of interactivity or customization it will need to accept some input, typically from users via a web browser, and sometimes also from other applications.
Users typically enter information into <input> elements in a <form> element on the site's front end, and the data is typically sent to the server as the body of a POST request, or as URL parameters appended to a GET request. However, input might also arrive on the server via other means, such as cookie values or additional HTTP headers.
If the input provided by the user doesn't have the form or content that the site expects — for example, if they enter an invalid email address — this can cause the site to malfunction. Catching problems like this as early as possible improves the user's experience.
However, aside from innocent errors by the user, supplying unexpected input enables a malicious actor to attempt various security attacks, including cross-site scripting (XSS), SQL injection, and command injection. In these situations, the attacker deliberately crafts some input that will enable an attack, and passes it to the application. The attacker might completely bypass the website's front-end, providing the malicious input directly in an HTTP request. Although input validation is not usually a complete solution to these security threats, it's an important first line of defense.
Applications can often implement a given check by specifying it in terms of the values that are allowed (an "allowlist") or in terms of those that are denied (a "denylist").
For example, suppose we wanted to check that a numeric input is between zero and 10. We can implement this as an allowlist by testing that the input matches this range, and denying everything else:
function checkRange(input) {
if (input >= 0 && input <= 10) {
return true;
}
return false;
}Alternatively, we can implement it as a denylist by testing whether the input is outside the range, and allowing everything else:
function checkRange(input) {
if (input < 0 || input > 10) {
return false;
}
return true;
}It's usually more reliable to implement a check as an allowlist, as this defaults to denying values that the author didn't consider. This is especially true when the invalid input is being deliberately crafted by an attacker: it's easier for an attacker to provide some input that would evade the check, and fall through to the default "allow" condition.
We can distinguish two types of input validation:
Applications typically implement syntactic validation using the type-checking features of their chosen programming language.
To implement semantic validation, they can use various methods including range checking, checking a value against a set of allowed values, or, for more complex cases, regular expressions.
Note that regular expressions can be hard to get right, and some expressions may make an application vulnerable to denial of service attacks. For this reason, it's usually better to use well-regarded third party validation libraries. One popular choice is validator.js.
Applications should validate input as soon as possible after it has been entered, so the user has immediate feedback about the problem, and can be given the chance to fix it. This generally means that you should validate input on the client side, in the website's front-end code.
However, you must not rely on front-end validation to catch security issues, because an attacker may subvert or completely bypass the front-end code. So you must also validate input on the server, before processing it.
The HTML <input> element supports a number of attributes that enable you to define valid values for the input the user provides. They include:
type, which defines the type of input that is expected, and triggers validation based on the type. For example, if type is email, then the browser will automatically check that the input is a syntactically valid email address.
minLength and maxLength, which define the minimum and maximum lengths that textual input is allowed to have.
min and max, which define the minimum and maximum values that a numeric value is allowed to have.
step, which defines the granularity that a numeric input value must have.
pattern, which defines a regular expression that textual input must match.
You can also define a custom validity check in JavaScript, by adding an event handler to the element's change event. Inside the event handler, you can perform a custom validity check, and then call the element's setCustomValidity() method to set its validity.
If the input fails validation, the browser will not submit the form, and will instead show an error message to the user.
See Using HTML form validation for more information.
On the server side, applications should, if possible, use the validation functions provided by their framework of choice, such as Django's validators.
It's especially important to pay attention to validation failures which could not have been made by a user interacting with the site's front end: for example, a <select> element containing an option that was not provided in the form's HTML. Failures like this are strong indicators that an attacker is deliberately crafting invalid input.
When input is represented as JSON, you can use JSON Schema to define validity: this includes APIs that are specified using OpenAPI. If you use a database, you can also define a database schema and validate input against that.
If your site allows file uploads, you need to consider various additional threats. Attackers may:
The following best practices are commonly used to mitigate these threats:
Only allow authenticated users to upload files.
Filenames are also user input, so they need to be validated. If possible, generate your own name for files you save. If you have to use the names provided by users, be highly restrictive in the characters that users may choose, and validate names against this.
Determine which file types you need to support, and allow only these types, based on the file extension. Be especially wary of web-executable file types such as HTML or JavaScript. Since checking file extensions involves processing the filenames provided by users, be sure to validate filenames first.
Restrict the size of files that can be uploaded.
Allow users to report undesirable or illegal content, and have a process for removing it.
If possible, store files on a different host. If this is not possible, store files outside the website's root. This reduces the risk that malicious uploads could be served to other users in attacks such as XSS.
For more details, see OWASP's File Upload Cheat Sheet.
Tricking a site into accepting malicious input is a vector for a number of attacks in which the site inadvertently executes the content as code or as a command. This includes:
Cross-site scripting (XSS) attacks, in which the browser executes malicious code as though it were part of the website.
SQL injection attacks, in which the server executes malicious SQL queries on their database.
Command injection attacks, in which the site runs malicious commands on the host's operating system.
Generic input validation as we've discussed it here is a useful first line of defense against attacks like this, but it is not a complete defense against them, or even the primary defense. This is because it's extremely hard to protect against these attacks without knowing the specific context in which the input will be used.
Instead, applications should use defenses that are specific to these attacks: