Summary

The current @dimforge/rapier3d-compat package requires 'unsafe-eval' in the Content-Security-Policy script-src directive due to the new Function() call generated by wasm-bindgen in the JS glue code.

This was fixed in wasm-bindgen 0.2.109 (PR #4910), which removed the new Function("return this") fallback entirely in favor of globalThis.

The current Cargo.lock pins wasm-bindgen at 0.2.100. Updating to 0.2.109+ and rebuilding would make @dimforge/rapier3d-compat compatible with strict CSP policies that only allow 'wasm-unsafe-eval' instead of 'unsafe-eval'.

The Problem

In rapier_wasm3d.js (line ~6024):

imports.wbg.__wbg_newnoargs_105ed471475aaf50 = function(arg0, arg1) {
    const ret = new Function(getStringFromWasm0(arg0, arg1));
    return addHeapObject(ret);
};

This triggers the following CSP violation:

Evaluating a string as JavaScript violates the following Content Security Policy directive
because 'unsafe-eval' is not an allowed source of script: "script-src 'self' 'wasm-unsafe-eval'"

Proposed Fix

Since the Cargo.toml likely specifies wasm-bindgen = "^0.2.x", the fix should be as simple as:

cargo update -p wasm-bindgen

Then rebuild and publish the npm packages.

Impact

This would allow applications using Rapier to deploy with a strict CSP like:

script-src 'self' 'wasm-unsafe-eval';

Instead of the current requirement:

script-src 'self' 'unsafe-eval';

The difference is significant — 'unsafe-eval' allows arbitrary eval() / new Function() calls (a major XSS vector), while 'wasm-unsafe-eval' only permits WebAssembly compilation.

References

• wasm-bindgen PR #4910: Remove new Function fallback (merged 2026-01-21, released in 0.2.109)
• wasm-bindgen #1641: js_sys::global uses eval
• wasm-bindgen #1647: Gate features requiring CSP unsafe-eval