Make `mono` CSP Compliant

[mingyaulee]

In the effort to remove unsafe-eval CSP requirement from Blazor WASM, the mono runtime also needs to be CSP compliant by removing the need for unsafe-eval.

Although issue #59416 has been resolved, the runtime is still not CSP compliant, with the following lines requiring the unsafe-eval CSP:

runtime/src/mono/wasm/runtime/method-binding.ts

Line 113 in 14584c6

result = Function.apply(Function, keys);

runtime/src/mono/wasm/runtime/method-calls.ts

Line 631 in 0d889f5

const fn_defn = new Function("__closure", fn_body_template);

This might not be applicable since it is only for debugging:

runtime/src/mono/wasm/runtime/debug.ts

Line 216 in 0d889f5

const fn_defn = new Function("proxy", fn_body_template);

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In the effort to remove unsafe-eval CSP requirement from Blazor WASM, the mono runtime also needs to be CSP compliant by removing the need for unsafe-eval.

Although issue #59416 has been resolved, the runtime is still not CSP compliant, with the following lines requiring the unsafe-eval CSP:

runtime/src/mono/wasm/runtime/method-binding.ts

Line 113 in 14584c6

result = Function.apply(Function, keys);

runtime/src/mono/wasm/runtime/method-calls.ts

Line 631 in 0d889f5

const fn_defn = new Function("__closure", fn_body_template);

This might not be applicable since it is only for debugging:

runtime/src/mono/wasm/runtime/debug.ts

Line 216 in 0d889f5

const fn_defn = new Function("proxy", fn_body_template);

Author:	mingyaulee
Assignees:	-
Labels:	arch-wasm, untriaged, area-VM-meta-mono
Milestone:	-

[keesschollaart81]

Hi @pavelsavara I see you removed it from the 7.0 timeline after it being triaged and put on the roadmap quite recently. Out of curiosity (as this is quite an important feature for me), what is the story here, too complicated/much work?

[pavelsavara]

We are generating interop thunks (JS code for marshaling) on runtime, so we need to use new Function.
Also we plan to add new C# API wrapping JS new Function so that people could create JS functions.

We may be able to re-visit interop and generate it on compile time as part of AOT in the future.
We may also try to implement linker trimming to include JS code in the future, which would link-out usage of new Function if you didn't use it's API in your code.
Both of those things are non-trivial, realistically not doable in Net7 time frame.

Are there other ways how CSP compliance could be achieved ?

[mingyaulee]

This is very important for the browser extension development, since chrome is moving to manifest v3 and all the extensions has to be compliant. Generally, writing JavaScript code in string and executing is a bad idea in the first place and should be avoided at all cost. If this fix does not make it to .Net 7 release, no one would be able to develop new browser extensions using Blazor because the chrome web store will not accept it.

[keesschollaart81]

We host our (Blazor WASM) web app on a vendor-managed (static files) webserver. As per their security policy, with their latest version, they require the web apps to be CSP compliant: 'Industry standard security'. I guess this requirement will pop-up more and more?