React

kepler.gl is one of those libraries that looks simple from the outside and then quietly pulls in a lot of browser features once you ship it: Web Workers, WebGL, map tiles, fonts, API calls, and often third-party basemaps. That makes Content Security Policy trickier than a plain React app. If you lock CSP down too early, kepler.gl usually breaks in non-obvious ways: blank map canvas workers failing to start tiles not loading icons or fonts disappearing map style JSON fetching but not rendering This guide is the practical version: what to allow, what usually breaks, and copy-paste CSP examples you can start from. ...

shadcn/ui gives you a weird CSP problem compared to most component libraries: it is not really a library in the classic sense. You copy components into your app, own the code, and then your CSP story becomes your problem. That is good for flexibility, but it also means there is no single “shadcn/ui CSP policy.” The right policy depends on how you render styles, whether you use theme scripts, whether you pull in analytics, and whether your app is static, SSR, or edge-rendered. ...

Nivo is usually a pretty easy fit for a strict Content Security Policy. That’s the good news. The catch is that teams often blame the charting library when the real CSP breakage comes from everything around it: analytics, consent banners, custom fonts, exported images, server-side rendering, or a dev setup that quietly relies on unsafe-eval. If you’re adding Nivo charts to a production app and want a sane CSP, here’s how I’d approach it. ...

goober is tiny, fast, and refreshingly unpretentious. That’s exactly why people like it. But the moment you try to lock down a real app with Content Security Policy, CSS-in-JS stops being a styling choice and starts becoming a security deployment problem. The short version: goober usually injects styles into <style> tags at runtime. CSP cares a lot about that. If your policy is strict, those injected styles can get blocked unless you deliberately allow them. ...

Phosphor Icons are easy to love: clean set, multiple weights, works fine in React, and the SVG output is usually painless. The annoying part starts when you lock down Content Security Policy and realize your icon strategy has security consequences. I’ve run into this a lot. Teams pick an icon package early, then add CSP later, and suddenly a harmless-looking icon library turns into a debate about style-src, font-src, inline SVG, third-party CDNs, and whether someone really needs a runtime script to paint a caret. ...

Recharts is usually one of the easier charting libraries to live with under Content Security Policy. That’s the good news. The bad news: teams still break dashboards with CSP all the time, usually because they copy a broad policy from somewhere else, tighten it blindly, or blame Recharts for behavior caused by their own app shell, analytics, or CSS-in-JS stack. If you’re running Recharts in a React app, most CSP issues come from the environment around the charts, not the chart library itself. Recharts renders SVG. That’s a lot friendlier than libraries that depend on eval, dynamic code generation, or canvas hacks. Still, there are a few predictable ways to mess it up. ...

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

Single Page Applications have a unique relationship with CSP. The development workflow depends on things CSP doesn’t like — eval for HMR, inline styles for CSS-in-JS, dynamic script loading. But in production, SPAs actually benefit enormously from CSP because they’re JavaScript-heavy. Here are configurations that work for each major framework, based on production deployments. React (Vite) Vite is the recommended build tool for new React projects. Development // vite.config.js export default defineConfig({ plugins: [react()], server: { headers: { 'Content-Security-Policy': "default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https: blob:; font-src 'self'; connect-src 'self' ws:; frame-ancestors 'none'" } } }); ```text You need `unsafe-eval` for Vite's hot module replacement. You need `ws:` in connect-src for the WebSocket connection Vite uses to push HMR updates. You need `blob:` in img-src because some bundlers use blob URLs for certain assets. These are development-only concessions. In production, you can be much stricter. ### Production Deploy via Nginx or your reverse proxy: location / { add_header Content-Security-Policy “default-src ‘self’; script-src ‘self’; style-src ‘self’ ‘unsafe-inline’; img-src ‘self’ data: https: blob:; font-src ‘self’; connect-src ‘self’ https://api.yoursite.com; frame-ancestors ’none’; base-uri ‘self’” always; try_files $uri $uri/ /index.html; } ...