Quick questions on Input validation and sanitisation explained: HSC Software Engineering Module 1

Check that incoming data matches an expected format before processing it. Two approaches:

Transform input to make it safe for downstream use. Removes or escapes unwanted characters but does not reject the request.

Transform data at the boundary where it is written to a target context. The encoding depends on the context:

Submitting ' OR '1'='1 as the password turns the query into:

Real systems combine all three:

reject empty comments, comments over 5000 characters, comments containing null bytes. Allow normal Unicode text.

insert the comment with a parameterised query. No need to escape SQL metacharacters - the driver handles it.

HTML-encode the comment text when rendering. Convert less-than to ampersand-lt-semicolon, greater-than to ampersand-gt-semicolon, ampersand itself to ampersand-amp-semicolon, and the two quote characters to their numeric or named entities. Prevents stored XSS attacks where a malicious commenter injects script tags.

Browser validation is a UX feature, not a security control. An attacker hits the API directly.

Attackers find encodings you missed. Allow-list what you want; reject everything else.

You may need to render data in HTML, in a JSON API response, and in a CSV export. Encode at the output boundary, not at storage, so the same stored value can be rendered safely in multiple contexts.

Command injection, LDAP injection, NoSQL injection, and template injection all follow the same pattern. The defence is the same: parameterise or context-encode at the output boundary. :::