What’s Next

There are gaps where just parsing the site’s libraries is not sufficient for a complete policy. I wrote a new Google Analytics module for Drupal 8 to address that Google still recommends including an inline script that injects a script tag into the page, even though there is a better option. Then to send data Google Analytics can use two methods: either by loading an image with parameters in the URL, or via an AJAX request. Correspondingly if the image-src or connect-src directives are restrictive a site could block its own analytics collection.

In order to address the limitations of the information currently available through library definitions the module needs a way to set defaults and manual overrides, and an API for other modules to specify additional policy values. While the API could introduce another hook or event, I think it may be possible to just build on top of the existing library system; modules could add additional items to their library definitions directly in the YML file, or by using hook_library_info_alter() where values need to be set dynamically.

Testing a policy can be done with just the browser console, but it shouldn’t be implemented on a live site without also adding a reporting directive. The module should handle storing reports in the site log, and be configurable to use external services like Report URI.

Known issues

The most significant issue is that CKEditor 4 requires inline scripts in order to function. The Content-Security-Policy module currently only creates one policy to apply to every page on the site, and since CKEditor is a core library it would require 'unsafe-inline' always be included. The best compromise may be to enable per-request changes to the policy so that only pages which include CKEditor allow inline scripts.

There are two items within core that still cause problems for the style-src directive. The first is due to core including Modernzr within the admin theme, which results in a violation due to inline styles. Some issues and pull requests to fix the problem date back to 2015 and haven’t seen any recent updates, so you might have to ignore this warning for a while longer.

The second issue is due to Drupal 8 supporting Internet Explorer 9, which has a limitation on the number of CSS files that can be included on the page through <link> tags. In order to circumvent the limitation CSS files are added inline through CSS import rules when there are too many, which is likely to happen during development when aggregation is disabled. The Content-Security-Policy module must allow inline CSS to prevent breaking the site, but adds a warning to the status page to recommend re-enabling aggregation. Drupal core no longer maintains support for IE 9 or 10 as of 8.4, and this workaround could be removed in 8.6, but if you really need to still support IE9 with unaggregated CSS, the Content-Security-Policy module integrates with the IE9 Compatibility module to keep the current behaviour.