Inline Form Validation

Some form entry errors are due to human mistakes; these may be made worse or more likely by poor design. Can HTML 5 and CSS 3 help? A fairly recent article Forward Thinking Form Validation on A List Apart discusses how the new input types and attributes in HTML 5 combined with CSS 3's basic UI module can be used to guide users on how to complete form fields in real-time, making it less likely for them to make mistakes.

The explanation and demonstration are quite compelling, but do read the associated comments. Client-side validation can reduce human error (e.g. typos), and the number of requests submitted to the server with invalid data (see Input Masking at the Web Browser, Don't Stop the Attack (Too Soon), Let Down By Customer Surveys, Email Address Formats, and Input Validation and Output Encoding). See also these recent blog posts elsewhere:

• Working With Forms in HTML5
• HTML5 Forms Validation in Firefox 4

But do not expose all your business logic in client-side validation. For example, checking the general format of the account number would be reasonable, but the detailed validation (including authorisation) checks should only be undertaken server-side. This is because if the session or authorisation checks fail, it is difficult to handle this well dynamically on the form page—do we suddenly display an authentication form? Additional business logic on the client can also introduce new vulnerabilities.

The validation constraints also need to be flexible enough to cater for "valid", "reasonable" and "invalid" values. For example, you may want to store a telephone number without space characters (the valid format), but it is probably unreasonable to impose this on users who may well find it easier to type the spaces (or hyphens and parentheses) as they go. That would be a reasonable value, which client-side validation could allow, but is then accepted and sanitised before storage. When the telephone number is re-displayed it must be encoded appropriately, but it can also be formatted in the most legible way. Space characters apply in a similar way for credit card numbers.

And, always, undertake the same validation checks on the server too.

In my talk at AppSec Washington DC earlier this month (slides and workbook), I used the form validation as an example of how knowledge of any client-side validation may affect the response to data verification failures. In a form without client-side validation, a wide range of user input is not necessarily malicious.

However, if there is fully enforced client-side format validation, the receipt of invalid data could be more suspicious. This is because a user would have to use special tools to achieve this effect.

The siutuation is different if the data being validation came from another computer system, rather than direct human entry.

All human users will react in different ways to forms, and depending on circumstances, there will be a variety of human errors submitted. Client side validation can help with the user experience but is not a replacement for server-side validation. Knowledge of the validation mechanisms can help make better decisions on the server about the type of response to make. But remember that each browser version may react in different ways, and as before, if you are using any JavaScript for validation, this may be turned off by some users. Humans make programming errors too!