SiteCheck

Guides · Security

How to start a Content-Security-Policy

Your page does not send a Content-Security-Policy. This header gives the browser a list of places your page may load scripts and other files from. If the page asks for a script from anywhere else, the browser refuses it. It is extra protection, and most sites need a developer to set it up, because a policy that is too strict can stop parts of a page from working.

What it does

A policy is one line sent with your page. Here is a simple one:

Content-Security-Policy: default-src 'self'; script-src 'self' https://stats.example

This says that files may come from your own site, and scripts may also come from stats.example. Anything else is blocked.

Scripts and styles written directly into the page are blocked too, unless the policy allows them. Many sites and site builders use these, which is why a first policy often breaks something.

Start in report-only mode

The same policy can run under a different header name. The browser then blocks nothing and only reports what it would have blocked.

How the two header modes treat an unlisted scriptA page asks for a script from an address that is not on the list. In report-only mode the script still runs and the browser logs a report. In enforcing mode the browser blocks the script. Page asks for a script from other.example Is it on the policy's list? No. Report-only header Script still runs. Browser logs a report. Visitors notice nothing. Enforcing header Script is blocked. Features that need it may stop working.
The list is the same in both modes. Only the header name decides whether the browser blocks.

How to set one up

  1. Ask your developer or host to send this header on your pages: 
    Content-Security-Policy-Report-Only: default-src 'self'
  2. Open your main pages in Chrome and open the Console in the developer tools. It lists each file the policy would block.
  3. Try your forms, checkout, maps, videos and analytics, and note what appears.
  4. Add each source you trust to the policy, and remove anything you no longer use.
  5. Repeat for a while, until no new reports appear. A developer can collect reports from real visits using the report-to directive.
  6. Rename the header to Content-Security-Policy, and test the same pages again.

Your report keeps showing this item during the report-only stage, because it looks for the enforcing header. Switch only when your testing is clean.

Site builders

Shopify, Wix and Squarespace run the server for you and often have no setting for custom headers. Their pages also load many scripts that change when the platform updates. Check their help pages or ask support. If they do not offer it, you can leave this item as it is.

Some builders let you add code to the page head, so a policy could go in a <meta> tag. A meta tag cannot run in report-only mode, and it ignores frame-ancestors. Our test reads only the header, so it would not count.

On WordPress, a header plugin or your host may be able to send the header. Plugins and themes often add scripts of their own, so test again after each update.

A CDN in front of your site can often add the header too.

How to check

Once the enforcing header is live, press Rescan on your report. The test only looks for the header, so a policy that allows everything would pass. The quality of the list is up to you and your developer.

Check a page

More security guides