loke.dev
Header image for Why Is Your Content Security Policy Still Throwing Console Errors in Production?

Why Is Your Content Security Policy Still Throwing Console Errors in Production?

Stop the 'trial and error' cycle of fixing CSP violations and learn how to build a strict policy that doesn't break your third-party integrations.

· 5 min read

Why Is Your Content Security Policy Still Throwing Console Errors in Production?

Most Content Security Policies (CSP) are nothing more than security theater, and deep down, you probably know it. We spend hours whitelisting domains like https://*.googleapis.com only to realize we've essentially left the back door unlocked and the key under the mat. If your browser console is currently a sea of red CSP violations despite your best efforts, it’s likely because you’re trying to manage a static list of "trusted" sources in a web ecosystem that is anything but static.

The "whack-a-mole" approach to CSP—where you wait for a bug report, copy the blocked URL, and add it to your header—is a recipe for burnout. Let’s talk about why your policy is failing and how to move toward a "Strict CSP" that actually works.

The "Domain Whitelist" Trap

We’ve all been there. You want to add Google Analytics, so you add www.google-analytics.com to your script-src. Then you add Stripe, so you add js.stripe.com. Before you know it, your CSP header is 4kb long and looks like a phone book from 1998.

The problem? Domain whitelists are bypassable. If an attacker finds a way to upload a malicious script to a "trusted" domain (like a public CDN or a cloud storage bucket), your CSP will happily let it execute. Moreover, modern scripts often load *other* scripts dynamically. When that third-party library updates and starts fetching dependencies from a new subdomain, your production site breaks.

The Secret Sauce: strict-dynamic

Instead of trying to predict every URL your dependencies might touch, you should be using a Nonce-based policy combined with strict-dynamic.

A "nonce" (number used once) is a cryptographically strong random string generated on every single request. You add it to your script tags, and you tell the CSP that any script with this nonce is trustworthy.

<!-- In your server-side template -->
<script nonce="ed3b98be6459" src="https://example.com/app.js"></script>

But what happens when app.js tries to load a tracking pixel or a support chat widget? That's where strict-dynamic saves your sanity. It tells the browser: "If I explicitly trusted a script with a nonce, I also trust any scripts that *it* programmatically injects into the page."

Here is what a modern, robust CSP header actually looks like:

Content-Security-Policy:
  object-src 'none';
  script-src 'nonce-rAnd0m123' 'strict-dynamic' https: 'unsafe-inline';
  base-uri 'none';

Why the `https:` and `'unsafe-inline'`?
These are backward compatibility fallbacks. Older browsers that don't understand strict-dynamic will ignore it and fall back to the older whitelist-style rules. Modern browsers will see strict-dynamic and automatically discard the https: and 'unsafe-inline'. It’s a clever bit of "progressive enhancement" for security.

CSS is the Sneaky Culprit

If your scripts are fine but you're still seeing violations, look at your styles. CSS-in-JS libraries (like Styled Components or Emotion) are notorious for injecting <style> tags directly into the <head>.

If you see an error like Refused to apply inline style because it violates the following Content Security Policy..., you have two choices:

1. The Nonce way: Pass the nonce to your CSS-in-JS provider (most support this).
2. The Hash way: If the style block is static, you can provide a SHA-256 hash of the content in your header.

style-src 'self' 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=';

Pro tip: If you use 'unsafe-inline' for styles, you're technically vulnerable to CSS injection attacks (which can be used to exfiltrate data via background images), but in the real world, this is often the "necessary evil" developers accept to keep their UI frameworks from exploding. If you can avoid it, do.

Stop Guessing: Use Report-Only Mode

Never, ever deploy a new CSP directly to production. You *will* break something. I've done it, you've probably done it, and it's never a fun Monday morning.

The Content-Security-Policy-Report-Only header is your best friend. It tells the browser: "Don't actually block anything, just send a JSON blob to this URL whenever something *would* have been blocked."

Content-Security-Policy-Report-Only:
  default-src 'self';
  report-to /csp-violation-endpoint;

You can use a service like Sentry or even a simple lambda function to collect these reports. This lets you see exactly what you missed—like that one legacy analytics script running only on the /checkout/success page—without affecting the user experience.

The Edge Case: "Refused to connect to..."

Sometimes the error isn't about a script loading; it's about a script trying to send data back home. This triggers a connect-src violation.

If you use Sentry for error tracking or Mixpanel for analytics, they need to be explicitly allowed in connect-src. Unlike scripts, connect-src doesn't support strict-dynamic. You still have to maintain a small whitelist here, but since these are API endpoints and not script execution sources, the security risk is significantly lower.

Final Sanity Check

Building a CSP is an iterative process. If you're still seeing errors:
1. Check your nonces: Are they being regenerated on every request? (If they stay the same, they're useless).
2. Check for "Blob" and "Data" URLs: Some libraries (like Mapbox or Web Workers) use blob: or data: URLs. You might need to add these specifically: script-src 'nonce-xxx' 'strict-dynamic' blob:.
3. Check the console source: Click the filename in the console error. Is it a browser extension? Sometimes, users have "Dark Mode" or "AdBlock" extensions that inject code into your site. You can't fix these, and your CSP *should* block them. Don't waste time trying to whitelist every user's local setup.

A perfect CSP doesn't exist, but a strict one is closer than you think. Ditch the giant whitelists, embrace the nonce, and let strict-dynamic do the heavy lifting. Your console (and your security auditor) will thank you.