Optional hardening

Your site has no list of what scripts are allowed to run

What it means

A web page pulls in many pieces: your own scripts, analytics, a chat widget, fonts, maps, a payment button. By default, a browser runs a script from any address the page mentions.

A Content Security Policy is an allowlist your server sends with each page. It says, for example, run scripts only from my own site and from my payment provider, and refuse everything else. Your site does not send one, so browsers allow everything.

A CSP does not stop someone from breaking into your site. It limits what injected code can do once it is on a page, for example stopping it from loading more code from an attacker's server.

Why it matters

Small business sites get injected code through outdated plugins, compromised third-party scripts, or hacked accounts. That code can show spam, redirect visitors, or copy what they type into forms. A well-built CSP is the single setting that most limits that damage.

The catch is that a CSP has to list everything your site legitimately uses. Miss one, and that piece stops working: a chat box disappears, a form will not submit, analytics goes quiet. Sites that add plugins, apps and marketing tags often are the hardest to cover.

That is why EverThread rates this as optional. Plenty of well-run sites do not have one.

How to check your own site

1. Open your home page in Chrome, Edge or Firefox. Right-click the page, choose Inspect, and open the Network tab.
2. Reload the page. Click the first row in the list, which is the page itself, and look at the Response Headers section.
3. Look for content-security-policy. If you only see content-security-policy-report-only, a policy is being tested but not enforced.
4. To see what a policy would block, open the Console tab. Each problem appears as a message naming the address and the rule it broke.

How to fix it

Any website

1. List every outside service your site uses: analytics, tag managers, chat, fonts, maps, video, payment, booking and ad tools. Many list the addresses they need in their help pages, under a heading about Content Security Policy.
2. Start with the Report-Only header below. It uses the name Content-Security-Policy-Report-Only, so browsers report problems but block nothing. Add the addresses from your list to the right lines. For example, a script from https://www.googletagmanager.com goes on the script-src line.
3. Browse your important pages with the Console tab open: home, contact form, checkout, login. Every report is something to either add to the policy or remove from the site.
4. Leave Report-Only running for a few weeks, and recheck after adding any plugin or tag. When nothing new appears, rename the header to Content-Security-Policy to enforce it.
5. EverThread looks for the enforced header, so it will keep showing this note while you are in Report-Only mode. That is expected.

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'; frame-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self'

WordPress

1. Set the policy at the server or CDN, using the Apache, Nginx or Cloudflare steps below. That is more reliable than a plugin.
2. Be realistic about scripts. Many themes and plugins put small scripts directly in the page. A policy that blocks those will break them, and allowing them with 'unsafe-inline' weakens the protection. Even so, a policy that limits which outside sites scripts can come from is still worth having.
3. Check the admin area and your page builder as well as public pages. If the admin breaks, apply the policy to public pages only, or ask your developer to exclude /wp-admin/.

Shopify, Squarespace, Wix and other hosted builders

1. These platforms run the servers, so you cannot set this header. Some send their own policies on parts of the site, such as checkout.
2. A CSP can technically go in a tag on the page, but Report-Only mode does not work that way. On these platforms, apps and the platform itself add scripts you do not control and that change without notice. A policy you write by hand is likely to break something. For most shops on these platforms, the honest advice is to leave this alone.

Cloudflare

1. Go to Rules and create a response header rule. Depending on your dashboard, this is under Transform Rules, then Modify Response Header, or under Rules, Overview, as a Response Header Transform Rule.
2. Apply it to all incoming requests. Choose Set static, enter Content-Security-Policy-Report-Only as the header name, and paste your policy as the value. Deploy.
3. When you are ready to enforce, edit the rule and change the header name to Content-Security-Policy.

Apache (.htaccess)

1. Add these lines to the .htaccess file in your site's main folder, or to your server's site settings, with your own addresses added. This needs the mod_headers module.
2. Keep the policy on one line. To enforce, change Content-Security-Policy-Report-Only to Content-Security-Policy.

<IfModule mod_headers.c>
  Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'; frame-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self'"
</IfModule>

Nginx

1. Add this line inside your site's server block with your own addresses added, then reload Nginx. To enforce, change the header name to Content-Security-Policy.

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'; frame-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self'" always;

What to send your developer

Roll out with Content-Security-Policy-Report-Only and collect reports from real traffic, not just your own browsing: declare an endpoint with the Reporting-Endpoints header and report-to, and keep report-uri as a fallback for browsers that do not support it. For scripts, prefer nonces or hashes with 'strict-dynamic' over long host allowlists, which are easy to bypass through permissive CDNs. If you have to start with 'unsafe-inline', still set object-src 'none', base-uri 'self' and frame-ancestors, which are low-risk wins. Report-Only, frame-ancestors and report-uri are ignored in a <meta> policy. You can run an enforced baseline and a stricter Report-Only policy side by side while you tighten. See MDN on CSP and the OWASP CSP cheat sheet.

Reporting-Endpoints: csp="https://example.com/csp-reports"
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'nonce-{RANDOM}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; report-to csp; report-uri https://example.com/csp-reports

Common questions