peerjs needs Content-Security-Policy script-src: unsafe-eval

[andreialecu]

Please, check for existing issues to avoid duplicates.

• No similar issues found.

What happened?

Because of the dependency on cbor-x, which does this check, the page where peerjs is used requires a CSP of script-src: unsafe-eval, which is extremely unrecommended.

The fix here would be to use one of the *-no-eval exports: https://github.com/kriszyp/cbor-x/blob/0b5e8807622619c6a7a062f7e771478ecfd52f83/package.json#L58-L59

Meaning that this line:

peerjs/lib/dataconnection/StreamConnection/Cbor.ts

Line 2 in 708c55c

import { Decoder, Encoder } from "cbor-x";

Should probably be:

import { Decoder, Encoder } from "cbor-x/index-no-eval";

How can we reproduce the issue?

Add an HTTP header of:
Content-Security-Policy-Report-Only: script-src 'self' and notice that unsafe-eval is required on this line:
https://github.com/kriszyp/cbor-x/blob/0b5e8807622619c6a7a062f7e771478ecfd52f83/decode.js#L37-L44

What do you expected to happen?

unsafe-eval should not be required. CSP error should not appear.

This will also spam the reporting endpoint with CSP errors, if one is set up.

Environment setup

• OS:
• Platform:
• Browser:

Is this a regression?

No response

Anything else?

No response

[jonasgloning]

Hey Andrei, thank you for the bug report!

We agree this is a bug. PeerJS shouldn’t be relying on unsafe-eval.

Sadly this appears to be a bit more complicated than your proposed fix in our case:
The current bundling/typescript setup doesn’t allow for importing from a package export yet. We’ll hopefully address this soon, but this could explode in complexity and will take some time.

[andreialecu]

kriszyp/cbor-x#102 got merged, I believe the types should behave better now.

[jonasgloning]

There's a new version on @rc https://www.npmjs.com/package/peerjs/v/1.5.3-rc.1 that includes a fix (#1248). You can install it with npm i --save peerjs@rc

Import paths still break some bundler implementations we test against — one of the reasons for the large delay.
We decided to still merge the PR. Projects affected should (and can) just update their tooling.

The team will meet again and release a new stable version on Saturday, 11th of May.