Description
Motivation
wasm-bindgen and its associated crates (js_sys
, web_sys
, etc.) should be compatible with normal CSP configurations, i.e. ones that don't whitelist unsafe-eval
or unsafe-inline. Right now, it is too easy to accidentally to accidentally make a wasm-bindgen-based crate incompatible with good CSP practices. Further, it is hard to audit the internal implementation of wasm-bindgen and its associated crates for CSP problems. See #1641 for example.
Proposed Solution
Create an unsafe-eval
Cargo feature that controls access to the Function
constructor, eval, and other features that result in JS that would require unsafe-eval
. The feature shouldn't be marked as a default feature so that one can easily audit a depending crate's Cargo.toml to see if these features are in use. Instead, bump to the next incompatible version number since this is not a backward-compatible change. Test in CI the default configuration and the configuration with the unsafe-eval
feature enabled. Change the implementation of as many APIs as possible to work in the default (non-unsafe-eval
configuration, e.g. web_sys::window()
. This may require such APIs to be redesigned.
Activity
Pauan commentedon Jul 8, 2019
That doesn't work, because it's possible for any library to enable the feature. So you have to check the
Cargo.toml
of the crate, and all of its dependencies, and all of its transitive dependencies.In addition, this is trickier than it may seem, because there are quite a few APIs which have implicit eval behavior, and they need to be carefully blacklisted manually (e.g.
set_timeout_with_str
)In addition, it's always possible for a crate to use
inline_js
(or import amodule
) to do eval, so a feature doesn't actually help.Personally, I would be in favor of getting rid of all of the eval things completely. There's very very few legitimate uses for eval, and it's always possible to use
inline_js
if you really truly need eval.