Add a default Content-Security-Policy and clickjacking defence 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.

Update issue summary

Rebased and fixed the bot's previous issue.

In my previous comment I wasn't sure of the core dev timeline, but this looks like it's something that could be put in 10.4, with the compatibility later removed in 11.0.0.

Added some comments to MR.

Can be rebased so tests appear green please.
Also is it meant to be draft?

For the CR you can actually go ahead and create it just don't check published yet till the issue is merged.

- Squashed and rebased
- Draft Change Record created
- Postponed issue for 12.x created

I'm not sure why tests are failing on ImageStylesPathAndUrlTest:L315

Remaining questions:
- Service parameter name: http.response.content_security_policy (like http.response.debug_cacheability_headers) or csp.config (like cors.config) or ?
- Should any X-Frame-Options header present on a response be removed, since browsers will ignore it when CSP is present?
- Review additional directives to add by default: script-src * 'unsafe-inline'; object-src 'none'

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.

False positive

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.

Something that came up in #2868079: Add a default Content-Security-Policy-header for svg files is that there may be a need for different policies in certain cases - uploaded files should probably have scripts and styles blocked, though SVGs may need inline styles, image data, and fonts. Private files can have the header applied from the event subscriber, but public files would require an addition to .htaccess.

Instead of a single set of policies, the service parameter could be keyed by use:

default:
  report_only:
  enforced: "script-src * 'unsafe-inline'; object-src 'none'; frame-ancestors 'self'"
files:
  report_only:
  enforced: "default-src 'none'"
svg:
  report_only:
  enforced: "default-src 'none'; style-src 'unsafe-inline'; image-src data: font-src: data:"

For SVG images,

I have spotted this error, which says I need `data:` whitelisted.

 Content-Security-Policy: The page’s settings blocked the loading of a resource (img-src) at data:image/svg+xml,%3csvg width='24' hei… because it violates the following directive: “default-src 'self'” js_J79s-Ta4InFzicdahjWbsmc-zVw1kaXPV9gHaoS8QUg.js:3:71535

Are there plans for making it completely CSP compatible, ie. without using the `data:` source?
If yes, do you have an issue created for it?
If no, can you provide a justification on that please?

@sudhanshu.b
That policy violation would occur when svg images are inlined on the page through a data uri, without it being allowed by the policy: e.g. HTML <img src="data:image/svg+xml,[...]">, or a CSS url('data:image/svg+xml;[...]').
The default policy proposed here does not include an img-src directive that would raise that violation.

The options that would work without requiring img-src data: in the CSP policy are:
- Including the SVG from an external source: <img src="/sites/default/files/image.svg">
- Inlining the full SVG markup in HTML, if the SVG is know to be from a safe source. However this will be less safe for dynamic image sources than allowing data: because embedded SVG elements can include scripts that will be executed in the page context, while <img src="data:[...]"> will have JS disabled.