Content-Security-Policy is a header that whitelists where scripts, styles, images and other resources may load from. A good CSP is one of the strongest defences against cross-site scripting (XSS), because injected scripts simply refuse to run.
CSP lets you declare trusted sources for each type of content. The browser blocks anything outside that policy, dramatically reducing the impact of XSS and data-injection attacks even when an application flaw exists.
Check your website
See how your site handles content security policy (csp): stop xss at the browser — free, no account needed.
For business owners
Cross-site scripting is one of the most common and damaging web vulnerabilities — it can steal sessions, deface pages or capture payment data. CSP is a powerful safety net: even if a bug lets an attacker inject a script, CSP can stop it executing. It takes real effort to configure correctly, but it meaningfully protects customers and demonstrates a serious security posture.
How it works (technical)
A policy is a list of directives, each naming allowed sources: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self'.
Best practice is a nonce- or hash-based policy that avoids 'unsafe-inline', so only scripts you explicitly mark can run. Deploy in Content-Security-Policy-Report-Only mode first to collect violation reports without breaking anything, then switch to enforcing mode.
Real-world example
A forum was hit by stored XSS in signatures. Because it enforced a nonce-based CSP with no unsafe-inline, the injected <script> never executed in visitors' browsers. The report-only endpoint had already shown the team exactly what a real attack would look like.
Why it matters
CSP is the browser-level control that contains XSS damage. It is complex, which is why many sites lack it — making it a strong differentiator on any security scan and a genuine protection for users.
How to fix it
Deploy
Content-Security-Policy-Report-Onlyfirst and collect violation reports.Start from
default-src 'self'and add only the sources you actually use.Prefer nonces or hashes over
'unsafe-inline'for scripts.Set
object-src 'none'andbase-uri 'self'as safe hardening defaults.When reports are clean, switch to the enforcing
Content-Security-Policyheader.
Best practices
Iterate with report-only mode before enforcing.
Avoid
unsafe-inlineandunsafe-evalwhere possible.Include
upgrade-insecure-requeststo eliminate mixed content.Keep the policy under version control and review it when adding third-party scripts.
Common mistakes
Enabling a strict CSP in enforcing mode without testing, breaking legitimate features.
Adding
'unsafe-inline'to "make it work", which defeats most of the protection.Forgetting to allow required third-party analytics or payment scripts.
Frequently asked questions
Will CSP break my site?
It can if enforced without testing. Always start in report-only mode so you see violations before they affect users.
Is CSP worth the effort for a small site?
A basic policy (default-src 'self', object-src 'none') is easy and helpful. A strict nonce-based policy is more work and best suited to sites handling logins or payments.
Put this into practice
See how your site scores with Plexa Trust — start with a free scan, then unlock the complete audit on Pro.
Scan your website free