After an update or major change, verify a contact form from the visitor's browser through the server and final destination. Test valid and invalid entries, server-side validation, abuse controls, confirmation messages, storage or email delivery, reply routing, accessibility, privacy, and monitoring. A successful button animation is not proof that a message reached the intended owner.
Record the intended behavior
List every field, required state, accepted format, length limit, consent control, attachment rule, destination, recipient, auto-response, retention rule, and expected success or error message. Record the active form version and deployment time. Use test addresses and clearly labeled messages so they cannot be confused with genuine customer requests.
Test the form in representative browsers, mobile and desktop layouts, keyboard-only navigation, and any supported assistive-technology path. Check labels, focus order, readable error text, and that errors identify the field without erasing valid entries. Client-side validation improves immediate feedback, but MDN warns that it can be bypassed and must not replace server-side validation (MDN form-validation guidance).
Test accepted and rejected input
Submit an ordinary valid message and confirm every expected stage: browser response, server acceptance, database or queue record where applicable, email or help-desk delivery, sender address, reply-to behavior, timestamp, and notification. Then test missing required fields, malformed addresses, excessive length, unexpected fields, duplicate submissions, and special characters that legitimate names or messages may contain.
OWASP recommends defining validation rules for each field, enforcing them on the server, and favoring an allowlist of accepted structure rather than trying to recognize every malicious string (OWASP Input Validation Cheat Sheet). For a free-form message, that can mean broad text support with a reasonable length limit, safe storage, and context-appropriate output handling rather than rejecting normal punctuation.
Verify abuse controls on the server
Check rate limits, honeypots, CAPTCHA or challenge systems, duplicate suppression, attachment scanning, and alerting without weakening access for legitimate users. If Cloudflare Turnstile is used, the server must validate the token with Siteverify; Cloudflare states that the client widget alone is insufficient, tokens expire after five minutes, and each token is single-use (Turnstile server-validation documentation). Test success, an expired token, a reused token, and the user-facing recovery path.
Confirm delivery and operational ownership
Verify the final destination with a direct record: inbox receipt, ticket identifier, database row, or queue event. Check spam placement, forwarding rules, distribution-list membership, and whether replies go to the submitter rather than an unmonitored address. Confirm that sensitive form contents are not exposed in URLs, analytics, logs, or broad notifications.
Assign an owner for failures and send a controlled test from outside the organization when practical. Confirm that monitoring detects a broken destination as well as a server error. Keep a timestamped result with the form version, test cases, delivery evidence, and any known limitations.
Repeat the core valid, invalid, abuse-control, and delivery tests after changes to DNS, email providers, form plugins, authentication, hosting, queues, or recipient lists. The form is verified only when both the visitor experience and the downstream record behave as intended.
Sources
- Client-side form validation — MDN Web Docs
- Input Validation Cheat Sheet — OWASP Foundation
- Validate the token — Cloudflare Developers, Sept. 16, 2026