Input validation defines what data the system is prepared to handle. It rejects values that do not meet that contract before they reach storage, business logic, a command, or another service. The same contract must hold at every entry point, including entry points that do not have a visible form.
Input arrives from more than users
Browser controls improve usability, but they do not establish a trusted boundary. Requests can be sent directly to an API. Data can also arrive from imports, webhooks, scheduled jobs, message queues, and other services. Each source can be malformed, incomplete, stale, or valid in structure but invalid for the current business state.
An audit of vibe-coded software inventories these entry points. Generated features may define a schema for one route and repeat a looser version elsewhere. The code looks consistent at screen level while different paths accept different meanings for the same field.
| Input source | Structural check | Contextual check |
|---|---|---|
| Web form | Required fields and types | Allowed value for this user |
| API request | Schema and size limits | Valid operation in current state |
| File import | Format, columns, encoding | Records belong to the right account |
| Webhook | Payload shape and signature | Event is current and expected |
| Background job | Stored data still parses | Preconditions still hold |
Validation has layers
Structural validation asks whether the data can be interpreted safely. Business validation asks whether it makes sense for the requested operation. Authorization remains a separate decision: a correctly shaped account identifier does not prove that the caller may access that account.
A review distinguishes several checks:
- Type: Confirm that a value is a string, number, date, list, or expected object.
- Štruktúra: Require known fields and reject unexpected nesting where it changes behaviour.
- Bounds: Limit lengths, ranges, collection sizes, and file sizes.
- Format: Parse identifiers, dates, addresses, and structured content deliberately.
- Meaning: Verify that the value is allowed in the current workflow and relationship.
What weak validation looks like
Weak validation is often duplicated and optimistic. One route converts invalid data silently, another relies on a database error, and a third passes a value into a downstream service. Error handling then becomes part of the contract by accident. The audit checks whether rejected data fails before it changes state and whether the response exposes internal details.
Threat modeling directs attention to inputs that cross important trust boundaries. Free text that is displayed later, identifiers used in queries, file uploads, callback URLs, and values passed to external tools all deserve explicit handling. The audit does not assume that a framework default covers the complete path.
Evidence that validation holds
Tests should cover valid boundaries, invalid values, missing values, oversized payloads, and combinations that violate business rules. They should call the server entry point rather than only the interface component. The expected result includes the absence of side effects: no partial write, queued job, or external call after rejection.
This verification belongs to the production discipline described in vibe coding versus agentic engineering. A visible form can guide a normal user. Reliable input validation protects the system when data arrives through every other route the product exposes.
