Input Validation and Output Encoding

Why it matters

Injection and cross-site scripting (XSS), which the next two lessons test in detail, share one root cause: a value from outside reaches an interpreter such as a database, a shell or a browser and runs as code. Injection is one of the OWASP Top 10:2025 categories and includes XSS, and the two controls that prevent it are exactly these: validate what comes in, encode what goes out. One unchecked entry point or one unencoded output is enough.

For a tester this is productive ground, because the defects hide in the gaps between layers: a form that validates while the API does not, a list page that encodes while the export does not. Functional tests with tidy values never reach those gaps. A few harmless marker values, carried from every entry point to every place the value appears, find them in minutes, without attack tools, on systems you are authorised to test.

Input validation: allow-list rules, enforced on the server

The OWASP Input Validation Cheat Sheet asks for two checks on every value: its syntax, the expected type and format (type, length, range, format, membership of a fixed set), and its semantics, whether the value makes sense for the operation: the visit date is not in the past, the quantity does not exceed the stock. Testers usually call them syntactic and semantic validation. Rules are written as allow-lists: define what is accepted and reject everything else. A block-list (deny-list) of forbidden strings is always incomplete, because a dangerous value can be spelled in more ways than any list holds, and it rejects honest data: blocking the apostrophe rejects O'Brien without making any query safe. The cheat sheet lists deny-listing and "cleaning" input among its common pitfalls. Free text has an allow-list too, only a wider one: one character encoding agreed across components, malformed input rejected, legitimate punctuation and scripts kept, a length limit, and, where values are compared, one Unicode normalisation applied before validation and storage (so that é typed as one character or as e plus an accent mark is the same value).

Browser checks such as required, maxlength and a pattern are feedback, not a control: as in the lesson on testing web forms, anyone can edit the page or send the request without it. The cheat sheet is explicit: validate on the server even when the browser checks the same fields, and validate data from internal APIs, partner feeds and queues too. The form is only one entry point: the JSON API the mobile app calls, a bulk import, a query string, a header such as Accept-Language, a cookie and a webhook all bring values from outside. The tester proves that every path enforces every rule.

• Write each rule so that it can be tested: ^ORD-[0-9]{5}$ for an order number, ORD- and exactly five digits (the anchors ^ and $ make the whole value match, as the cheat sheet asks; without them the pattern also accepts xx ORD-12345 <b>); an integer from 1 to 20 for a quantity; one value from the stored list for a country; for a company name 2 to 80 characters of Unicode letters, digits, spaces and ' - & ., so the apostrophe and the ampersand stay legal.
• Copy the form's request from the Network panel as cURL, change one field to a value the page refuses, send it with a test account and expect a 4xx that names the field and the rule, nothing stored, and no stack trace or SQL in the message.
• Send the same set through the API and the import: 81 characters, a quantity of 0 and of 21, country ZZ, and the request below, in which company and notes pass their rules while quantity and country fail. Any path that accepts what the form refuses is a finding.
• Watch for silent repair: a server that cuts 81 characters to 80 or strips < without a message changes the user's data. Unless the requirement allows it, report it.

POST /api/customers HTTP/1.1
Host: crm.test.example
Content-Type: application/json

{"company": "O'Brien & Sons", "quantity": 21, "country": "ZZ",
 "notes": "Discount < 10% until <b>Ramadan</b>"}

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"errors": [{"field": "quantity", "rule": "integer 1-20"},
            {"field": "country", "rule": "not a known country code"}]}

Try it: Regex Tester Try it: Negative Test Generator Try it: Special Character Dataset Generator

Output encoding: one value, one encoding per context

Encoding happens at the moment of output, in the code that writes the value into a page, a link, a script or a query, and it depends on where the value lands. The OWASP Cross Site Scripting Prevention Cheat Sheet gives each HTML context its own rules: element content, attribute values, JavaScript, CSS and URLs. The database has its equivalent: a parameterised query sends the value separately from the SQL statement, so the database never parses it as SQL; the Injection Prevention Cheat Sheet treats escaping the input as a last resort. The stored value never changes, and a value encoded for the wrong context stays unsafe, because HTML entities inside a URL or a script string mean nothing there.

• HTML element content: & becomes &, < becomes <, > becomes >, " becomes " and ' becomes ' (' and ' are the same character), so the page shows the characters as typed.
• HTML attribute: the same entities, inside a quoted attribute such as title or value; an unquoted attribute can be broken out of with a space and many other characters. An event attribute such as onclick is a script context: the browser decodes the entities before the script runs, so they protect nothing there.
• URL parameter: percent-encoding, so a space becomes %20, & becomes %26 and, in strict RFC 3986 encoding, ' becomes %27 (many encoders leave the apostrophe as it is); unencoded, the & in the name starts a second parameter. A URL written into href is then attribute-encoded as well.
• JavaScript and JSON: string escaping by a maintained encoder, not quotes escaped by hand: " as \", \ as \\, plus < as \u003c when the data sits inside an HTML page, so a value cannot close the script. Safer still: keep the value out of the script, for example in a data- attribute read with dataset, and write it into the page with textContent, never innerHTML.
• SQL: a parameterised query or prepared statement keeps O'Brien as data without touching the text.

Stored value        O'Brien & Sons

HTML content        O'Brien & Sons
HTML attribute      title="O'Brien & Sons"
URL parameter       ?q=O%27Brien%20%26%20Sons
JSON / JavaScript   {"company": "O'Brien & Sons"}      (nothing to escape here)
SQL                 WHERE company = ?                  (value bound as a parameter)

One character, three contexts:   <   ->   &lt; (HTML)   %3C (URL)   \u003c (script)

Try it: HTML Entity Encoder Try it: URL Encoder Try it: JSON Escape / Unescape

Why both: validation at the door, encoding at every exit

Neither control replaces the other. Validation cannot reject O'Brien, Al-Harbi & Sons or a note saying price < 50, because they are correct data; only encoding keeps them harmless on the way out. Encoding cannot reject a quantity of -1, a ten-megabyte note or a country that does not exist, because they display perfectly well; only validation keeps bad data out. The Input Validation Cheat Sheet says the same: validation does not replace parameterised queries for SQL or context-aware output encoding against XSS.

The order is fixed: input, validate (accept or reject, never repair silently), store the accepted value unchanged, encode for the context at every output. Storing an already encoded value breaks the chain, because every other output then receives wrong data: the e-mail shows & as text, the CSV export carries entities, and a page that encodes correctly shows & on screen because its source now holds &, the double-encoding defect. Sanitisation is a third, separate operation for the few fields that must accept markup, such as a rich-text editor: a sanitiser library keeps only an allow-list of tags and attributes, and the result is still encoded wherever it leaves as plain text.

Worked example: one customer through its outputs

A CRM in your test environment, with written permission to test it, has the customer form from above. The tester saves a customer with the company O'Brien & Sons and the note Discount < 10% until <b>Ramadan</b>, once through the form and once through the API with a valid quantity and country, then visits every place the values appear: the customer list, the tooltip on the name (a title attribute), the "find similar" link, the CSV export and the welcome e-mail.

• Customer list: both values shown as typed; the source has ', & and <. Pass.
• Tooltip: shows only O. The source reads title='O'Brien & Sons': the apostrophe ended the single-quoted attribute and the rest landed outside it. Finding: no attribute encoding. Stop and report; the XSS lesson continues from here.
• Find-similar link: /customers?q=O'Brien & Sons without percent-encoding; the search runs for O'Brien and the server receives a second parameter named Sons. Finding: no URL encoding, and a functional defect for every name with an ampersand.
• CSV export: the note arrives as Discount < 10% until <b>Ramadan</b>. Finding: the export reused HTML-encoded text, so whoever downloads it gets wrong data; encoding for the wrong context.
• Welcome e-mail: Ramadan in bold. Finding: the template inserts the note as markup, so text written by one user is rendered in another's mailbox; report it as HTML injection with restricted visibility and let the security lead judge severity.
• Entry points: through the API, quantity: 21 and country: ZZ return 422 naming both fields, nothing stored. Pass. Through the import, an 81-character company name is accepted and cut to 80 without a message. Finding: the import validates less than the form.

Frequently asked questions

References

• OWASP Cheat Sheet Series: Input ValidationOWASP FoundationAllow-list validation, syntactic vs. semantic checks, and why client-side validation is never a security control.
• OWASP Cheat Sheet Series: Cross Site Scripting PreventionOWASP FoundationPreventing XSS: output encoding for each context, sanitizing user-authored HTML, safe DOM sinks and framework protections, with CSP only as defence in depth.
• OWASP Cheat Sheet Series: Injection PreventionOWASP FoundationPreventing SQL, OS-command and other injection through parameterisation, validation and escaping.
• OWASP Top 10:2025OWASP Foundation · 2025The ten most critical web application security risks, with how to test for and prevent each.