sus.botdocs

Security finding

The Content-Security-Policy and what the pages load do not match

Security Warning Severity: Medium

Part of the audit The content security policy and the page disagree. Finding id: security.cspVsPage.

What it costs you

A policy that blocks what the page needs breaks features for visitors without an error anyone sees. A policy that allows hosts nobody uses, or that only reports, leaves doors open that nobody watches.

What to do

Bring the policy in line with what the pages load today: add what is blocked and wanted, remove what is allowed and unused, and enforce it.

What it checks

  • Page loads what the policy blocks
  • Policy allows hosts no page uses
  • Header and page policies differ
  • Test-only policy never enforced
  • Unsafe inline cancels nonce protection

How to fix it

Allow the blocked load or remove it

  1. Read the console message: [subject]
  2. If the page should load it, add its exact host to the directive the message names.
  3. If not, remove the tag or the code that loads it.

How to check: Open [example url] with the browser console open: no Content Security Policy message.

Remove the unused host from the policy

  1. Remove this entry from the policy: [subject]. If you are unsure, do it in a Content-Security-Policy-Report-Only header first and watch for reports.

How to check: curl -sI [example url] | grep -i content-security-policy

Keep one policy, in the header

  1. Move what the meta policy adds into the Content-Security-Policy header, then remove the meta element.
  2. A meta element does not support every CSP feature, and a report-only policy cannot be delivered in one.

How to check: View the source of [example url]: no meta element with http-equiv="Content-Security-Policy".

Enforce the report-only policy

  1. Read the violation reports and fix what they show.
  2. Then send the same policy as Content-Security-Policy. You can keep a stricter draft in Content-Security-Policy-Report-Only next to it.

How to check: curl -sI [example url] | grep -i content-security-policy

Remove unsafe-inline where it is still honoured

  1. Remove 'unsafe-inline' from [subject], and from any script-src-elem or script-src-attr directive that has it without a nonce or hash.
  2. Give the inline scripts you own a nonce or a hash.

How to check: Open [example url] with the browser console open: no Content Security Policy message. curl -sI [example url] | grep -i content-security-policy

A real case

A Google study of 1,680,867 hosts found bypasses in 94.72% of the distinct Content-Security-Policies, and 99.34% of the hosts with a policy got no protection against cross-site scripting from it.

Source: Weichselbaum and others, CSP Is Dead, Long Live CSP!, ACM CCS 2016

How to verify by hand

The site's own violation reports, if a reporting endpoint is set.

What this relies on

The page works as intended; the policy was not updated, or was loosened until nothing broke.