Web-Security

Educational platforms are a CSP minefield. A normal marketing site might load a few scripts, an analytics tag, and maybe a video embed. An LMS loads SSO flows, SCORM packages, grading tools, PDFs, discussion widgets, proctoring apps, webinar platforms, analytics, and random third-party course content written by people who have never heard of CSP. So the trick is not “make CSP strict at all costs.” The trick is building a policy that blocks obvious abuse without breaking the actual learning experience. ...

Content Security Policy and Subresource Integrity solve different problems, and they work best when you treat them as a pair. CSP answers: what sources am I willing to trust? SRI answers: is this exact file the one I meant to load? That distinction matters. I still see teams deploy one and assume they’re covered. They’re not. If you load a third-party script from an allowed domain in CSP, CSP is happy. But if that third-party file changes unexpectedly, CSP won’t help. SRI will. ...

Content Security Policy has a reputation problem. A lot of teams either treat CSP like a magic anti-XSS shield, or they avoid it because they assume it will break everything. Both takes are wrong. CSP is powerful, but it’s also easy to misuse in ways that give you a nice-looking header and very little real protection. I’ve seen plenty of production policies that look serious because they’re long, but collapse the moment an inline script sneaks in or a third-party script gets too much trust. ...

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