Cross-site scripting

The same value is safe in one position and dangerous in another: inside text, inside an attribute, inside a URL, inside a script block. One filter cannot be correct for all of them.

Input filtering also has to anticipate every encoding an attacker might use, which is a list nobody finishes.

Encoding on output knows the context, because it happens at the point the value is inserted.

Modern templating engines encode by default, which is why this class of problem is now concentrated in the places that opt out — a raw-HTML helper, a direct DOM assignment.

Which makes the practical advice narrow: find the places that bypass the default, and justify each one.

A content security policy restricting which scripts may run, which turns a successful injection into a blocked one.

HttpOnly on session cookies, which stops injected script from reading them — the most valuable thing it could take.

A type-enforcing API for DOM assignment, where the platform supports it, which makes the unsafe assignment a compile-time or runtime error rather than a silent success.

None of these replaces correct encoding. They limit the consequence of getting it wrong, which is a different and complementary job.

A policy permitting inline scripts permits exactly the thing an injection produces.

A policy permitting arbitrary evaluation does the same for a different shape of the same problem.

Both are common, because a strict policy requires either a nonce or a hash on every legitimate inline script — which is real work on an existing site.

So a policy that exists is not the same as a policy that helps, and reading its directives is what distinguishes them.

Whether a content security policy is present and what its directives permit, which is read from the response header.

Whether session-like cookies carry HttpOnly.

Whether inline event handlers appear in the markup, which is a signal that a strict policy is not in force.

Not whether any particular value is correctly encoded, which is a property of code rather than of a response — and nothing is injected or attempted to find out.

Stored: the value is saved and served to everyone who views the page afterwards, which makes it the most consequential shape.

Reflected: the value comes from the request and appears in the response, so it affects whoever follows a crafted link.

DOM-based: the value never reaches the server at all — client-side code reads it from the URL or storage and writes it into the page.

The third is invisible to anything inspecting server responses, which is why the mitigations that limit consequence matter as much as the ones that prevent injection.