Headers

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

Milligram is tiny, clean, and boring in the best possible way. That makes it a great fit for a strict Content Security Policy. If your CSS framework is just a stylesheet and not a JavaScript carnival, you can usually lock things down harder than most teams think. I’ve seen the opposite happen in production: a simple site starts with Milligram, then marketing adds Google Tag Manager, analytics, a consent banner, maybe a form embed, and suddenly the CSP turns into a landfill of wildcard domains and unsafe-inline. ...

Google Maps is one of those integrations that looks trivial right up until CSP starts blocking half of it. I’ve seen this play out a few times: the site already has a decent policy, someone drops in a Maps embed or the JavaScript API, and suddenly the console fills with CSP errors. The quick fix is usually script-src https://maps.googleapis.com 'unsafe-inline' plus a couple of random domains copied from Stack Overflow. That works, but it also turns a decent policy into a mushy one. ...

Trust badges and review widgets are classic CSP troublemakers. They look harmless: a tiny badge, a star rating, maybe a “verified reviews” block in the footer. Then you add one script and suddenly you need script-src, frame-src, img-src, style-src, and connect-src exceptions across half the internet. I’ve cleaned this up on enough production sites to have a strong opinion: treat every badge or review widget like a third-party app, not a decoration. ...