Frontend Index Return to the interactive index →
Production Engineering

Content Security Policy

How CSP reduces content-injection risk, how to deploy it safely, and why it complements rather than replaces output encoding.

Last reviewed: September 2026

What it is

Content Security Policy is an HTTP response policy that limits which resources a document may load or execute. A well-designed policy can reduce the impact of some injection vulnerabilities.

Mental model

CSP is a browser-enforced allowlist and set of execution constraints. It is a defense layer around the document, not a sanitizer for unsafe data.

Why it exists

Web applications routinely combine first-party code, user-controlled data, and third-party resources. CSP gives the browser explicit boundaries for permitted content.

When to use it

  • Protecting production documents against content injection
  • Reducing reliance on unrestricted inline script
  • Auditing third-party resource dependencies

When not to use it

  • Do not use CSP as a substitute for contextual output encoding
  • Do not copy a strict policy without mapping required application resources

Production considerations

  • Start with Content-Security-Policy-Report-Only
  • Prefer nonces or hashes over unsafe-inline
  • Collect reports with privacy and abuse controls
  • Test authentication, payments, embeds, and error flows

Accessibility implications

A policy must allow required accessibility assets and behavior. Test assistive flows and avoid failures that silently remove essential controls or content.

Performance implications

Reducing unnecessary third-party origins can improve both policy clarity and performance. Reporting and policy complexity still require operational care.

Primary documentation

Related Frontend Index entries