Testing Web Forms

Why it matters

Forms are where users hand over data and money. A form that refuses a valid name with an apostrophe loses a customer; one that books twice on a double click uses up seats or charges twice. Such defects slip through when only a few tidy values are ever tried.

Client-side checks are also easy to bypass. The OWASP Input Validation Cheat Sheet requires validation on the server, because anything done in the browser can be circumvented. A form that looks strict may sit on a server that accepts anything, and only a tester who goes around the browser finds out.

Client-side and server-side validation

Client-side validation uses the HTML constraints from the lesson on HTML for testers, such as required, type="email" and maxlength, plus page scripts that check a field as you type or when you leave it. It gives fast feedback but no protection: anyone can remove an attribute, turn off JavaScript or send the request without the page.

Server-side validation is the enforcement. It must repeat every client rule, and only it can check rules that need stored data, such as a unique email or the seats left. Test each rule through the form, for the user experience, and around it, for enforcement, on a system you are allowed to test:

• In DevTools, delete required or maxlength, or add novalidate to the <form> to switch off the browser's built-in checks, then submit. The edit lives only in your tab; the request is real.
• Or copy the request from the Network panel as cURL, change one value and send it again with a test account, from a terminal or the API Request Builder; the cURL Parser splits the command into method, URL, headers and body. Expected: a 4xx response such as 422, the field named, nothing saved.
• Compare the two rule sets. A server stricter than the page (the page allows 100 characters, the database column holds 50) shows up as a 500 or silently cut text; a page stricter than the server (an email pattern that refuses +) blocks real users.

Try it: cURL Parser Try it: API Request Builder

Required fields and positive and negative inputs

Check that every required field is marked on screen and in the markup, and that every missing field gets reported. Browsers' built-in messages usually show only the first invalid field at a time; if the requirement asks for all errors at once, the page needs its own script that lists them. A text field containing only spaces satisfies the browser's required check, so the server must trim and refuse it. Optional fields left empty must be stored as empty, not as the text null; conditionally required fields, such as a VAT number for business accounts only, need both states tested.

Then apply positive and negative testing field by field. Real valid data is more varied than developers expect:

• Positive: O'Brien, Al-Harbi, names in Arabic and Devanagari, sara+events@example.com, a phone number pasted with spaces such as +966 50 123 4567.
• Negative: empty, only spaces, one character over the maximum, sara@, letters in a number field, 0 where the minimum is 1.
• Text that looks like markup, such as <b>Sara</b>, must be stored and shown as typed, never rendered in bold; the lesson on web security basics goes further.
• Arabic-Indic digits such as ٠٥٠١٢٣٤٥٦٧ in a phone field: converted or refused with a clear message, as the requirement says. If it says nothing, ask.

Try it: Validation Test Generator Try it: Negative Test Generator Try it: Unicode Dataset Generator

Error messages, submission and double submit

An error message is part of the expected result: it sits next to its field, says what to do ("Enter an email such as name@example.com", not "Invalid input"), keeps what the user typed and disappears once the field is fixed. Server errors must look like client errors and use the page's language; the browser's built-in messages follow the browser's language instead. The guide on accessible forms covers how errors are announced.

Submitting should do one thing once: progress is shown, success shows a confirmation and stores exactly one record, and a failure, including a lost connection, keeps the input. Pressing Enter in a single-line field usually submits too. RFC 9110 does not define POST as idempotent: two identical POST requests can have more effect than one, so the same form sent twice can create two records. With the network throttled in DevTools, try:

• Double-click Submit, or press Enter twice.
• Reload the confirmation page: the browser offers to send the data again. Many sites prevent this by redirecting after the POST to a page loaded with GET.
• Go Back and submit again, or submit the same form in two tabs.
• Expected: one record, one email. A disabled button stops most double clicks but not a reload, a second tab or a replayed request, so the server needs its own duplicate check.

Try it: Mock Error Payload Generator

Autofill and password managers

Many users never type: the browser or a password manager fills the form from saved data. The autocomplete attribute tells it what each field is, with tokens from the HTML standard such as name, email, tel and new-password; WCAG 2.2 success criterion 1.3.5 Identify Input Purpose expects them on fields that collect information about the user. Save test data in a separate browser profile, then check that:

• Each value lands in the right field, not the full name in "First name".
• Validation and the Submit button react to filled values: as in the lesson on JavaScript for testers, a check that listens only for key presses never runs after autofill.
• Sign-in fields accept paste and password managers. Blocking them forces people to retype passwords from memory, which WCAG 2.2 success criterion 3.3.8 Accessible Authentication (Minimum) is meant to prevent.

Try it: Fake User Generator Try it: Fake Phone Number Generator

Worked example: an event registration form

Requirement: "To register for a free event, enter Full name (required, 2 to 60 characters), Email (required, one registration per email), Mobile (required, 05 and 8 digits), Company (optional) and Tickets (1 to 4, within the seats left). Register shows a reference number and sends an email." The browser can check presence, length, format and range; only the server knows which emails are registered and how many seats are left.

• RF-01, positive: valid data → a reference number, one record, one email.
• RF-02, positive: نورة القحطاني, nora+expo@example.com, no company → accepted and shown as entered.
• RF-03, negative, browser: Register with every field empty → each required field reported, and the Network panel shows no request.
• RF-04, negative, server: the request replayed with "name": " " and "tickets": 5 → 422, both fields named, nothing saved.
• RF-05, negative, server only: an email that is already registered → a message under Email, the other input kept.
• RF-06, double submit: double-click Register on a throttled connection → one record, one email.
• RF-07, autofill: a saved phone +966501234567 → stored as 0501234567, or refused with a format message; the requirement must say which.

Frequently asked questions

References

• HTML Living StandardWHATWGThe HTML language, including named character references (entities) and the parsing rules browsers follow.
• OWASP Cheat Sheet Series: Input ValidationOWASP FoundationAllow-list validation, syntactic vs. semantic checks, and why client-side validation is never a security control.
• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• Client-side form validation — MDNMDN Web Docs (Mozilla)Built-in and scripted form validation in the browser, and why it helps users but never replaces validation on the server.