SECURITY TESTING
Input Validation Testing.
Hands-on checks How QA engineers can test unsafe or malformed input safely — required fields, types, length, format, special characters, HTML-like input, and API payloads.
When to use this page: When testing any field, form, search box or API payload that accepts user input and you want to confirm it handles unexpected input safely.
Input validation checks whether the application handles unexpected, malformed or unsafe input without breaking or doing something dangerous. You can test this thoroughly with safe, ordinary inputs — no exploit payloads required. This page covers what to vary, where to test, and what evidence to collect.
// What input validation means
Good validation accepts the input the feature is designed for and safely rejects everything else — with a clear message, the right status code, and no broken pages or stored bad data. QA's job is to vary the input along predictable dimensions and confirm the behaviour is safe and consistent on both the UI and the API.
- Required fields are actually required (server-side, not only in the browser).
- Data types are enforced (a number field rejects letters).
- Length limits hold — minimum and maximum.
- Format rules hold (email, date, phone, URL).
- Allowed characters are handled; unexpected ones are rejected or safely escaped.
// Safe test inputs
Use ordinary, safe examples — you are checking handling, not attacking. Vary one dimension at a time so you know what triggered the behaviour.
| Input to try | What you're checking |
|---|---|
| Very long text (e.g. 5,000 chars) | Length limits and graceful rejection. |
| Unexpected symbols (' " < > & ;) | Special characters are escaped, not executed. |
| HTML-like text: <script>alert(1)</script> | Shows as literal text later, never runs. |
| Emoji and accented / Unicode characters | Stored and displayed correctly, no corruption. |
| Leading / trailing / only-whitespace | Trimmed or rejected, not saved as blank. |
| Invalid dates (31 Feb, 13th month) | Rejected with a clear message. |
| Negative or very large numbers | Boundary rules enforced where relevant. |
| Invalid email formats | Rejected consistently on UI and API. |
Why HTML-like input matters
Entering <script>alert(1)</script> is a safe way to confirm the app escapes input. If it shows as plain text wherever it is later displayed, escaping works. If a dialog pops up or the markup renders, stop and escalate — that is a cross-site scripting (XSS) risk.
// Where to test
- Forms and profile fields
- Search and filter boxes
- Comments and free-text fields
- Admin fields (often less hardened)
- API payloads — send the same bad input directly to the endpoint
- Import files and uploaded data
- URL query parameters
Always test the API, not just the UI
Browser-side validation is easily bypassed. Send the same malformed input straight to the API and confirm the server rejects it with a 400 and a field-specific error — the UI being tidy is not enough.
// Common risks when validation is weak
- Broken forms or error pages on unexpected input.
- Bad data saved that breaks later screens, search or exports.
- Stored unsafe content that renders for other users (XSS).
- API failures or stack traces that leak internal details.
- A finding that needs security escalation.
// Evidence to collect
- The exact input used and the field or API endpoint.
- The expected validation vs the actual behaviour.
- Response status and body (with sensitive values masked).
- A screenshot of the UI state.
- Whether the input was stored and later displayed somewhere else.
// When to escalate
- HTML or script input that renders or executes instead of showing as text.
- Error responses that expose stack traces, SQL errors or internal paths.
- Input that is saved and then shown to other users unsafely.
// Related resources