Hugo

I’ve run into this exact problem a few times: a team tightens Content Security Policy, ships it to production, and suddenly half the icons vanish. Not SVG logos. Not a giant component library. Tiny CSS.gg icons. They look harmless because CSS.gg is “just CSS”. That’s exactly why they get people into trouble. CSS-based icon sets often depend on inline styles, pseudo-elements, CSS variables, or external stylesheets loaded from a CDN. All of those can collide with a strict style-src. ...

A lot of CSP advice sounds clean on paper and falls apart the second you add the usual site accoutrement: analytics, tag managers, cookie consent, forms, embeds, and one “temporary” inline script that survives for two years. That’s why CSP work gets messy on real sites. I’m going to use a real-world style policy based on the header observed on headertest.com and walk through what a developer-facing site like csp-examples would look like before and after tightening it up. ...

I’ve seen this exact failure more than once: marketing drops in a Stripe pricing table, everything looks fine locally, then production CSP quietly blocks it and the page ships half-broken. The annoying part is that Stripe’s pricing table is simple to embed, but CSP rarely is. If your site already has Google Tag Manager, analytics, consent tooling, and a reasonably locked-down policy, adding one more third-party script can turn into a guessing game fast. ...

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. ...