Input Validation

In Turkish: Girdi Doğrulama

Updated September 30, 20263 min read

In short

Input validation is the practice of checking that data entering a program has the expected type, format and range before it is used, and rejecting the rest.

What is input validation?

Input validation means checking every piece of data that comes from outside a program, such as form fields, URL parameters, JSON bodies, headers, uploaded files, and messages from other services, before trusting it. The program confirms that the data has the right type, length, format, and range, for example that an age is a whole number between 0 and 150 or that a country code is on a known list. Anything that fails is rejected with a clear error instead of being passed deeper into the system.

The strongest approach is allowlist validation: define exactly what is allowed and reject everything else, rather than trying to block a denylist of known bad values, which attackers can usually get around. Validation must happen on the server, at the boundary where data enters, because checks in the browser are only a convenience for users and can be skipped with a simple script. Many teams describe the expected shape of their data with a schema, using a validation library or a standard such as JSON Schema, so the same rules are enforced everywhere.

Validation protects both correctness and security: it stops bad data from corrupting the database and shrinks the room attackers have to work with. It is like a bouncer checking IDs at the door: people who don't meet the rules never get inside, which makes everything inside easier to manage. Rules should cover business logic too, such as refusing a negative quantity or a discount code that has already expired.

Input validation is often confused with output encoding and sanitization, and it is sometimes treated as a complete defense against injection. Validation decides whether data is acceptable, while output encoding makes data safe for a specific context at the moment it is used, such as escaping HTML to prevent XSS or using parameterized queries to prevent SQL injection. A perfectly valid name like O'Brien can still break a badly built SQL string, so validation is one layer of defense, never the only one.

Key takeaways

Validate all external input for type, length, format, and range before using it.
Prefer allowlists of what is permitted over denylists of what is forbidden.
Always validate on the server; client-side checks can be bypassed.
Schemas keep validation rules consistent and easy to review.
Validation complements, but does not replace, output encoding and parameterized queries.

Example

Validating an order on the servertypescript

type Order = { productId: string; quantity: number; country: string };
const COUNTRIES = new Set(["US", "DE", "JP", "BR"]); // allowlist

function parseOrder(input: any): Order {
  const { productId, quantity, country } = input ?? {};
  if (typeof productId !== "string" || !/^[a-z0-9-]{1,40}$/.test(productId))
    throw new Error("productId must be 1-40 lowercase letters, digits, or dashes");
  if (!Number.isInteger(quantity) || quantity < 1 || quantity > 100)
    throw new Error("quantity must be a whole number from 1 to 100");
  if (!COUNTRIES.has(country)) throw new Error("unsupported country");
  return { productId, quantity, country }; // only known, checked fields
}

Readers ask

Is client-side validation enough?

No. Browser checks improve the user experience by catching mistakes early, but anyone can bypass them by sending requests directly. The server must always validate input again.

What is the difference between input validation and sanitization?

Validation checks whether input meets the rules and rejects it if not. Sanitization changes input to make it safe, for example by stripping disallowed HTML tags, and should be used only when you must accept content such as rich text.

Does input validation prevent SQL injection?

It helps by rejecting unexpected values, but it is not a reliable defense on its own, because some valid input contains characters like quotes. Parameterized queries are the primary defense against SQL injection.