Section 32 · API & Security
Content Security Policy
Audit guide for CSP headers, reporting, inline script handling, and source whitelisting.
This guide walks you through auditing a project's Content Security Policy (CSP) configuration - headers, reporting, inline script handling, and source whitelisting.
The Goal: Defense in Depth
CSP is your browser-level safety net. Even if XSS slips through your code, a strong CSP can stop malicious scripts from executing.
- Configured — CSP headers are deployed with essential directives (
default-src,script-src,frame-ancestors) - Monitored — A reporting mechanism captures and surfaces CSP violations
- Locked down — Inline scripts are blocked or secured via nonces/hashes
- Least-privilege — Source whitelists avoid overly permissive wildcards or
unsafe-eval - Production-ready — Policy is strict enough to provide real protection, not just checkbox compliance
Before You Start
- Identify where CSP could be configured (application code, nginx, Cloudflare, Vercel/Netlify headers)
- Identify frontend architecture (SPA, SSR, static site - affects CSP complexity)
- Identify third-party script usage (analytics, chat widgets, payment forms, fonts)
- Check if site is live (can test actual response headers)
general
CSP header present with key directives (default-src, script-src, frame-ancestors) - not overly permissive
“Could an attacker inject a script into your pages right now?”
CSP tested via report-only mode before enforcing, with violation reports collected and reviewed
“Did you test your CSP before it started blocking real users?”
script-src avoids unsafe-inline or uses nonces/hashes, GTM strategy documented if used
“unsafe-inline — do you know what that actually allows?”
CSP uses 'self' baseline with only necessary domains whitelisted, no wildcards or unsafe-eval without justification
“Which third-party domains does your CSP currently trust?”