Web-Security

If you use Aragon icons and your CSP is even slightly off, the breakage is usually annoying, subtle, and easy to misdiagnose. You see missing icons, blank squares, CSP console noise, or everything works locally but fails in production. I’ve hit this enough times to have strong opinions about it: most CSP problems around icon libraries come from guessing which directive applies. People tweak default-src, maybe throw in img-src data:, and hope for the best. That’s not how CSP works. ...

Teams usually discover CSP problems with Linaria the annoying way: everything works in development, then production gets a stricter policy and styles start disappearing. I’ve seen this happen when a team moves from a relaxed policy to something closer to a real production header, like the one headertest.com sends: content-security-policy: default-src 'self' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com; script-src 'self' 'nonce-MjgzMGM0NjctNzg4MS00NTNiLThkN2UtNjY3N2VmMTRlOGUy' 'strict-dynamic' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com; style-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://*.cookiebot.com https://consent.cookiebot.com; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.headertest.com https://tallycdn.com https://or.headertest.com wss://or.headertest.com https://*.google-analytics.com https://*.googletagmanager.com https://*.cookiebot.com; frame-src 'self' https://consentcdn.cookiebot.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; object-src 'none' That header is realistic because it shows the usual compromise: strong script controls, but style-src 'unsafe-inline' left behind because CSS tooling got messy. ...

PDF.js is one of those libraries that looks simple until CSP gets involved. You drop in the viewer, load a PDF, and everything works locally. Then you turn on a real Content Security Policy and suddenly the worker fails, fonts disappear, images stop rendering, or the whole viewer goes blank with a useless console error. I’ve hit this a few times. The pattern is usually the same: people start with a generic CSP, then keep adding exceptions until the app works again. That usually ends with unsafe-inline, unsafe-eval, and a policy that technically exists but doesn’t really protect anything. ...

I’ve seen the same pattern over and over: a team adopts a utility-first CSS framework, ships fast, then bolts on CSP later and wonders why the site breaks in weird places. Pharaoh CSS is no exception. The good news is that CSS-heavy sites are usually easier to lock down than JavaScript-heavy apps. The bad news is that most teams still start with a lazy policy like style-src 'unsafe-inline', leave it there forever, and call it “good enough”. It usually isn’t. ...

bare.css is the kind of CSS library that security folks usually like: tiny, boring, and not trying to be a JavaScript framework in disguise. That changes the CSP conversation quite a bit. If your site uses bare.css and almost nothing else, you can usually run a very tight policy. If your “simple” site also includes analytics, consent banners, embedded forms, tag managers, and a couple of convenience scripts, your CSP gets messy fast. I’ve seen plenty of “minimal” websites end up with a header that looks like an ad-tech startup wrote it. ...

YouTube embeds look simple until CSP gets involved. The usual failure mode goes like this: you paste an <iframe> embed, add autoplay=1, ship a strict policy, and suddenly the video is blank or blocked in the console. Then someone “fixes” it by throwing https: into frame-src or loosening half the policy. That works, but it’s lazy and expensive from a security standpoint. Here’s the version I’d actually ship for a developer-facing site. ...

If you’re tuning CSS in production, you’ll usually end up doing two things: minifying with cssnano removing unused selectors with a purge step Those are build-time optimizations, so people assume CSP has nothing to do with them. That assumption bites later. CSP does not care that your CSS was generated by PostCSS, cssnano, Tailwind, PurgeCSS, or a custom pipeline. CSP only sees what the browser sees: where styles came from, whether they were inline, and whether some script injected them at runtime. ...

Spotify embeds are simple until your CSP blocks them. You paste the iframe, reload the page, and get a blank box or a browser console full of Refused to frame errors. I’ve hit this enough times that I keep a tiny checklist for it. This guide is that checklist, with policies you can copy-paste. If you only need the shortest possible answer: Spotify embeds need frame-src https://open.spotify.com If your page itself is allowed to be embedded nowhere, keep frame-ancestors 'none' You usually do not need to loosen script-src for a plain Spotify iframe embed If your CSP is based on default-src 'self', you must explicitly allow Spotify in frame-src The basic Spotify embed HTML A typical Spotify embed looks like this: ...

Cookie consent banners are one of the easiest ways to blow up an otherwise clean Content Security Policy. I’ve seen teams lock down script-src, remove inline JS, add nonces everywhere, and then ship a consent platform that quietly needs half a dozen extra hosts, a stylesheet exception, iframe support, and a callback script jammed into the page head. Suddenly the CSP report inbox catches fire. This guide is the practical version: what to allow, where teams usually get it wrong, and copy-paste CSP examples for OneTrust and Osano. ...

Facebook video embeds are one of those things that look trivial until CSP starts blocking them. You paste Facebook’s embed code, reload, and suddenly your console is full of Refused to frame or Refused to load the script errors. The fix is usually small, but the exact directives matter. If you loosen the wrong thing, you end up with a policy that “works” and quietly stops protecting anything useful. Here’s the practical reference I wish more teams had handy. ...