flawopen.com/XSS/CSP vs. escaping

Do I need a Content-Security-Policy if I already escape output?

Reference page — draft, pending review
Short answer

Yes — they're complementary, not redundant. Output encoding is the primary fix; CSP is a second layer that limits the damage if encoding is ever missed somewhere.

What each one actually does

Output encoding prevents the injection in the first place

If every value is correctly encoded for its context, an attacker's script never becomes executable markup — this is the actual fix for the vulnerability.

CSP limits what a successful injection can do

A Content-Security-Policy header restricts which script sources the browser will execute at all. If one output point somewhere in a large codebase is missed, a strict CSP can prevent the injected script from running or from exfiltrating data to an attacker's server, even though the encoding gap still exists.

Why relying on CSP alone is risky

A permissive or misconfigured CSP (one that allows unsafe-inline scripts, for instance) provides no protection at all. CSP is defense-in-depth for when encoding fails somewhere — it was never designed to be the primary defense, and treating it as a substitute for encoding leaves real gaps.

FAQ

What's a reasonably strict CSP starting point?

A policy that disallows unsafe-inline and unsafe-eval, and restricts script-src to your own origin plus explicitly trusted third-party hosts, is a solid baseline — nonce- or hash-based script allowlisting is stronger still.

References