Content Security Policy (CSP)

CSP is a defence the browser enforces on the site's behalf. If an attacker manages to inject a script into a page, for example through a vulnerable comment form, a strict CSP stops the browser from running it, because the script does not come from an approved source. Its main purpose is limiting cross-site scripting (XSS), one of the most common web attacks.

CSP does not stop someone hacking your server or stealing passwords. It is one layer that limits the damage when something else fails, alongside updates, a web application firewall and secure code.

How it works

The server adds a response header named Content-Security-Policy to each page. The header contains directives, each naming a type of resource and the sources allowed for it. For example, default-src 'self' allows resources only from the page's own origin (the same scheme, domain and port), script-src adds approved script sources such as an analytics provider, img-src lists image sources and frame-ancestors controls which sites may embed your pages in a frame, which helps prevent clickjacking.

By default, a strict policy blocks inline scripts, the small pieces of JavaScript written directly into the page. Sites that need them either move the code into separate files or mark approved inline scripts with a nonce, a random value generated for each page load, or a hash of the script's contents. Allowing 'unsafe-inline' removes most of the protection CSP offers against XSS.

Because a mistake can break a site, policies are usually rolled out with a second header, Content-Security-Policy-Report-Only. In this mode the browser loads everything but reports what it would have blocked, either in the browser's developer console or to a reporting address. Once the reports show only unwanted sources, the policy is switched to enforcing mode.

Example

A catering company's site uses its own scripts and styles, a hosted font service and an embedded map. Its developer sets a policy allowing scripts only from the site itself, fonts from the font service's domains and frames from the map provider. Inline scripts are moved into files, so no exceptions are needed.

Months later the owner pastes a chat widget snippet into the site's footer and the widget does not appear. The browser console shows the CSP blocked the widget's script and its connection to the chat service. Rather than loosening the whole policy, the developer adds the chat provider's specific domains to script-src and connect-src, and the widget works while everything else stays locked down.

Why it matters for your business

A CSP reduces the harm from one of the most common classes of web attack, including scripts that steal form data or card details from checkout pages, and some security audits and payment security reviews look for one. It costs little to run but takes care to set up and maintain: every new third-party tool, from analytics to chat, needs its sources added, or it will silently fail. For a small brochure site the benefit is modest; for sites with logins, forms or payments it is a sensible layer. You can check whether a site sends one with free header-checking tools, or by opening the browser's developer tools and looking at the response headers in the Network tab.

Common mistakes

• Adding 'unsafe-inline' and broad wildcards to make everything work, which removes most of the protection.
• Switching straight to enforcing mode without a report-only trial, then breaking forms, embeds or analytics.
• Forgetting to update the policy when adding a new third-party tool, so it fails without an obvious error.
• Setting the policy on some pages but not others, leaving gaps an attacker can use.

Questions people ask

Does my website need a Content Security Policy?

It is not legally required, but it is recommended security practice, especially for sites with forms, logins or payments. A small static site gains less, though a simple policy is still worthwhile. The main cost is maintaining it as you add third-party tools.

How do I check if a website has a CSP?

Open the browser's developer tools, go to the Network tab, reload the page and select the main document request. Look for a Content-Security-Policy header in the response headers. Free online header-checking tools show the same information and often rate the policy's strength.

Why did my CSP break my website?

Usually because a script, style, font, image or frame comes from a source the policy does not allow, or because inline code is blocked. The browser console lists each blocked resource. Add only the specific sources you trust, or move inline code into files.