Content Security Policy for server-rendered pages

What it is

The Content-Security-Policy response header tells the browser which origins may supply scripts, styles, images, fonts, connections and frames. default-src 'none' denies everything not explicitly allowed; directives such as script-src 'self', style-src 'self', img-src 'self', frame-ancestors 'none', base-uri 'none' and form-action 'self' then open exactly what the page needs.

Why it matters

Output encoding should prevent cross-site scripting, but one missed context (an attribute, a JSON block, a URL) is enough. With a strict policy, an injected <script> or inline handler does not run, and an injected image cannot exfiltrate data to a foreign host.

How to apply

• Start with default-src 'none' and add sources per directive as the pages actually need them.
• Avoid inline scripts and styles; if unavoidable, use nonces or hashes rather than 'unsafe-inline'.
• Deploy with Content-Security-Policy-Report-Only first to find violations, then enforce.
• Combine with X-Content-Type-Options: nosniff, Referrer-Policy and frame-ancestors.

Pitfalls

'unsafe-inline' and 'unsafe-eval' neutralise most of the protection. JSON-LD data blocks are not executed and are not blocked by script-src, but their content must still be escaped. Third-party widgets often require loosening the policy; weigh their value against it.