Glossary
CSP (Content Security Policy)
An HTTP security header that defines allowed sources for loading scripts, styles, images, and other resources in a web page. CSP is the primary defense against XSS attacks by preventing execution of unapproved scripts. A poorly configured CSP (unsafe-inline, wildcards) provides little real protection.
What a CSP actually protects
Content Security Policy is an HTTP header that tells the browser which content sources are allowed: scripts, styles, images, iframes, outbound connections. Its main role is limiting XSS impact: even if an attacker manages to inject HTML, a strict CSP prevents unauthorized script execution and exfiltration to third-party domains. It is defense in depth — it doesn't replace fixing XSS, it reduces the consequences.
Common mistakes
In our SaaS audits, genuinely protective CSPs are rare. Recurring patterns: no header at all, policies with 'unsafe-inline' and 'unsafe-eval' that void most of the protection, overly broad wildcards (https: or *.cloudfront.net), and Report-Only policies never switched to enforcing mode. A modern strict CSP relies on nonces or hashes ('strict-dynamic'), which requires framework integration — Next.js supports it through its middleware, for example.
Our audit approach
We evaluate the CSP in real conditions: the policy actually served on each page, the directives actually enforced, bypass possibilities (JSONP, abusable whitelisted libraries, DOM injections). The report states whether your CSP would block a real XSS and proposes a target policy suited to your stack, deployable progressively via Report-Only.
Frequently asked questions
Does a CSP stop all XSS?
No. A strict CSP blocks injected script execution and limits exfiltration, but bypasses exist (gadgets in allowed libraries, injections in uncovered contexts). It sharply reduces XSS impact but never removes the need to fix the injection flaw itself.
Why is 'unsafe-inline' a problem?
Because most XSS attacks inject inline script precisely. Allowing 'unsafe-inline' effectively disables CSP's main protection. The modern approach: per-request nonces or script hashes, with 'strict-dynamic' for loading chains.
How do you deploy a CSP without breaking the app?
Start in Content-Security-Policy-Report-Only mode with a violation collection endpoint. Analyze reports, adjust the policy until there are zero false positives, then switch to enforcing. On a production SaaS this cycle typically takes a few weeks and avoids any breakage.