Content Security Policy: A Practical Guide for Safer Websites
Learn Content Security Policy basics including script rules, nonces, hashes, reporting, inline scripts, third-party risk, and rollout strategy.
CSP reduces the damage of injection bugs
Content Security Policy, or CSP, is a browser security feature that restricts which scripts, styles, images, frames, connections, and other resources a page can load. It is best known for reducing cross-site scripting risk. If an attacker injects script into a page, a strong CSP can make that script fail to execute.
CSP is not a replacement for escaping, sanitization, framework security, or careful review. It is an additional defensive layer. The policy is most useful when it is specific, monitored, and maintained as the application changes.
Start with visibility before enforcement
Many teams begin with a report-only policy. This lets the browser send violation reports without blocking resources. Report-only mode helps reveal inline scripts, third-party dependencies, browser extensions, and unexpected asset sources. Jumping straight to enforcement can break production pages if the policy is incomplete.
Reports need filtering because browser extensions and unusual clients can create noise. Focus on violations from real application behavior and important pages. Use the findings to tighten the policy gradually.
- Avoid broad allowlists such as
*where possible. - Use nonces or hashes for approved inline scripts.
- Keep third-party script sources limited and reviewed.
- Roll out enforcement in stages and monitor violations.
Script policy is the heart of CSP
script-src controls where scripts can come from and whether inline scripts may run. A strong policy usually avoids unsafe inline script and uses nonces or hashes for scripts the server intentionally allows. This requires coordination with templates, frameworks, tag managers, and build tools.
Third-party scripts complicate CSP because they may load additional scripts or require broad permissions. Analytics, ads, chat widgets, A/B testing, and tag managers should be reviewed with security and privacy in mind. A CSP can expose how much external code runs on critical pages.
Policies should match the app's architecture
A static documentation site, ecommerce checkout, SaaS dashboard, and embedded widget may need different policies. APIs, image CDNs, font providers, payment frames, and reporting endpoints should be listed intentionally. Separate policies by route if risk differs significantly.
Modern frameworks can make CSP easier or harder depending on how they handle inline scripts and hydration. Test production builds, not only development mode. Development tooling often uses scripts that should not appear in production policy.
Maintain CSP as dependencies change
A good policy can drift when teams add scripts, new CDNs, embedded tools, or payment providers. Make CSP changes reviewable, document why each source is allowed, and remove old sources when vendors are removed. CSP works best as a living security control rather than a header copied once from a checklist.
Connect CSP to incident response
CSP reports can reveal attempted injection, unexpected third-party behavior, or pages loading resources from places the team did not approve. Route important reports into security monitoring with enough context to investigate. A policy that only blocks quietly is useful, but a policy that also teaches the team what is happening is stronger.