A Content Security Policy (CSP) is a rule a website sends to the browser that lists exactly which sources are allowed to provide scripts, images, styles and other content. Anything not on the list is simply refused, even if an attacker managed to slip it onto the page.
Imagine a strict guest list at a private event. The doormen do not care how convincing a gatecrasher looks; if the name is not on the list, they do not get in. A CSP is that guest list for your web page: you declare “scripts may only come from my own domain and this one trusted analytics provider”, and the browser enforces it. This is the single most effective defence against cross-site scripting, where injected JavaScript tries to run in your visitors’ browsers.
The policy is built from directives. script-src controls where code may load from, img-src covers images, style-src covers CSS, and default-src sets a fallback for anything you did not name. A common trap is needing 'unsafe-inline' for old inline scripts, which quietly weakens the whole policy, so the cleaner fix is to move that code into proper files first.
A CSP is delivered as one of several website security headers. Because a too-strict policy can block your own legitimate code, teams usually roll it out in report-only mode first, review what would have broken, then enforce it. You can even point a report-uri at a logging endpoint so real violations show up while you tune the rules.
At TopDevs we tune a Content Security Policy for each site we build, tight enough to stop injected scripts cold while letting your real content load without a hitch.
