Content Security Policy
A response header declaring which sources of script, style and other resources the browser may load, which turns a script injection from a compromise into a blocked request.
Cross-site scripting persists because output encoding has to be correct in every location, and a single omission is sufficient. A content security policy is defence in depth for exactly that: even if an attacker injects a script tag, the browser refuses to execute it unless its source is permitted.
The strength of a policy is decided by two things. What sources are allowed —
unsafe-inline permits injected inline script and removes most of the protection,
which is why nonce or hash-based allowances for legitimate inline scripts are the
arrangement worth the effort. And whether it is enforced or merely reported, as
a report-only policy is a monitoring tool rather than a control.
The other headers that matter are fewer than the available list suggests:
Strict-Transport-Security to prevent downgrade, X-Content-Type-Options to stop
MIME sniffing, and a frame-ancestors directive to prevent clickjacking.
The related decision, and the one with the most impact, is where authentication
tokens live. A token in localStorage is readable by any executing script; a token
in an HttpOnly cookie is not, which is why holding tokens server-side and issuing
the browser a session cookie removes the entire theft-by-script class rather than
mitigating it.