CSP compliance

[derekkramer]

Problem

The __insertCSS method for pure CSS file imports isn't compliant with most
content security policies. This makes projects bundled with Bunchee only viable
with a style-src setting of 'unsafe-inline' or 'unsafe-hashes', or if
they remove their content security policy entirely.

Proposed Solution

The Bunchee CLI could be enhanced with an optional --nonce-header argument
passed to inlineCss and templated into the raw __insertCSS function. If
set, the code would be enhanced to pull the nonce value from the header and
inject it as an attribute to the inline'd <style> tag.

Example

If a user has configured a x-nonce header:

x-nonce "d1QZa9hkpPFwAMy3DPeizWDrdiJxKFwAv9YejVkccA4"

And specifies a header of x-nonce in their CLI build command:

bunchee --runtime node --nonce-header x-nonce -o ./dist/bundle.js

The existing inlineCss function would be modified to recieve the variable
and add calls to the cssImport.global payload:

let nonce = headers.get("x-nonce");
// ...
style.nonce = nonce

This would make Bunchee bundles more viable by allowing users to keep a content
security policy iwth a style-src setting of "nonce-<nonce_value>".
This feature would be superficial and purely additive and implementation of
the CSP nonce would be responsibility of the user.

I am open to tackling this feature and opening a pull request after receiving
approval to proceed in this request.

[huozhi]

Want to understand the whole process:
How would you expect to generate those CSP header? Will they become different hash in each version? That feels increasing the difficulty while integrating the package to your application.

[derekkramer]

@huozhi I think we rely entirely on the user for CSP generation and validation. Ideally we'd either pass a global variable to the Bunchee build or predetermine a global variable that would be checked at the inlineCss or __insertCSS call to check (pre-populated with the nonce hash) and adjust the __insertCSS call to be the following:

const helpers = {
  cssImport: {
    // have to assign r.type = 'text/css' to make it work in Safari
    global: `\
function __insertCSS(code) {
  if (!code || typeof document == 'undefined') return
  let head = document.head || document.getElementsByTagName('head')[0]
  let style = document.createElement('style')
  if (window.styleNonce) {
    style.nonce = window.styleNonce
  }
  style.type = 'text/css'
  head.appendChild(style)
  ;style.styleSheet ? (style.styleSheet.cssText = code) : style.appendChild(document.createTextNode(code))
}
`,
  // ...
} as const

I think the method by which we pass it is subjective, or if we enable or disable the check by CLI variable. But I'm curious to hear your thoughts.

[huozhi]

It's more about how will use create the nonce value itself:

• If you use a fixed string then it's still not 100% secure.
• If you're generating a dynamic string for each build / version, it will also be hard to track which one to integrate to the app.

window.styleNonce feels like would be used by any script, then could still lead to insecure injection? I believe we want to have a more common practice for everyone to adopt

[derekkramer]

You're right that unless you could guarantee the Bunchee package loading prior, this would be subject to injection attack.

I think this may only be solved by a plugin upstream at the Rollup plugin level or if the user of Bunchee chose to import() scripts within some Rollup entrypoint and inject the server-side nonce themselves.