drupalSettings.csp.nonce is missing

Now I'm a little baffled at how it was working while I was implementing the google_tag integration 😵‍💫.

The MR looks good from stepping through the before/after behaviour on a new site install.
I'm currently trying to get a couple functional tests running so that I can confirm the bug&fix that way (and keep it fixed 😉) .

I'm currently thinking that a different approach is needed. From what I currently understand:
- HtmlResponseSubscriber renders markup placeholders which may add additional asset libraries to the response from bubbled metadata (HtmlResponseAttachmentsProcessor::processAttachments), so CSP's subscriber needs to still execute afterwards in order to properly modify directives for any libraries on the page.
- drupalSettings.csp.nonce needs to be set prior to HtmlResponseSubscriber in order for the value to be properly inserted into the scripts_bottom placeholder. This means it can't conditionally set the nonce based on the header value, or the page's complete set of libraries, since the information is not available/complete. This includes checking Nonce::hasValue(), since a module may only call Nonce::getValue() during the policy alter event 😵‍💫.

If the nonce value is always added to drupalSettings, it's not necessarily bad, but it would be mean that JavaScript can't assume that the nonce is actually allowed via the header. I'm not sure if this will matter, as long as the corresponding module properly sets a domain source or 'unsafe-inline' as a fallback as needed.

I'm not sure if this will matter, as long as the corresponding module properly sets a domain source or 'unsafe-inline' as a fallback as needed.

I'm not sure what you mean here. Am I doing it right in the Gin MR? Or should I use fallbackAwareAppendIfEnabled and leave out 'self'?

I really need to write out a couple documentation pages, 'cause collaborating well with what other modules might potentially do (especially with nonces) is still pretty messy. I understand my use of "fallback" may also be confusing, because there is fallback for whole directives (use default-src if script-src is not provided), but also within directives (if a nonce can't be used, then another authorizing source needs to be added to the directive, such as 'unsafe-inline' or an external domain).

• As I understand, Gin only inserts a new inline script element onto the page, so 'self' isn't necessary - 'self' is to allow the page to load additional CSS files from the same domain as the page.
• fallbackAwareAppendIfEnabled() is generally the best method to alter a policy. I assume in most cases a site will have a script-src directive, but this method handles copying the value from default-src in the case that it doesn't so that it's properly overridden.
• script-src-elem should also be altered, otherwise if present it will override script-src without the necessary additions (Safari is currently the only browser that doesn't yet handle -elem and -attr directives).
• Now, coordinating a nonce and 'unsafe-inline' is where it gets messy, because adding a nonce disables 'unsafe-inline'
  • If a module requires 'unsafe-inline' (and can't use a nonce or hash), then it should prioritize its handler so that it's applied early and other module can work around its needs
  • If a module can use a nonce (or hash), it needs to check that the relevant directives don't already have 'unsafe-inline' (without also a nonce or hash that would disable it), so that it doesn't break another module that requires it.
  • If the directive requires 'unsafe-inline' (it's present on the directive and there's no nonce or hash that would disable it), a nonce should not be added to the directive. For Gin, since 'unsafe-inline' is already present, it doesn't need to also add it to the directive. (other modules may need to add external domains, for example).
  • If 'unsafe-inline' isn't present (or is disabled by another nonce or hash), then the module should add the nonce value. (It can add 'unsafe-inline as well for completeness or clarity, but there aren't any supported browsers that don't understand nonces and would require it for backwards compatibility)

There were some DX ideas that would allow CSP to handle more of the coordination in 🌱 Better CSP support for themes Active , but some other ideas are ✨ Enable conditional/alternate directive values Active , #3251172: Add utility methods for adding CSP information → , and ✨ Create script-src from script-src-attr and script-src-elem Active .
I'm thinking that fallbackAwareAppendNonce() from the MR on google_tag ✨ Support Content Security Policy nonce Active is probably also worth adding to CSP so that Gin and other modules can use it, since it handles most of the safely checking for 'unsafe-inline' logic.

gapple → changed the visibility of the branch 3409450-drupalsettings.csp.nonce-is-missing to hidden.

My MR should be functional now, but a small downside is that it's always adding the drupal settings loader script even when not needed by the page, which will have a small effect on responses for anonymous users on sites that don't ever use nonces.
I think it should be fine for CSP to not always add the csp/nonce library to the page, and any module that requires it will have to add it as a dependency. (and conversely, for the setting to be added to pages that don't have a library with csp/nonce as a dependency, since it's minimal overhead).

I just need to change the functional test so that it's actually testing for the nonce value based on the presence of csp/nonce on the page, and not just as a side-effect of other modules adding the drupal settings loader to the page for authenticated users.

So maybe a weird test now - Drupal 9 appears to add something that depends on core/drupalSettings by default while Drupal 10 doesn't - so D9 doesn't really test that the setting is available based on csp/nonce.

Whatever, it's fine...

gapple → closed merge request !22

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