15 Data Validation Rules for Reliable Business Applications

A reliable business application checks that data is the right type and format, present when required, within sensible ranges, consistent across related fields, unique where it must be, linked to records that exist, allowed in its current state and allowed for this user, and it applies the same checks to imports, APIs and integrations as to forms. Validate in layers: in the interface for helpful feedback, on the server for every entry point, and in the database as the final guard.

This list is for product owners writing requirements and developers designing forms, APIs and imports. OWASP's input validation guidance distinguishes syntactic validation (is it the right type and format?) from semantic validation (does the value make sense here, such as an end date after a start date). Both matter. For the database layer, see database design mistakes.

1. Type. A quantity is a whole number, a price is a decimal, a date is a real date. Convert input to the expected type on the server and reject what does not convert.

2. Required fields. Decide which fields are truly required for the record to be useful, and enforce them on the server and in the database. Every unnecessary required field is friction for users.

3. Format. Postcodes, tax numbers, phone numbers and SKUs follow patterns. Prefer allowlists (what is accepted) over trying to block bad characters; OWASP warns against trying to recognise every malicious string.

4. Length. Set maximum lengths that match how the data is used and stored, and minimums where meaningful. Very long input is a common cause of broken layouts and storage errors.

5. Normalisation. Trim spaces, standardise case where appropriate (email domains), and store phone numbers in a consistent international format so duplicates can be detected.

6. Range. Quantities above zero, discounts between 0 and 100%, dates of birth in the past. Ranges catch typing mistakes as well as abuse.

7. Cross-field rules. An end date after the start date, a delivery date after the order date, a shipping address required when delivery is chosen. These semantic checks are where many real-world errors hide.

8. Uniqueness. Invoice numbers, SKUs and account emails must be unique. Enforce it in the database with a unique constraint, not only by checking first in code, which fails under simultaneous requests.

9. References exist. An order must point to a customer that exists and is active; a product to a category that exists. Foreign keys enforce this in the database; the application should give a clear message first.

10. Money and units. Amounts have the right number of decimal places for their currency, the currency is stated, and units (kg or g, cm or inches) are explicit. Rounding rules should be defined, not left to defaults.

11. Dates and time zones. Store moments in time unambiguously and validate that times make sense in the user's zone, especially for bookings around daylight saving changes.

12. Allowed state transitions. An order can go from paid to shipped, but not from cancelled to shipped; an invoice cannot be edited after it is issued. Define the allowed transitions and reject the rest.

13. Permission-aware validation. Whether a value is valid can depend on who is submitting it: a sales rep may give up to 10% discount, a manager more. Check authorisation on the server for every change, not only by hiding buttons.

14. Import and API validation. CSV imports, API calls and integration syncs must pass the same rules as forms. Validate every row, report errors by row and field, and decide whether a file with some bad rows is rejected entirely or partly accepted.

15. Duplicates and replays. Retried requests, double clicks and re-sent webhooks can create duplicate records. Use idempotency keys or event IDs and unique constraints so the same request processed twice has the same effect as once. See webhook use cases.

A rule is only half the job; people need to know how to fix the problem. Say what is wrong and what is accepted, next to the field, and keep what the user entered. For forms with many fields, see multi-step form design and, for checkout examples, checkout error messages.

Reliable data comes from rules applied consistently at every entry point: forms, apps, APIs, imports and integrations. Write the rules down with the business, enforce them on the server, back them with database constraints, and test them with the messy data real users and systems send. Validation also supports security, but it does not replace parameterised queries, output encoding and the other controls in our website security checklist.

OWASP Cheat Sheet Series, Input Validation Cheat Sheet. Accessed 28 October 2026.