Allow for a nonce to be added to livewire and filament (inline) scripts to improve CSP security

[Roboroads]

Currently, while livewire supports it, there is no nonce support in filament admin. This makes that we have to add script 'unsafe-inline' to our CSP, which defeats the purpose of a CSP.

[danharrin]

I have no experience with this, so please PR as long as it doesn't hinder the maintainability of the framework.

[Roboroads]

Sure!

[ghost]

This is very much needed. Can't use Filament now due to all the inline stuff being blocked by a proper CSP.

See: https://content-security-policy.com/nonce/

[romansh]

Is there any plan to implement CSP compatibility?

[danharrin]

I do not have any plans at the moment, Livewire does not even support it yet AFAIK, only raw Alpine. And it would greatly decrease the developer experience for us.

[rossbearman]

@danharrin While Livewire doesn't support unsafe-eval, and is unlikely to in the future, it does support safe inlines by passing a nonce to @livewireScripts and @livewireStyles, since a PR back in 2020. This negates the requirement for unsafe-inline in the CSP.

@livewireScripts(['nonce' => $nonce])
@livewireStyles(['nonce' => $nonce])

It's now managed through FrontendAssets in Livewire.

It should be possible to remove the need for unsafe-inline in Filament if we were able to pass a nonce through to Livewire on every request and have it appended to any inline scripts or styles Filament uses on top (for example in assets.blade.php).

The biggest potential issue I see with it would be any plugins that currently inline scripts or styles would need to add support for it, or they'd be blocked if unsafe-inline was removed.

[romansh]

On top of being a maintenance nightmare, browser support for unsafe-hashes is relatively recent.

Due to 'caniuse' the unsafe-eval usage is less with 92.27%, when for unsafe-hashes it's 94.37%.

[rossbearman]

The unsafe-eval stats displayed on caniuse are bugged, they're instead showing the stats for wasm-unsafe-eval, which is much newer. unsafe-eval has been in the CSP spec since v1, so any browsers supporting CSP will respect it, and allowing unsafe-eval is the only way to use Livewire with a CSP, and that's unlikely to change.

unsafe-hashes was added in CSP v3, but the bigger issue is that you'd have to create a separate SHA-256 hash of every single style attribute and inline event handler used on a page (or that could be passed to the page during a Livewire update), and send those with the initial CSP header.

[rossbearman]

@danharrin This is what gets blocked on the default dashboard, once all <style> and <script> tags have nonces. Each of these that differ would need a SHA-256 hash sent with the initial header, along with a hash for anything that could later get inserted by a Livewire update.

Some of these could potentially be moved into inline <style> tags, or moved into the theme style sheet (scrollbar-gutter: stable on the sidebar for instance).

Resource pages have a few hundred, but I imagine a lot of that is just repetition of table rows or similar.

[danharrin]

The only thing we need inline styles for are to pass values (numbers, colors) into CSS props. Any alternatives, maybe ones to use attribute values within props?

[matthewdanepeavoy]

Full disclosure, very new to the topic of CSP's, but found something which might be helpful.

@danharrin - Looks like there are two different CSP directives for inline styles.

style-src: specifies valid sources for inline styles (<style>, ). These would be relatively easy to add a nonce too and go a long way towards securing inline <script> and <style> tags.

style-src-attr: This is specific only to style="" attributes.
@rossbearman did not have a directive for this set according to the error he showed, so it was defaulting to "style-src", which requires a nonce. Perhaps style-src-attr: 'self' would work instead?

A couple of potential options I see from this
Option 1:
Use style-src-attr to allow those few attributes, while requiring a nonce for any <style> and <script> tags.

Ex. 'Content-Security-Policy' => "style-src 'self' 'unsafe-eval' https://fonts.bunny.net 'nonce-adgjdkfgwkejgldfkjgwejg'; style-src-attr 'self'"

Option 2:
Move the attribute values to an inline <style> element (with nonce) as @rossbearman mentioned. This would remove the need for style-src-attr

Option 3
Set the css variables through JS. Using .setAttribute() will still trigger the block, but direct style modifying (ex. document.getElementById('1').style.background = 'red') won't.

Alpine already requires "script-src 'unsafe-eval'" so setAttribute might also be a solution.

[severfire]

Hi, I do have issue... that may be related...

I wonder how could i fix it? its on admin login page in JS console... :-/ could anyone help, please?