Roll out a policy

Scan the site, send Consepo's policy in report-only mode, fix what the reports show, then enforce it. The site needs a connected account; see Connect your Consepo account.

The rollout

1. 1

   Scan the site

   On the Overview, choose Scan this site. Consepo crawls the home page and the pages it links to with a real browser and suggests a policy from what they load. Later scans use Scan again, which re-runs the same scan rather than creating a new one.

2. 2

   Wait for the policy

   The Scan facts show Queued, then Complete. The plugin checks every five minutes for up to three hours, and Refresh asks Consepo straight away.

3. 3

   Send it in report-only mode

   Under Policy, choose Report-only, keep the source on Consepo, and choose Save in the header. Browsers report what the policy would block and block nothing.

4. 4

   Check the header

   The Header section shows exactly what public pages now send.

5. 5

   Read the reports

   With Report violations to Consepo on, browsers send reports to the site’s Consepo report address. Review them in Consepo and allow what the site genuinely needs.

6. 6

   Enforce

   When the reports show nothing you want to keep, switch the mode to Enforcing and save.

What a scan leaves behind

The Overview's What the crawl found section says whether the crawl saw inline scripts, inline styles or likely eval(). Inline scripts are the common case on WordPress; Script nonces lets WordPress's own inline scripts run without 'unsafe-inline'.

A site has one Consepo scan. Scan again re-runs it in place, so it does not count as a new application against the Consepo plan. While a re-run is in progress, and if it fails, the site keeps sending the last policy that completed. If the scan was deleted in Consepo, the Overview shows Deleted in Consepo and the next scan creates a new one.

Scans started from the Overview crawl up to 10 pages, 10 links deep. The admin REST API accepts limit up to 100 and depth up to 10.

Modes and sources

Switch the source to Custom to keep changes of your own: paste the policy from Consepo, edit it, and save. A custom policy is cleaned before it is stored and sent:

• Control characters and line breaks become spaces, so a stored policy cannot inject a second header.
• Policies longer than 8,000 characters are cut at the last directive that fits.
• When a directive appears twice, the first one wins, as it does in browsers. Malformed directive names are dropped.
• Any report-uri or report-to is removed. The plugin adds its own report-uri when reporting is on.

Where the header is sent

The header goes on public pages only, from WordPress's send_headers action. It is not sent:

• in wp-admin, on wp-login.php, or on REST API responses;
• in the Customizer preview;
• when the mode is Off, or the chosen source has no policy yet (no completed scan, or an empty custom policy);
• when PHP has already sent a header with the same name, for example from another security plugin. Two policies would both apply and the page would get the stricter of them, so the plugin leaves the other one alone;
• when the consepo_csp_scanner_send_policy filter returns false. See Hooks and constants.

An example of what a public page received in report-only mode, with nonces on and before the first scan (so without report-uri):

content-security-policy-report-only: default-src 'self'; script-src 'self' 'nonce-U9khxe9n2dwfUgmnZAyGQk6C'; img-src 'self' data: