Input Validation
Input validation is the practice of checking all data received from users and external sources against expected formats, types, lengths, and ranges before processing it, serving as the first line of defense against injection attacks.
Understanding Input Validation
Every piece of data that enters your application from an external source — form fields, URL parameters, HTTP headers, file uploads, API payloads, webhooks — is potentially malicious. Input validation ensures this data conforms to expected patterns before the application processes it. The principle is simple: never trust user input.
Validation should happen at multiple levels. Client-side validation provides immediate user feedback but offers zero security since it can be bypassed entirely. Server-side validation is where security enforcement happens. Database constraints provide a final safety net. Each layer catches issues the others might miss.
There are two fundamental approaches. Allowlisting (positive validation) defines what is permitted and rejects everything else — for example, a username must match ^[a-zA-Z0-9_]{3,20}$. Denylisting (negative validation) defines what is forbidden and accepts everything else — for example, rejecting input containing <script>. Allowlisting is always preferred because it is impossible to enumerate all malicious inputs, but new attack patterns can bypass denylists.
Modern applications should use schema validation libraries like Zod, Yup, or Joi that define the expected shape of input data and validate it declaratively. These libraries handle type checking, range validation, string pattern matching, and nested object validation in a way that is maintainable and comprehensive. They also provide TypeScript type inference, making the validated data type-safe throughout the application.
Why This Matters for Vibe-Coded Apps
AI-generated APIs frequently accept whatever data the client sends without validation. The AI builds the happy path — accepting valid data and processing it — but does not consider what happens when malformed, oversized, or malicious data arrives. This leads to injection attacks, type confusion errors, and application crashes.
When reviewing AI-generated code, check every endpoint that accepts input. Does it validate the type, length, and format of each field? Libraries like Zod integrate well with TypeScript and can be added to AI-generated code with minimal changes. Ask the AI to add Zod validation to your API endpoints — it generally produces good validation schemas when explicitly prompted.
Real-World Examples
Log4Shell (CVE-2021-44228)
The Log4Shell vulnerability demonstrated the consequences of processing unvalidated input in log messages. A specially crafted string in any logged field triggered remote code execution through JNDI lookups. Input validation that rejected or sanitized JNDI lookup patterns could have prevented exploitation.
PHP Type Juggling Attacks
PHP's loose type comparison has been exploited in numerous applications where input validation did not enforce strict types. Passing 0 where a string is expected can bypass authentication checks because 0 == "password" evaluates to true in loose comparison. Strict type validation prevents these attacks.
Billion Laughs XML Attack
An XML parsing attack uses nested entity definitions to create an exponentially expanding payload that consumes all available memory. Without input validation that limits entity expansion or rejects excessively nested XML, a small input file can crash servers by consuming gigabytes of RAM.
Frequently Asked Questions
Is client-side validation sufficient?
No. Client-side validation provides user experience benefits (immediate feedback) but offers no security. An attacker can bypass client-side validation by disabling JavaScript, modifying the DOM, or sending requests directly to the API with tools like curl or Postman. All security-relevant validation must happen on the server. Client-side validation should be treated as a convenience feature, not a security control.
What is the difference between validation and sanitization?
Validation checks whether input meets expected criteria and rejects it if it does not (e.g., "this is not a valid email address"). Sanitization modifies input to make it safe (e.g., stripping HTML tags or escaping special characters). Both are important but serve different purposes. Validation is preferred when you can reject bad input. Sanitization is necessary when you must accept and process potentially dangerous input, such as rendering user-provided HTML.
Should I use allowlisting or denylisting?
Always prefer allowlisting. Define exactly what valid input looks like and reject everything else. Denylisting tries to enumerate all malicious patterns, which is impossible — attackers constantly find new bypass techniques. A denylist that blocks <script> can be bypassed with <SCRIPT>, <scr ipt>, or <img onerror=...>. An allowlist that only permits [a-z0-9] cannot be bypassed regardless of what the attacker tries.
How do I validate file uploads?
File upload validation should check multiple attributes: file extension (against an allowlist), MIME type (from the file header, not the Content-Type which the client controls), file size (enforce a maximum), and file content (scan for malicious payloads). Never trust the file extension alone — a file named image.png could contain executable code. Use a library that reads file magic bytes to determine the true file type. Store uploaded files outside the web root or in a dedicated storage service.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to input validation and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan