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.

[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.

[aSeriousDeveloper]

FYI, Alpine JS now supports unsafe-eval a little more! alpinejs/alpine#4671

Additionally, Livewire has a merged PR (but not released yet) that also implements these new changes: livewire/livewire#9461

I imagine making Filament support this csp-safe mode might require some changes to Alpine calls throughout the codebase, but it should be an option soon at least.

[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?

[aSeriousDeveloper]

FYI, Alpine JS now supports unsafe-eval a little more! alpinejs/alpine#4671

Additionally, Livewire has a merged PR (but not released yet) that also implements these new changes: livewire/livewire#9461

I imagine making Filament support this csp-safe mode might require some changes to Alpine calls throughout the codebase, but it should be an option soon at least.

EDIT: whoops, sorry severfire, replied to the wrong comment :z

[pixagraphic]

I agree, we really need CSP using nonces to work with filament. :(

[kbhnarola]

Is there any solution? facing the same error.

[CicerBro]

I always added all the hashes for Filament into my CSP policy, but now on every freaking page load the hash seems to change? How is that even possible?

[CicerBro]

If anyone wants the "solution". I use Filament just for my admin panel, and I also use Spatie/Csp in Laravel for handling CSP.

So in my custom CSPPolicy.php I just did this:

    protected function shouldOverrideScriptDirective(): bool
    {
        $overridePaths = [
            'admin',
            'admin/*',
            'horizon',
            'horizon/*',
        ];

        foreach ($overridePaths as $pattern) {
            if (request()->is($pattern)) {
                return true;
            }
        }

        return false;
    }

And then in the configure method:

if ($this->shouldOverrideScriptDirective()) {
            // Override script directive for specific paths
            $policy->add(blabla);
} else {
            // Normal script directive for all other paths
            $policy->add(blabla);
}

        // Continue with other directives outside if/else
        $policy->add(Directive::FRAME etc. etc.

[4513]

Is there actually any update? The Livewire has the 'CSP-safe' feature merged and published a while ago. It's config to enable the CSP so you should not longer need unsafe-eval (as stated in https://livewire.laravel.com/docs/4.x/csp)

The only problem I now see is the Filament itself.

(Probably) every reported error leads to Filemant's blades, such as vendor/filament/filament/resources/views/components/theme-switcher/index.blade.php

[danharrin]

There's no update on our side, you can help by submitting PRs to make more of our JS CSP-safe though.

[4513]

@danharrin I am willing to help and implement the feature. But I must note, that I am not sure about how much time I can spend in near future to doing so. Anyway, the implementation would consist of several steps because it may, and I believe that it will, impact both, multiple existing features of the filament and filament parties (filament-plugin developers, filament developers, optionally filament users).

Are you fine about me creating a WIP PR for this, so you and others may all react to the changes and suggest ones? Or is there another preferred way doing so?

Some (if not all) points I will focus on step by step:

• initializing filament with CSP
  • add a Filament PHP API to set nonce for current request - this is similar to CSP implementation of Vite, Livewire; this should mainly be for filament-user
  • add a Filament PHP API to render a CSP nonce for script and style HTML elements - this is very important for everybody creating blade templates and may impact filament-user if creating own templates; should impact filament-plugin-developer if introducing templates with styles/scripts
• current style/script elements update
  • adding CSP nonces to all existing filament style and script elements
• simple inlines to elements
  • transform current filament's inline styles and scripts into own style/script elements with the available CSP
• livewire/alpine's custom element' data attributes
  • some attributes currently are written in a way the CSP has problem with that. It usually contains script. The point is to rewrite that attribute's value into separated script element.
• AJAX expecting CSP
  • FIlament may request backend to return a new HTML (e.g. error page on an action). Because the new HTML is not aware of the CSP nonce, it renders with different one, making any styles and scripts of the new HTML being blocked. Not sure right now whether the Livewire has that solved.
  • point of this is to add a CSP-aware property to request body (such as in POST /livewire/update by intercepting) saying what CSP nonce can be parsed. I will have to think a bit more and that part tho, because it might be tricky.
• CSP check TestCase for developers?
  • I will try to create a test case for a developer (mainly filament dev and filament-plugin dev) that would check that all templates are CSP compliant
• filament documentation
  • update docs for filament-users how to set up filament to comply CSP
  • update docs for developers how to set their plugins CSP compliant and how to test that. That includes how to add CSP nonces to their styles and scripts

I will try to test as much as I can, but honestly, another hand will be really helpful then.

[danharrin]

I will note that I don't think Livewire / Alpine / TipTap etc have support for CSP that prevents inline styles. In the Livewire example CSP config, there is style-src 'self' 'unsafe-inline'.

So yes, I would accept a WIP PR to start adding CSP support. It will need to be opt-in.