Content Security Policy

Why it matters

It is one of the more effective defences against cross-site scripting, where an attacker injects malicious script into a page. Even if an attacker finds a way to inject a script tag, a correctly configured CSP prevents the browser from actually executing anything not loaded from an approved source. It also serves as a second, independent layer if a vulnerability elsewhere in the application is ever exploited, meaning a single coding mistake does not automatically translate into a successful attack on a visitor. It also has to be maintained as a living document: every new third-party script, a chat widget, an analytics tool, has to be explicitly added to the policy or it will be silently blocked.

What goes wrong when it's handled badly

A CSP that is too permissive, allowing scripts from any source or allowing inline scripts broadly, defeats much of its own purpose. A CSP that is too strict without careful testing can break legitimate functionality, like a payment provider's own script failing to load, which is why it is configured deliberately against the specific third-party scripts a page actually needs, not applied as a generic template. A concrete example is a CSP configured once at launch and never revisited, still blocking a legitimate analytics script added a year later, which teams sometimes work around by disabling the policy entirely rather than updating it correctly. Running a CSP in report-only mode first, which logs violations without blocking anything, is the standard way to find these gaps safely before switching to full enforcement. Documenting exactly why each allowed source is in the policy makes the next review faster and safer than reconstructing the reasoning from scratch.