Content Security Policy

coreSecurity Pro plugin supports wide range of CSP features, considering that CSP specification is ever evolving and various elements of the specification have been changed over the years many times. The goal is to deliver specifications support that covers most popular browsers support today and widest range of stable elements of the CSP specifications.

CSP or Content Security Policy is a very important security header, and to learn more about it, check out this Mozilla Developer Network documentation, and additional document: Content Security Policy.

CSP Reports Logs Panel

If the CSP feature is enabled, a new panel is added to the coreSecurity where you can see all logged violations of the CSP directives. These reports are stored only if you enable logging directive in the settings for CSP. Reports show which directive was violated, on which page of your website, what resource was blocked (URL that was not compliant to the directive) as a source of violation, including the IP of the violation origin.

There are additional data gathered and as this data is less important, it is part of the hidden logs meta row, where you can see more if needed. To learn more about this panel, check out CSP Reports Log article.


Method for adding headers

  • Select Method: If your server supports .HTACCESS file, that is the best method to add headers. Direct method works with any server and headers are added using PHP on every page request, and only for web pages. CSP added to .HTACCESS is served for all files coming from the server!

Basic Settings

Header Mode

  • Select Header More: CSP can be added in ‘Report Only’ or ‘Live’ mode. Report only mode will show errors in browser, but will not enforce CSP rules. It is useful for validation of rules during development or testing.

Before switching to Live mode, make sure to properly test it:

  • Do not switch to the Live policy mode before you make all the tests with the Report policy mode.
  • During the testing phase, it is best to disable Log option, or you will end up with a lot of reports logged. Use Log feature when you switch to Live policy mode.
  • To test CSP, use Google Chrome or Mozilla Firefox Development Console. But will display detailed information in the Console about each CSP issue.

Header Flags

These are CSP specification elements that are enabled by only including them inside the CSP, they have no additional options.

  • Upgrade Insecure Requests: Forces user agent to upgrade all HTTP requests to HTTPS.
  • Block All Mixed Content: Prevent any resources from loading from HTTP if the page is loaded using HTTPS.

Log Violations Reports

The very powerful element of the CSP is ability to get reports when the directives are violated, and ability to use these report to track issues. coreSecurity can log the CSP reports, or you can use external service for CSP report logging.

  • Log Reports: The plugin will add reporting part of the policy. This feature will work only if CoreActivity plugin is active.
  • Custom Log URL: If you use some other website to track CSP reports, you need to add the URL to send reports to here. If this is enabled coreSecurity can’t log the violations in the same time, it is either internal logging here, or custom external services.
  • Force SSL report URL: In some cases, network home URL for the website might be generated with HTTP even if your website is set to use HTTPS. Enable this option, only if you use HTTPS URL and SSL.
  • Log Original Policy: Each report contains full original CSP policy that is not very useful to log, and it takes a lot of space.
  • Do not log Admin pages: Policy violations generated on the website admin side will not be logged, which useful if you use third party plugins that show adds linked to their website, and you are not going to add to the CSP anyway.

Do you really need to have original policy logged? Well, that depends, and there are some cases where you may do that, at least for a while:

  • It is sent for reference purposes as a proof that CSP failed because of the element of that policy.
  • You can log it to match it to your real policy as a method to discover eventual HTTP headers tampering.


This is useful and powerful aspect of the CSP, but the browser support is not consistent right now, and some aspects of the sandbox directive are not working in every browser.

  • Sandbox Directive: Forces running the resource inside the sandbox similar to IFRAME, with restrictions to various action
  • Allowed Items: Currently, there are 14 elements to this directive that are widely supported, and this list will change in the future, depending on the specification changes.

Predefined Rules

Now, this is very important part for making the CSP setup easier, because some of online services you may use can have very complicated CSP rules requirements with dozens of different directives and many different URLs to allow. Keeping track of all that is quite complicated, and Dev4Press has started the open project for tracking popular online websites and services rules for CSP. You can check that here: Content Security Policy Library. This Library is used for the predefined rules in the coreSecurity, and the list will be updated in the future.

If you use Google Analytics, Google Fonts, you integrate Instagram feed on your website, simply check these services on this list, and their rules will be auto-populated in CSP, without you needing to add individual rules manually.

Directive Settings

Now, each CSP directive is listed with the same settings. To understand how it is set, here is the image of one directive:

CSP Settings for a single Directive.png

So, for each directive, you need to change the Status first. There are four status possible:

  • Disabled: Directive will not be added to the CSP.
  • None: Directive will be added, but nothing will be allowed under that directive. If the directive is for JS files, no JS files will be allowed to load!
  • All: Directive will be added unrestricted, everything will be allowed.
  • Self: Directive will be added allowing your website (self) and additional custom URLs and special elements.

Option for Custom URLs allows you to add one or more URL to allow. This option supports use of wildcards to define URLs. Some of the possible methods to set them are:

  • https: – Matches any url over HTTPS scheme.
  • – Matches both HTTP and HTTPS version of the URL.
  • https://* – Matches HTTPS subdomains for the URL, but now the main domain.
  • – Matches exact domain URL, with the specified port.
  • *:// – Matches any scheme for subdomain and any port, but not the main domain.
  • – Matches exact domain URL, no other subdomains.

Additional elements to use in each directive are listed here:

  • unsafe-inline: allows inline elements (for JS directive, allows script tags).
  • unsafe-eval: allow use of dynamic script evaluation code.
  • unsafe-hashes: allows use of specific
  • strict-dynamic: allow scripts that are loaded by other scripts with added nonce and hash.
  • data: allow use data: URLs as content source.
  • mediastream: allow use mediastream: URLs as content source.
  • blob: allow use blob: URLs as content source.
  • filesystem: allow use filesystem: URLs as content source.
  • report-sample: requires a sample of the violating code to be included in the report.
  • wasm-unsafe-eval: allows loading and use of WebAssembly modules.

List of Basic Directives

Basic directives include the following directives, and most websites need to use these:

  • default-src: a basic directive that is used as a fallback for all other directives, if they are not included.
  • script-src: directive dealing with the JavaScript files and inline JavaScript code.
  • style-src: directive dealing with the CSS files and inline stylesheets.
  • img-src: directive dealing with the images.
  • font-src: directive dealing with the fonts.
  • media-src: directive dealing with the media files (audio and video).

List of Expanded Directives

This is the list of directives that many websites will need to use if they deal with some special content (frames, remote connection and more). If you use most of the predefined rules, they will enable one of these directives if needed.

  • connect-src: directive dealing with the URLs related to script interfaces like: AJAX (XMLHttpRequest), WebSocket, EventSource and more.
  • child-src: directive dealing with the web workers source and nested browsing contexts like FRAME or IFRAME.
  • frame-src: directive dealing with nested browsing contexts like FRAME or IFRAME.
  • manifest-src: directive dealing with manifest files that can be applied to resources.
  • object-src: directive dealing with valid sources for the EMBED and OBJECT elements.
  • worker-src: directive dealing with valid sources for Worker, SharedWorker and ServiceWorker scripts.
  • form-action: directive dealing with allowed URLs to be used as a valid target for forms submissions.

List of Advanced Directives

  • frame-ancestors: directive dealing with the valid parents that may embed pages as OBJECT, EMBED, FRAME or IFRAME.
  • script-src-attr: directive specifying valid source for inline JavaScript event handlers.
  • script-src-elem: directive specifying valid source for inline JavaScript SCRIPT elements
  • style-src-attr: directive specifying valid source for inline styles applied to individual DOM elements.
  • style-src-elem: directive specifying valid source for inline STYLE and LINK elements
  • base-uri: directive specifying valid URLs for document BASE element.

Limitation of CSP implementation

While the CSP implementation in coreSecurity is very elaborate, it doesn’t cover everything CSP has. The missing and unsupported elements are impractical to support in the context of the WordPress considering that every plugin has the ability to add code anywhere inside the page.

  • nonce-*: cryptographic nonce used for each script (linked or inline). This is highly problematic to implement, since it requires parsing full HTML page, isolating each SCRIP tag, calculating the nonce, modifying HTML to include it and add it to CSP for each page individually.
  • sha*-*: similar to previous one, but using cryptographic hash functions (sha256, sha384 and sha512).

The main issue is that plugin would need to track every inline script for every website page (because they can be different), and track each one, calculate and cache hashes or nonces, run full page processing and parsing for each time page is served to modify these scripts and generate new CSP policy each time.

Right now, there are no plans to implement these types of CSP directives due to complexity of the process, and potential issues it can have on website loading, especially with cache plugins involved.

Rate this article

You are not allowed to rate this post.

Leave a Comment