Skip to content

Gate features requiring CSP unsafe-eval on a non-default Cargo feature #1647

Open
@briansmith

Description

@briansmith

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

Pauan commented on Jul 8, 2019

@Pauan
Contributor

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.

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 a module) 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.

added
help wantedWe could use some help fixing this issue!
js-sysIssues related to the `js-sys` crate
web-sysIssues related to the `web-sys` crate
and removed
enhancementNew feature or request
on Jul 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedWe could use some help fixing this issue!js-sysIssues related to the `js-sys` crateweb-sysIssues related to the `web-sys` crate

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @briansmith@alexcrichton@Pauan

        Issue actions

          Gate features requiring CSP `unsafe-eval` on a non-default Cargo feature · Issue #1647 · rustwasm/wasm-bindgen