Remove `unsafe-eval` CSP Requirement for Blazor WASM
TanayParikh opened this issue · 19 comments
Runtime made the necessary changes that unsafe-eval may no longer be required for Blazor WASM: dotnet/runtime#59416
Note, there's also a Chrome bug which may come into play here (WebAssembly/content-security-policy#7)
This issue tracks validating this fix, and the associated documentation updates.
Original CSP Issue: #34428
Unfortunately this is still an issue due to the Chrome bug:
This resource helps detect if the chrome issue is resolved (WASM related, not blazor specific): https://s3.amazonaws.com/webassembly-chrome-csp/csp_test.html
Others are having the same issue as well: element-hq/element-web#12262
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
@TanayParikh based on my testing with dotnet.7.0.0-preview.3.22175.4 the runtime still requires unsafe-eval, mainly due to the evaluation of string in the following line:
The original issue was closed and locked so I am hoping you might be able to reopen it.
original issue
Can you please provide a link.
I was referring to the issue that you have created and linked to from here.
dotnet/runtime#59416 Make mono CSP Compliant
Ah so it's over on the runtime repo. Thanks for clarifying. Please open up a new issue with the line you pointed out, on dotnet/runtime, and crosslink dotnet/runtime#59416 and #37787.
We should re-check if this is still the case. Since this issue was posted, Chromium has added support for a new CSP flag, wasm-unsafe-eval, which is intended for this case. It might now be possible to run without unsafe-eval, by adding wasm-unsafe-eval instead: https://chromestatus.com/feature/5499765773041664
Unfortunately wasm-unsafe-eval doesn't look to be sufficient in this case:
It's calling out https://github.com/dotnet/runtime/blob/637f8f241146e467d6a603394d63ff716838c0c6/src/mono/wasm/runtime/method-binding.ts#L81-L115 specifically.
cc/ @radical any ideas what may be going wrong here?
If the wasm-unsafe-eval source keyword is used, and the unsafe-eval keyword is not present, then WebAssembly modules may be compiled and instantiated.
One advantage of this is that a website can permit WebAssembly modules to be used without also enabling JavaScript's eval keyword.
IIUC, this means that wasm-unsafe-eval will allow WebAssembly.compile, and friends to work, but not the general eval in JS. Do correct me if I'm wrong. So, then the situation is unchanged.
Yes, we need to get rid of eval in the JS code first. Also see dotnet/runtime#68374
I was looking into this case also. Maybe relevant is recent discussion regarding WASM loading in extensions and v3 manifest at https://bugs.chromium.org/p/chromium/issues/detail?id=1318922 (made this comment also in the previously linked thread, found it first).
I'm also wanting to use Blazor in a chrome extension but this is blocking me.
I'm also wanting to use Blazor in a chrome extension but this is blocking me.
Same here.
Blazor in Net7 is using legacy JavaScript interop, which is not CSP safe. We need to migrate Blazor to use the new JS interop with [JSImportAttribute] to make it CSP friendly.
Thanks for contacting us.
We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Just to show that its not a rare or low-impact issue. This issue is 100% blocking me from using Blazor in new projects. My company has a security requirement on things going into production that disallows us from using unsafe-eval.
Just to show that its not a rare or low-impact issue.
I second that.
we need this fixed asap, cannot realistically use blazor wasm without this.
EDIT: Is this available as part of .net 8 preview?
I need to point out that this is a very important thing to fix in order for Blazor to be considered mature.
Specifically, "eval()" in Javascript is considered insecure, but Blazor essentially runs via "eval()."
It's quite critical to fix this, in the long-term, for a Blazor-powered site to be considered safe from XSS attacks.