Add nonce- to our CSP policy to allow inlining bootstrap.js inside the application document

[pgayvallet]

In #92784, we migrated the /bootstrap.js endpoint from legacy to core.

The /bootstrap.js endpoint is now an unnecessary request, as we are technically able to inline this script in the application's document generated by the rendering service. However, our CSP policy currently forbid that, as we are legitimately disabling unsafe-inline by default.

Ideally, we would generate a nonce- id for each application request, and use it in the rendering service to add the nonce attribute to scripts we need to inline.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[jportner]

Is there any reason we couldn't use a hash of the script instead of generating a new nonce with each request? Seems that it will accomplish what we want and it will be easier to implement.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

[legrego]

I'm not opposed to exploring the hash approach if that's viable. My one reservation is that it won't scale very well: while I don't expect to have a ton of these, there are at least 2 JavaScript assets within the security plugin that could benefit from the nonce approach too.

[pgayvallet]

Is there any reason we couldn't use a hash of the script instead of generating a new nonce with each request

AFAIK not really, we could definitely use a hash-based nonce for the specific bootstrap.js need.

Note that I'm not sure this is really better, as we would have to expose an API inside core to allow addition of such nonce- when serving document requests, which doesn't necessarily sound more secure that a per-request generated value?

Also, as @legrego said, this seems way less generic and re-usable (even if I'm not well aware of what exactly the security plugin would like to leverage the inline scripts for)

[jportner]

AFAIK not really, we could definitely use a hash-based nonce for the specific bootstrap.js need.

Note that I'm not sure this is really better, as we would have to expose an API inside core to allow addition of such nonce- when serving document requests, which doesn't necessarily sound more secure that a per-request generated value?

I was suggesting using a hash instead of a nonce, not a hash-based nonce. As described in the linked MDN page:

'<hash-algorithm>-<base64-value>'
A sha256, sha384 or sha512 hash of scripts or styles. The use of this source consists of two portions separated by a dash: the encryption algorithm used to create the hash and the base64-encoded hash of the script or style. When generating the hash, don't include the <script> or <style> tags and note that capitalization and whitespace matter, including leading or trailing whitespace. See unsafe inline script for an example. In CSP 2.0, this applied only to inline scripts. CSP 3.0 allows it in the case of script-src for external scripts.

If you use a nonce, the HTTP server has to calculate a new nonce for every single request and expose that for consumers (in this case the RenderingService) to insert it where the script is inlined.

With the hashing approach, consumers can independently define hashes for the scripts that need to be inlined, and register those hashes with the HTTP server so that they can be included in the CSP response. The hash only needs to be generated and registered once for static content such as the bootstrap script.

[pgayvallet]

With the hashing approach, consumers can independently define hashes for the scripts that need to be inlined, and register those hashes with the HTTP server so that they can be included in the CSP response. The hash only needs to be generated and registered once for static content such as the bootstrap script

The bootstrap script is not static though, as it depends on values of uiSettings that can be changed by the end users, so this assertion is unfortunately wrong.

[jportner]

The bootstrap script is not static though, as it depends on values of uiSettings that can be changed by the end users, so this assertion is unfortunately wrong.

Ah, thanks for clarifying. Maybe a Kibana-wide nonce would be easier, then!