Content Security Policy, grounded in your site

See what scripts and assets are loading from 3rd parties and implement a policy with security in mind.

CSP Report crawls your URLs, summarizes origins by directive, and helps you draft policies you can validate in Report-Only before you enforce.

What implementing a Content Security Policy delivers

  • Constrains scripts, styles, and other subresources to approved origins, reducing exposure to cross-site scripting and related attacks.
  • Surfaces unexpected third parties and regressions through violations and reports prior to enforcement.
  • Supports compliance and assurance with a clear, browser-enforced declaration of what your application is permitted to load.

Reporting vs enforcing (which header?)

CSP may be implemented as a report-only header or as an enforced policy. The same directives apply; the difference is whether the browser blocks incompatible loads.

Content-Security-Policy-Report-Only

The browser evaluates the policy and issues violation reports without blocking resource loads. Use this mode to assess impact and refine directives before enforcement.

Content-Security-Policy

The browser applies the policy and blocks disallowed loads. Violations may still be reported when report-to or report-uri is configured. Adopt this header once Report-Only results are stable.

Content Security Policy Level 3 — W3C specification

Understand your site's Content Security Policy

Practical tooling for teams that want stronger defaults without freezing the whole release train.

  • Crawl real pages

    Walk your site with browser rendering so script, style, image, font, and frame sources reflect what visitors actually load—not guesswork from static files.

  • Draft policy headers

    Turn discovered origins into a structured starting policy you can paste into Report-Only, tune, and iterate before you enforce.

  • Share when you want

    Keep reports private to your workspace, or generate a public link so security and engineering can review the same findings.

  • Built for iteration

    Re-run crawls as your stack changes. Compare guidance as third parties and inline usage evolve.

Why Content Security Policy matters

Content Security Policy is more than a single HTTP header. It is how you tell the browser which sources are allowed for scripts, styles, frames, and more—so exploits and unexpected third parties surface as violations instead of silent compromises. The formal rules live in the W3C Content Security Policy Level 3 specification.

  • Shrink cross-site risk

    A tight Content Security Policy limits where scripts, styles, and other subresources may load from—your first line of defense when XSS or supply-chain abuse appears.

  • Catch breakage before enforcement

    Report-Only mode and browser reports show what would have been blocked. You fix allowlists deliberately instead of learning in production.

  • Compliance and trust

    Many security programs and audits expect explicit control over executable content. A clear policy documents that posture in the browser itself.