Security

Content Security Policy: The Complete Guide for 2026 Content Security Policy, usually called CSP, is one of the most effective browser-side defenses against cross-site scripting, malicious third-party script execution, data injection, and a wide range of content loading abuses. When configured well, CSP reduces the damage an attacker can do even if some unsafe markup or script reaches the page. CSP is not a replacement for output encoding, input validation, secure templating, sandboxing, dependency review, or HTTP-only cookies. It is a powerful second line of defense. It tells the browser which resources are allowed to load, which scripts may execute, where forms may submit, whether the page may be framed, and where violations should be reported. ...

Svelte 5 doesn’t make CSP hard, but it does force you to be honest about how your app renders, hydrates, and injects code. That’s a good thing. If you’re building with Svelte 5 and runes, the CSP story is mostly about three things: avoiding inline script and style surprises handling nonces correctly for SSR not breaking hydration or third-party tooling Runes themselves don’t need special CSP directives. $state, $derived, and $effect are compile-time language features. CSP doesn’t care that you used runes. CSP cares whether the generated output includes inline JavaScript, inline styles, eval-like behavior, or external resources from origins you didn’t allow. ...

Progressive web apps make CSP slightly weirder than normal websites. A regular site mostly loads fresh resources over the network. A PWA keeps working when the network is gone, which means scripts, HTML, and API responses may come from the service worker cache instead of the server. That changes how people debug CSP failures, and it changes how you should think about policy rollouts. The short version: cached resources still need to obey CSP. Offline support does not bypass browser enforcement. But service workers can absolutely make CSP behavior confusing if you cache old HTML, stale JS, or third-party responses that no longer match your current policy. ...

Content Security Policy on WooCommerce sites is where good intentions go to die. I’ve seen teams turn on a “strict” CSP, feel great for five minutes, then realize checkout is broken, Stripe fields don’t load, product images disappear from the CDN, and marketing starts yelling because GA4 went dark. E-commerce is one of the hardest places to deploy CSP well because a store is never just your code. It’s your theme, plugins, payment providers, tag managers, fraud tools, cookie banners, live chat, analytics, A/B testing, and whatever one-off script someone added during Black Friday. ...

FullStory is one of those tools that security teams side-eye and product teams love. Session replay, event capture, rage clicks, funnels — great for debugging real user behavior, but it also means you’re injecting a third-party script that phones home constantly. That makes Content Security Policy a real concern, not a checkbox. If you add FullStory without thinking through CSP, you usually get one of two outcomes: FullStory silently breaks and nobody notices until analytics goes dark. Someone opens the policy way too far with https: and 'unsafe-inline', and now your CSP is mostly decorative. I’d rather avoid both. ...

Next.js developers usually think about CSP at the page level: block inline scripts, add nonces, lock down third-party tags. That’s the right instinct, but API routes deserve attention too. Strictly speaking, CSP is mostly a browser-enforced policy for documents and some subresources. Your JSON API endpoint isn’t executing scripts in the browser, so a Content-Security-Policy header on /api/users won’t do much for a normal application/json response. That’s the part people skip. ...

Government websites have a rough CSP problem. I’ve seen the same pattern over and over: a site adds a Content Security Policy because a scanner demanded it, ships a giant allowlist, sprinkles in 'unsafe-inline', and calls it done. The header exists, the compliance box gets checked, and the actual XSS risk barely moves. That’s not a government-specific technical limitation. It’s mostly a procurement, legacy platform, and “don’t break the citizen-facing form” problem. ...

Let me be blunt: if you’re not running Content Security Policy on your website, you’re leaving the front door wide open for Cross-Site Scripting (XSS) attacks. And no, input sanitization isn’t enough. It never has been. I’ve seen countless security audit reports where everything looks great on paper — input validation, output encoding, WAF rules — but one missing CSP header turns all of that into a suggestion rather than a guarantee. ...