CSP Made Simple: The Developer's Checklist
A practical checklist for implementing Content Security Policy
Most people look at Content Security Policy and immediately treat it as something optional. I think that is a mistake. CSP is one of the simplest ways to prevent things you did not ask for from running on your site. It is not perfect, but it forces you to be intentional about what your pages load. That alone is worth it.
Here is the practical checklist I use. It is simple, strict by default, and avoids unnecessary noise.
1. Start with a minimal but strong policy
Too many developers begin by copying a long CSP template. That only creates confusion.
Begin with the smallest set that keeps your site tight:
default-src 'self';
script-src 'self';
style-src 'self';
img-src 'self';
font-src 'self';
This gives you a clean baseline. Everything else is opt in.
2. Add only what your site genuinely needs
CSP is not a place for generosity.
If your site uses Google Fonts, add it.
If it uses a CDN for icons, add that too.
Nothing else should be listed.
CSP works best when the list is short and intentional.
3. Do not enable unsafe inline unless you have no choice
Allowing inline scripts with:
script-src 'unsafe-inline'
is basically declaring that CSP does not matter.
If you can, avoid it. Use nonces or hashes for any inline scripts you control.
It is cleaner and far safer.
4. Remember to whitelist your API calls
Developers often forget that fetch requests and other network calls also fall under CSP.
If you call an external API, you must declare it:
connect-src 'self' https://api.example.com;
If you do not, your site will silently fail.
5. Add your analytics domains explicitly
Analytics almost always break under a strict CSP.
Trackers require specific domains to be allowed.
For Google Analytics:
script-src 'self' https://www.googletagmanager.com;
connect-src 'self' https://www.google-analytics.com;
If you forget this, your numbers will confuse you.
6. Handle images properly
Images tend to come from different places, especially if you use a CDN.
Declare them clearly:
img-src 'self' data: https://your-cdn.com;
This avoids ugly broken image placeholders.
7. Declare font and style sources
Fonts and external stylesheets are the first things CSP breaks, and developers always notice too late.
Be explicit:
style-src 'self' https://fonts.googleapis.com;
font-src 'self' https://fonts.gstatic.com;
If your site suddenly looks plain, this section is the culprit.
8. Turn on reporting to see what your browser blocks
If you want insight instead of guessing, use reporting:
report-uri https://your-domain.com/csp-logs;
This is optional but extremely helpful.
9. Test your policy in report only mode first
Before enforcing a strict CSP, test it quietly:
Content-Security-Policy-Report-Only
This logs every violation without breaking anything.
Once it looks clean, flip the switch to full enforcement.
10. Keep the policy short and review it occasionally
A good CSP should fit on one screen.
If it is long, you are either being too generous or you do not understand what your site is loading.
Review it whenever you add new services or remove old dependencies.