useScript compatibility with CSP

[vejja]

Hi all

useScript is an absolutely fantastic way to embed 3rd-party external scripts in a Nuxt application.

I'm opening this discussion as a contributor to the Nuxt-Security module. We try to contribute to safer Nuxt applications by allowing users to deploy their websites with Strict CSP (Content Security Policy).

CSP Limitations

One thing that gets in our way with useScript is the fact that it inserts onload inline event handlers, as in : https://github.com/unjs/unhead/blob/main/packages/unhead/src/plugins/eventHandlers.ts#L12

CSP disallows the insertion of inline event handlers, as explained in MDN docs on CSP

Description of Issue

As a result, when enforcing Strict CSP on a website, the onload event managed by useScript is blocked :

One way to get around this is to allow unsafe-hashes on the script-src-attr directive, but it is both unsafe (as its name implies), and unpractical (as it requires hashing of all legit inline code at build time).

Please note that the other suggestion provided by the error message (which is to use a nonce) is not applicable on the client side. Only servers can insert nonces, which de facto prevents hybrid frameworks to implement this solution.

Proposal

A better way to solve this issue would be to follow up MDN's recommendation, which is to replace inline event handlers with addEventListener calls.

For the sake of clarity, I'm copying below the relevant part of the MDN site :

I am wondering whether it would be possible to modify the existing unhead code that inserts inline event handlers into the DOM with addEventListener bindings on the script tags ?

I am not fully able to assess whether this would be feasible, hence opening the discussion here.

Happy to answer any questions about why this would be desirable from a CSP perspective and the technical limitations imposed by CSP on inline scripts.

Cheers

[harlan-zw]

Hi @vejja, thank you for opening this discussion.

I think moving to addEventListener should be possible, it will add extra weight to the page and will require exposing some globals though. I'll try and investigate further when I have a chance

[vejja]

Thanks @harlan-zw for your answer.

From my perspective I can see that you are inserting this.dataset.onload = true on the onload inline event handler of the script. This is the only line of code that gets blocked by CSP, the rest is fine (i.e. modifying the data-xxx attributes is perfectly OK for CSP).

As for the extra weight and globals, this is obviously an issue. Do you think that having a simple option to deactivate the insertion of the inline event handlers would be an issue? In a Nuxt world, maybe it could then become my own responsibility to bind addEventListener to the script onload event via a Vue template ref. Not sure it would work though, what do you think?

Let me know if I can help, I can try to contribute but will need a little bit of guidance.

[vejja]

@harlan-zw : FYI I managed to get a POC running of what I had in mind
The POC is based on Cloudflare Turnstile with Strict CSP

• An example of CSP rejecting the inline event handlers: https://stackblitz.com/edit/nuxt-starter-d1f3pg?file=app.vue
  You can see that the Captcha is not loaded, and the console says that CSP rejected the inline event handler

• A POC with CSP passing with addEventListener : https://stackblitz.com/edit/nuxt-starter-fa6ach?file=app.vue
  You can see that the Captcha loads correctly. The addEventListener was correctly bound to the script tag. I was not able to remove the inline event handler so the event is being observed twice: once via inline handler (blocked by CSP) and once via addEventListener (CSP happy).

Both examples are structured exactly the same way:

1- A turnstile.ts plugin uses useScript to load the 3rd party script; it leverages useScript's use() method to extract Cloudflare Turnstile methods such as render. It's a good example because the script takes a long time to load, so we fall exactly in the situation where use() is fantastic DX: no need to worry about whether the script is already loaded or not !

2- A turnstile.vue component that renders the Captcha. Once again, very nice to work with useScript : I can call render without worrying about if the window.turnstile global is populated and ready.

The POC is extremely hacky and probably not stable at all but it works. What I had to do is:
1- use the dom:renderTag hook to find the <script> tag by id
2- add addEventListener to it before the document is loaded
3- modify manually the data-onload attribute to signal the script has finished loading
4- force client mode on the plugin otherwise it would not work

I tried to get rid of the onload inline handler completely to suppress the console warning by using the transform() method of useScript but then it doesn't work anymore.
So it looks like my suggestion of just deactivating the insertion of the inline event handlers is not going to work that simply.

However I do believe we could be very close to a solution. I was able to make it 'kind of work' without any change to the codebase, the only annoyance being the console error message about the inline event handler being rejected.

[harlan-zw]

Since you had a decent chance to play around with the composable, I was wondering if you had any further feedback or ideas for improving the security @vejja?

We're looking to do an announcement and publish Nuxt Scripts soon so looking to sort out any final breaking changes

[vejja]

On security, honestly no. I love the interface of useScript and I think it is brilliant. You have crossorigin, nonce and integrity baked in so I can't think of any missing piece from my perspective.

One thing that I think would be even fancier is if I could use it directly in defineNuxtConfig app-wide, the same way I can use the app.head entry in nuxt.config.ts instead of using the useHead composable. It would allow me to avoid writing a plugin for each injected script. I'm not too sure if this could be implemented, because with my turnstile plugin I am able to extract the turnstile methods render, remove and reset to inject them globally in the useNuxtApp provider, whereas with defineNuxtConfig I can't really see how this could work. But definitely something that comes to mind once you start using useScript.

[harlan-zw]

This was planned for the original release but we got a bit tied up on what third parties to support. Most likely will be dropped for the initial release.

The implementation is powered by composables though, so you register the global component such as:

export default defineNuxtConfig({
  scripts: {
    globals: {
      // will load the script globally
      cloudflareTurnstile: {
        apiKey: ''
      }
    }
  }
})

Then to access it you would use the composable in any part of your app

const { $script, render } = useCloudflareTurnstile()
// etc

[vejja]

No worries, it's wonderful already. Will look at the composable syntax !
Thanks

[vejja]

Can't stop thinking about this 😊😊😊
What about a syntax in the like of:

export default defineNuxtConfig({
  scripts: {
    turnstile: [
      // Params at 1st position
      {
         src: 'https://challenges.cloudflare.com/turnstile/v0/api.js?render=explicit',
      },
      // Options at 2nd position
      {
        trigger: 'idle', // This could be the default
        use: () => window.turnstile // This could also be the default, based on the 'turnstile' key used above
      }
    ]
  }
})

And then anywhere in the application:

const { turnstile } = useNuxtScripts() // Or maybe useNuxtApp().scripts ?
const { render, remove, reset, $script } = turnstile
// Et voilà !

And going one step further, assuming idle and window[key] can indeed be used as reasonable defaults, the nuxt.config.ts entry could even be simplified to:

export default defineNuxtConfig({
  scripts: {
    // String type instead of array type sets default options and params
    turnstile: 'https://challenges.cloudflare.com/turnstile/v0/api.js?render=explicit'
  }
})

Wouldn't it work universally now with scripts gta and Stripe for instance ?
As long as the user uses a key name for the script which is the name of the global that the script injects ?

[vejja]

idle means the script won't be loaded until the requestIdleCallback hook is called

Ok, thanks

[harlan-zw]

I noticed the docs were a bit lacking there, have pushed up some improvements.

[vejja]

Hi @harlan-zw
Just noticed you removed the idle option.
What value do you recommend if I want client-side only insertion of the <script> tag ?
Should I specify trigger: undefined or can I omit the trigger option altogether ?
And in the latter case, can I be sure that the <script> tag won't be inserted by the server-side ?
Thanks !

[vejja]

Hey @harlan-zw
Noticed your changes in v1.9.4 that make { trigger: 'client' } the default now - so clear on my end, please disregard my previous question, and many thanks for this new feature which makes useScript even easier to use.

Some additional questions though for clarification purposes:

• use : I understand use only works client-side and noops in the server. But if I have { trigger: 'server' }, will it still work in the client ? (I assume yes, but checking)
• stub : I understand stub works in both the client and the server. If called on server will execute the code, but if called on client will fallback to the Real API. Does it mean that in the client it will always be replaced by use ? I'm asking because your example code has an if (process.server) check so I'm wondering if I don't include that check, will it still fallback to use ? And what happens if the user does not set use ?
• { trigger: 'server' } : I understand that this ensures that the <script> tag is inserted by the server in the HTML that it produces, but does this also commands loading the script on the server ? In other words, are script insertion by server and script execution by server 2 different concepts or is it the same thing ? For instance, can I set { trigger: 'client' } so that the script tag is not inserted in the HTML, but still use stub in the server environment ?

Apologies if my questions are confused (and maybe make no sense in real life), but just trying to make sure I don't mislead our users into a wrong implementation.
Many thanks again !