Input Validation and Output Encoding (Secure Coding)

Prerequisites — complete before this lesson

This lesson is the remediation lens for injection and XSS findings. The exercises ask you to recall and fix a specific prior finding — arriving without that background makes them meaningless. Complete these lessons first:

- sql-injection-data-extraction

- dom-xss or reflected-and-persistent-xss

- intercepting-proxies

If you have not completed these, return to this lesson after you have — the recall exercise requires a real prior finding to work from and will be meaningless without it.

Every exploitation lesson so far showed you how an application breaks when it trusts untrusted data: a quote mark rewrites a SQL query, an angle bracket becomes executable script, a path fragment escapes its directory. This lesson turns those findings around and asks the defender's question - what should the code have done instead?

This is the remediation lens for those findings, not another exploitation walkthrough.

The answer is almost never one clever filter. It is two distinct controls that do two different jobs at two different moments:

Input validation - decide whether incoming data is acceptable (right type, length, format, range) as early as possible, on the trusted side.
Output encoding - decide how data is rendered safely into a specific destination (an HTML page, a SQL query, a URL) at the moment it leaves the application for that destination.

Confusing the two is the root of most "I tried to fix it but it still broke" stories:

Validation alone cannot make a dangerous character safe in every context - a legitimate name like O'Brien contains a quote.
Encoding alone cannot reject business-nonsense input - a quantity of -9999 is harmless to render but wrong to accept.

You need both, each in its proper place.

In this lesson you will:

See why allowlist validation beats blocklist filtering, and why you must canonicalize before you validate.
Identify parameterized queries as the durable, structural fix for SQL injection, and contextual output encoding as the durable fix for XSS.
Confirm the cardinal rule: security validation must run server-side, because the client is attacker-controlled.

Estimated time: ten minutes. No exploitation is performed here - this is a secure-coding and synthesis lesson.

When you are ready, send the Continue signal.

Prerequisites — complete before this lesson

This lesson is the remediation lens for injection and XSS findings. The exercises ask you to recall and fix a specific prior finding — arriving without that background makes them meaningless. Complete these lessons first:

- sql-injection-data-extraction

- dom-xss or reflected-and-persistent-xss

- intercepting-proxies

If you have not completed these, return to this lesson after you have — the recall exercise requires a real prior finding to work from and will be meaningless without it.

This is the remediation lens for those findings, not another exploitation walkthrough.

The answer is almost never one clever filter. It is two distinct controls that do two different jobs at two different moments:

Input validation - decide whether incoming data is acceptable (right type, length, format, range) as early as possible, on the trusted side.
Output encoding - decide how data is rendered safely into a specific destination (an HTML page, a SQL query, a URL) at the moment it leaves the application for that destination.

Confusing the two is the root of most "I tried to fix it but it still broke" stories:

Validation alone cannot make a dangerous character safe in every context - a legitimate name like O'Brien contains a quote.
Encoding alone cannot reject business-nonsense input - a quantity of -9999 is harmless to render but wrong to accept.

You need both, each in its proper place.

In this lesson you will:

See why allowlist validation beats blocklist filtering, and why you must canonicalize before you validate.
Identify parameterized queries as the durable, structural fix for SQL injection, and contextual output encoding as the durable fix for XSS.
Confirm the cardinal rule: security validation must run server-side, because the client is attacker-controlled.

Estimated time: ten minutes. No exploitation is performed here - this is a secure-coding and synthesis lesson.

When you are ready, send the Continue signal.