Add a default CSP and clickjacking defence and minimal API for CSP to core

Nice!

Some questions:

- Can we via our libraries mechanism automatically emit headers for external JS added via that way?
- Is it possible to also restrict directories? Given we know all directories due to aggregation could we restrict those directories?

Even if we make it an optional hardening?

Well, core needs to support the API from day 0 - even if then only the contrib module enables it.

Adding at 8.1 will potentially break contrib modules and it is one of the most important security hardenings we can do.

It is also just 'ready' now. And the web is evolving ...

#2789139: [upstream] CSP requires 'unsafe-inline' because of CKEditor 4 also helps make this possible! :)

Core currently still requires 'unsafe-inline' when CSS aggregation is disabled due to #2897408: Remove IE9 support from CssCollectionRenderer and provide it in contrib instead.

--

I've started working on a contrib module to provide automated CSP headers at https://www.drupal.org/project/csp
Currently it parses defined libraries to add a Content-Security-Policy-Report-Only header with the necessary domains for script-src and style-src. It doesn't actually report anywhere yet other than the browser console, but a built-in report endpoint is also in the works.
#2895245: API for modules to alter policy considers adding an additional attribute to library definitions to support additional policies such as connect-src.

--

@Fabianx: "Is it possible to also restrict directories? Given we know all directories due to aggregation could we restrict those directories?"

Policies can only specify domains, not directories, but I have another experiment where I used Apache rewrite rules to establish separate subdomains restricted to their responsibilities, altered URIs to their respective subdomains, and applied the policy:

default-src 'self'; script-src assets.example.com; style-src assets.example.com; img-src assets.example.com files.example.com; connect-src 'self';

I reopened #2789139: [upstream] CSP requires 'unsafe-inline' because of CKEditor 4, since CKEditor still requires 'unsafe-inline'. The improvements in CKEditor 4.7 only removed the need for 'unsafe-eval'.

Any documentation or articles I've seen so far only uses domains, and I haven't tested the state of browser support, but the spec does allow restricting by directory (CSP Level 3 - 6.6.2.10. path-part matching).

So this would theoretically be possible:

  default-src 'self'; 
  script-src example.com/core/ example.com/modules/ example.com/themes/ example.com/profiles/ example.com/sites/default/files/js/; 
  style-src example.com/core/ example.com/modules/ example.com/themes/ example.com/profiles/ example.com/sites/default/files/css/; 

CSP module has seen significant improvements, and has a stable release now.

I've proposed using an additional property in library definitions to enable support for additional directives: #2895245: API for modules to alter policy

CKEditor has been removed from core, CKEditor 4 is removed from Drupal Core in 10.0.0

#2789139: [upstream] CSP requires 'unsafe-inline' because of CKEditor 4 comment #30

Is that unblock this issue?

A remaining issue is that the core/drupal.ajax library still requires style-src 'unsafe-inline': #3110517: Improve Drupal\Core\Ajax\AddCssCommand to accept an array of CSS assets

----

The CSP module's default enforced policy is currently quite lenient (frame-ancestors 'self'; object-src 'none'), because it's reasonably likely that something like default-src 'self' will block expected functionality and has the potential to DDOS your own site with the default of logging violation reports to the site log (if not properly configured in a dev environment before deploying to an active site).
The default report-only policy is stricter (adding style-src and script-src directives, and will include any relevant domains from library definitions), but also only reports to the browser console in anticipation of the potential initial violations.

I guess the X-Frame-Options header that core adds via FinishResponseSubscriber should also be removed when this is done. The "frame-ancestors" directive in the CSP header is well supported and obsoletes X-Frame-Options.

With IE no longer being supported, core could replace its default X-Frame-Options: SAMEORIGIN with Content-Security-Policy: frame-ancestors 'self'. Starting to always add a default CSP header could cause problems for a site that sets X-Frame-Options: DENY though. (It looks like IE was the only browser to support ALLOW-FROM).

A possible transition is:
[11.1] Add a late-subscriber that translates x-frame-options to a CSP frame-ancestors if the response does not have a CSP header (assume if a CSP header is set but does not include frame-ancestors, then it was intended to allow any frame parent). Issue a deprecation warning if the response has a value other than X-Frame-Options: SAMEORIGIN to notify users to use CSP instead.
[12.0] Remove the late subscriber, and replace X-Frame-Options with a static CSP policy that includes frame-ancestors 'self'. A site that uses the Content-Security-Policy module, SecKit, or a custom listener to set the CSP header will override this default value.

My suggestion for a minimal static policy that core can add by default:

  Content-Security-Policy: script-src * 'unsafe-inline'; object-src 'none'; frame-ancestors 'self'

The simplest way to allow modifying the default CSP (or adding a CSP-Report-Only), would be to have a container parameter. Users wanting a more flexible implementation can use the CSP module.

A slightly rough MR:
- Introduce a new service parameter for setting static CSP values
- A late acting response subscriber will translate X-Frame-Options to Content-Secutity-Policy: frame-ancestors
- If a CSP policy is set (via service parameter, or another module like CSP or seckit), then that value is not changed.
- The X-Frame-Options header is always removed - either it's being replaced by core with an equivalent CSP policy, or we assume that the CSP policy set by the user has their desired frame-ancestors value (including the option of being omitted).
- If X-Frame-Options is not set to SAMEORIGIN, then a deprecation warning is issued to use CSP to set the value. (If the value is still the default SAMEORIGIN, then a future version of Drupal changing to frame-ancestors 'self' will not change browser behaviour).
- ALLOW-FROM is ignored by modern browsers (and equivalent to not sending the X-Frame-Options header), but is translated to a CSP value if used.

In a future version of Drupal:
- The service parameter can be set to a default enforced CSP value
- The late acting event subscriber can be completely removed
- Core can stop setting X-Frame-Options
- Modules (such as CSP or seckit) will still override core's default (now static) value.

Why the CSP policy value:
- script-src * 'unsafe-inline' will only block eval(). Not including 'unsafe-inline' would have the potential to break existing sites (and hopefully its presence leads people to explore making sure it's not required...)
- object-src 'none' is recommended to block legacy HTML elements
- frame-ancestors replaces X-Frame-Options
- I don't think there's other values that can safely be added as a default enforced policy directive without a reasonable risk of negatively affecting some sites. (maybe base-uri 'self'?)

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.