By Published on

CSP as a single best move toward web security (but not used)

Content Security Policy (CSP) is one of the most powerful security controls the web has ever invented, yet adoption is still surprisingly low.

Do you want to know why, what CSP actually protects, and why the ecosystem hasn’t embraced it as widely as it deserves? Read on.

First, if you never heard of CSP, start here Example of a medium-strict Content Security Policy.

Second, please note: if your development team changes every few months and new coders build on remnants of previous spaghetti code then CSP is not for you. It will break - for no obvious reason - everything on your website.

What CSP actually protects against

CSP (Content Security Policy) is primarily designed to stop:

  • Cross‑Site Scripting (XSS)
  • data exfiltration via injected scripts
  • inline JavaScript execution
  • loading malicious resources from attacker domains
  • clickjacking (via frame‑ancestors)
  • mixed content
  • dangerous eval()‑like constructs

In other words, CSP is the closest thing we have to a browser‑enforced firewall for web pages.

If implemented correctly, CSP can make entire classes of attacks impossible.

So why isn’t CSP widely deployed?

This is the part most people don’t realize:
CSP is extremely powerful, but extremely hard to deploy correctly.

Here are the real reasons adoption is low.

1. CSP breaks a lot of existing websites

Most websites — especially older ones — rely on:

  • inline <script> tags
  • inline event handlers (onclick="...")
  • inline CSS
  • third‑party scripts that inject inline code
  • analytics tools that use eval()
  • ads that load scripts dynamically
  • widgets that load scripts from unpredictable domains

A strict CSP (script-src 'self') breaks all of this.

Fixing it requires:

  • refactoring JavaScript
  • moving inline code into external files
  • adding nonces or hashes
  • auditing every third‑party script

This is expensive and time‑consuming.

2. Third‑party scripts make CSP nearly impossible

Modern websites depend on:

  • analytics
  • ads
  • tag managers
  • social widgets
  • A/B testing tools (split testing)
  • payment widgets
  • chat widgets

These often load more scripts, from more domains, sometimes dynamically.

A strict CSP becomes unmanageable because:

  • you must whitelist every domain
  • those domains change
  • those scripts load other scripts
  • some require unsafe-inline or unsafe-eval

This defeats the purpose of CSP.

3. CSP requires deep architectural discipline

To deploy CSP correctly, a team must:

  • eliminate inline JavaScript
  • use nonces or hashes
  • avoid eval() and similar constructs
  • audit every script source
  • maintain a strict allowlist
  • monitor violations
  • update CSP as the site evolves

Most teams don’t have the discipline or resources for this.

4. CSP is easy to get wrong

A single mistake like:

script-src 'self' https://example.com 'unsafe-inline'

…completely destroys the protection.

Or:

script-src *

…which is basically no CSP at all.

Many sites deploy CSP in “report-only” mode forever because enforcing it breaks things.

5. Frameworks didn’t support CSP well until recently

React, Angular, Vue, and others historically:

  • used inline scripts for hydration
  • used eval-like constructs
  • generated unpredictable code
  • required unsafe-inline for certain features

Only in the last few years have frameworks started to support CSP‑friendly patterns.

6. CSP is not required by most compliance frameworks

PCI‑DSS, SOC2, ISO27001, GDPR — none of them mandate CSP.

So companies deprioritize it.

So what’s the real story?

CSP is incredibly effective — but only if you build your site with CSP in mind from day one.

Retrofitting CSP onto an existing site is like trying to add earthquake reinforcement to a house that’s already built.

The modern trend: “CSP Level 3 + nonces”

The best practice today is:

  • script-src 'nonce-XYZ'
  • no inline scripts without a nonce
  • no unsafe-inline
  • no unsafe-eval
  • strict domain allowlists
  • frame-ancestors to prevent clickjacking
  • object-src 'none'
  • base-uri 'none'
  • connect-src restricted to known APIs

This is extremely strong — but again, requires architectural discipline.

Summary

CSP is one of the strongest defenses against XSS and script injection, but adoption is low because it requires major architectural changes, breaks legacy patterns, and is difficult to maintain in a world full of third‑party scripts.

CSP could be the next big leap in web security, but only if the ecosystem evolves to make it easier to adopt.