Security

Content Security Policy rollout: build CSP from the resources a site really uses

A Content Security Policy rollout reduces where the browser may load or execute content, but a strong policy must still permit every legitimate application path. The safest sequence is inventory, Report-Only observation, nonce/hash design, browser interaction coverage, enforcement, and continued regression monitoring.

Inventory resource and action origins

List scripts, styles, fonts, images, connect/fetch endpoints, frames, workers, media, forms, and base/object behavior across representative routes. Include consent-dependent analytics and rare application flows, not only the homepage.

Remove unused third-party dependencies before adding them to a permanent allowlist.

Prefer nonces/hashes over broad unsafe-inline

For server-rendered dynamic scripts, per-response nonces can authorize intended code while blocking injected inline script. Hashes work for stable inline blocks. Keep script-src-attr restricted so event-handler attributes do not bypass the design.

Understand strict-dynamic browser behavior before relying on it.

Use Report-Only to discover breakage

Collect violation reports or browser-console evidence while exercising forms, checkout, menus, tools, downloads, authenticated flows, and analytics with consent denied/granted. Separate browser extensions/noise from genuine site resources.

Do not leave Report-Only forever after compatibility is proven.

Enforce and continuously test

Move the same tested policy to enforcing mode, verify critical flows again, and assert the header in production edge tests. Review new violations when dependencies change and add only the minimum policy change required.

  • Inventory all directive categories.
  • Use nonce/hash-based script policy.
  • Exercise real flows in Report-Only.
  • Enforce with ongoing browser regression.
Related DotMoose serviceSee the DotMoose security approach

Keep reading

Related guides.

More security →