When the directives "script-src-elem" and "style-src-elem" directives are disabled, they are still added to the CSP header.

This is caused by the LibraryPolicyBuilder->getLibrarySources() function in combination with the implementation in ResponseCspSubscriber->onKernelResponse() function.
The getLibrarySources adds the detected hosts for each directive for both the "with elem" and "without elem" version of the directive.
The Response Subscriber just takes all returned directive keys and adds them to the policy. As a result you now have the "with elem" versions even though you had them disabled in the config.

Comments

paulvandenburg created an issue. See original summary.

paulvandenburg’s picture

Status: Active » Needs review
StatusFileSize
new1.21 KB

This patch fixes the issue by adding an extra check if the directive is enabled before adding the results of the getLibrarySources function to the policy.

askibinski’s picture

Status: Needs review » Reviewed & tested by the community

Patch looks good and works as advertised.

This patch together with the one mentioned in #3, fixes "script-src-elem" and "style-src-elem" console log errors in browsers which do not support these Level 3 directives yet.

  • gapple committed 8bfc26e on 8.x-1.x
    Issue #3030488 by gapple, paulvandenburg: Disabled directives are still...
gapple’s picture

Title: Disabled script-src-elem and style-src-elem directives are still added to the header » Disabled directives are still added to the header by library sources
Status: Reviewed & tested by the community » Fixed

Thank you for the bug report and patch.

I made a bit of a different code change to only add library sources for enabled directives, and added corresponding tests for sources provided from a library.

Since this fixes a bug in the 8.x-1.3 release, I'll be publishing a 8.x-1.4 release shortly.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

gapple’s picture

The *-attr and *-elem directives shouldn't be disabled just to silence the console messages.
If you do not require 'unsafe-inline' for any inline script elements, restricting it to only script-src-attr (for ckeditor to work) will significantly improve CSP's ability to protect against XSS compared to only using script-src.
Chrome now supports these new directives with a feature flag so it is possible to test that they are configured correctly, and warnings in other browsers about unsupported directives can be safely ignored.

dgroene’s picture

This is not fixed- still experiencing script-src-elem and style-src-elem being added even though they are unchecked/disabled. I want these to not be included and to inherit from script-src and style-src. The fact that these redundant directives are added actually creates an exception on the server due to the size of the header.
It looks like this patch worked at one time, but the module has undergone a lot of refactoring since then.

gapple’s picture

@dgroene would you mind opening a new issue with some details about your config, and any modules that implement a policy subscriber?

The LibraryCspSubscriber uses fallbackAwareAppendIfEnabled() to add its values, and Csp::getHeaderValue() does attempt to remove more specific directives if they match their fallback value to shorten the header.
You can force the removal of a directive by adding your own subscriber to CspEvents::POLICY_ALTER with a priority placing it after the CSP module's subscribers.