Can't use with Content Security Policy

[ekilah]

Describe the bug

EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive:

Our site has a Content Security Policy preventing eval() from being used. Several dependencies of this project use eval(), here are PRs where people have tried to fix this there unsuccessfully:
fontkit: foliojs/fontkit#180
restructure: foliojs/restructure#29
yoga-layout: (see below)

One guy has forked those two ( https://github.com/Hopding/fontkit and https://github.com/Hopding/restructure , @Hopding ) to fix these issues because it seems like the maintainer of the originals is somewhat unresponsive to this issue.

I was able to work around this by replacing this repo's dependencies with @Hopding's forks, for instance:

"resolutions": {
    "restructure": "https://registry.yarnpkg.com/@pdf-lib/restructure/-/restructure-0.0.1.tgz#e38c81b6ddaa8c982e7780620c89bddfb6c53653"
  }

the above is the result of a manual process to link to the fork's product because of a bug in yarn (see yarnpkg/yarn#5235 ), something like "restructure": "https://github.com/Hopding/restructure#8af8c49f3a63681d90554be1600d1b381ff9114d" should work in theory.

However, it looks like after doing that, there is another dependency here that uses eval, and this time it's yoga-layout-prebuilt (a wrapper around yoga-layout). I can't seem to find any forks or issues on either of those repos that attempt to remove the eval there. Seems like a large repo, so I've hit a bit of a wall towards solving this myself.

error message for reference:

if I add unsafe-eval in my CSP, everything works.

Note: I know these are issues in dependencies, and not in this repo itself, but:

• Ideally this repo wouldn't have dependencies that cause issues like this for a relatively common CSP configuration
• This repo could potentially use forks of the dependencies that fix these issues
• I'm not sure where else to ask about / point out these issues, since they are somewhat widespread

To Reproduce
Have a CSP that is restrictive of script-src, i.e.:

<meta http-equiv="Content-Security-Policy" content="
...
script-src
      'self';
..
"/>

and then try to include this project.

Expected behavior
I can avoid using unsafe-eval and use this project

Desktop (please complete the following information):

• OS: Mac
• Browser Chrome
• @react-pdf/renderer 1.4.0

[diegomura]

Hey @ekilah !

Thanks for reporting this. I'm sorry to hear about this problem.

I would like to help you on this but I'm not sure if I can. Even if we fix fontkit and restructure (we are already using a fork for fontkit), yoga-layout is something that is way out of my control. yoga is originally written in C++ and compiled to asm.js using emscripten. So any eval call comes from there. I couldn't find a way of removing them, and I'm not sure if there's any at all.

I would be happy to solve this on the fontkit and restructure side, but only if there's a way of also fixing yoga-layout-prebuilt.

I'm keeping this open for awhile if you or someone else knows how to tackle that part, but until then I cannot do much.

My apologizes again

[ekilah]

@diegomura thanks for the reply. I agree, if it can't be fixed completely for my use-case, there's not much point beyond having a little more confidence in the dependencies from a security standpoint.

yoga-layout looks like a repo that doesn't get much attention from Facebook on GH issues. a little deeper look showed that all the evals in yoga-layout probably come from https://github.com/charto/nbind , the tool that helps them use C++ in JS, and it looks like (from a quick search, and an assumption) that eval is somewhat critical to that library's functionality... I may open an issue there but it will likely be a dead-end.

[diegomura]

Yes, you are right about where those evals come from. I hope opening an issue there will eventually has some effect on this. I once tried to translate Yoga to plain JS, with some success, but it was a crazy and time-consuming task. At the same time, it was very hard then to maintain. I know Yoga isn't the most maintained project out there, and the way of using it on JS adds lots of overhead (such as nbind and stuff), but it does it's job quite well and I just cannot maintain that much code alone 😅

[ekilah]

made an issue over at nbind: charto/nbind#128

[AgarwalShyam]

Hi Team,

We have also used the same @react-pdf/renderer package but getting the CSP issue in the chrome browser, is anybody has any update on this or any workaround?

Thanks & Regards,
Shyam Agarwal

[siemah]

Hi @AgarwalShyam and @ekilah,
You can allow 'unsafe-eval' and secure all the others CSP or maybe allow it only for one path such as /path/to/page, it is not the best solution but you can use it if you had to

[lukashoffmannhb]

Is there any solution for that? Unfortunately adding 'unsafe-eval' is no option for us.
We are having troubles with the Restructure package as well.

[Neneil94]

I get the 'unsafe-eval' error as well. I successfully integrated all forks, but finally I got the yoga lib error too.

[fredrikzkl]

Any updates on this?

[bangarangler]

Any updates on this? having Security Error: blob popping up and I assume it's with the Content-Security Policy but can't find a way to solve it. Thanks all ; )

[ekilah]

For those asking for updates, I can only say that we chose not to use react-pdf because of this issue (though it's not react-pdfs fault). allowing unsafe-eval was not an option for us.

Feel free to try and make more noise on this issue, which blocks fixing this for react-pdf: charto/nbind#128

We're using a different tech stack, outside of the React realm, to create PDFs for now.

[aiavci]

Is there no update for this?

[aiavci]

@ekilah

For those asking for updates, I can only say that we chose not to use react-pdf because of this issue (though it's not react-pdfs fault). allowing unsafe-eval was not an option for us.

Feel free to try and make more noise on this issue, which blocks fixing this for react-pdf: charto/nbind#128

We're using a different tech stack, outside of the React realm, to create PDFs for now.

Someone posted on Stackoverflow about an alternative library:
https://stackoverflow.com/questions/68557489/react-and-csp-evalerror-call-to-function-blocked-by-csp

[tomtom94]

We are still having the issue guys,
We are using maximum CSP in our company thanks to the csp-html-webpack-plugin module.
I am using version "@react-pdf/renderer": "^3.0.0" the latest one.

gtm.js?id=GTM-NMGWMT6:43 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-eval' 'nonce-6h3VpQSkDAW2Vbdo8aQ+xA==' https://fonts.googleapis.com https://www.googletagmanager.com https://*.fairandsmart.com https://fonts.gstatic.com https://www.kalixia.fr https://prismic.io https://html2canvas.hertzen.com https://*.googleapis.com https://*.doubleclick.net https://www.google.com https://yt3.ggpht.com https://bat.bing.com https://*.clarity.ms https://s.yimg.com https://sp.analytics.yahoo.com https://connect.facebook.net https://www.youtube.com https://tagmanager.google.com https://www.google-analytics.com https://ssl.google-analytics.com https://www.googleadservices.com 'nonce-tdevfEFHD0QhcCHimeJA8g==' 'nonce-/heKuctyDK1uzmYPuGFZGg=='". Either the 'unsafe-inline' keyword, a hash ('sha256-YyZCoITruEUkQHBE3s4m6U4CtX+GRl72258hDklpmS8='), or a nonce ('nonce-...') is required to enable inline execution.

f.aa @ gtm.js?id=GTM-NMGWMT6:43
f.ja @ gtm.js?id=GTM-NMGWMT6:42
f.X @ gtm.js?id=GTM-NMGWMT6:40
f.D @ gtm.js?id=GTM-NMGWMT6:38
f.write @ gtm.js?id=GTM-NMGWMT6:38
f @ gtm.js?id=GTM-NMGWMT6:45
e @ gtm.js?id=GTM-NMGWMT6:44
t.streams @ gtm.js?id=GTM-NMGWMT6:46
(anonymous) @ gtm.js?id=GTM-NMGWMT6:461
Zq @ gtm.js?id=GTM-NMGWMT6:278
c @ gtm.js?id=GTM-NMGWMT6:461
b @ gtm.js?id=GTM-NMGWMT6:461
ue @ gtm.js?id=GTM-NMGWMT6:112
e @ gtm.js?id=GTM-NMGWMT6:286
(anonymous) @ gtm.js?id=GTM-NMGWMT6:61
(anonymous) @ gtm.js?id=GTM-NMGWMT6:287
(anonymous) @ gtm.js?id=GTM-NMGWMT6:286
Yr @ gtm.js?id=GTM-NMGWMT6:288
gs @ gtm.js?id=GTM-NMGWMT6:292
Mt @ gtm.js?id=GTM-NMGWMT6:310
Pt @ gtm.js?id=GTM-NMGWMT6:315
Tt.b.push @ gtm.js?id=GTM-NMGWMT6:319
Jt @ gtm.js?id=GTM-NMGWMT6:309
Fu @ gtm.js?id=GTM-NMGWMT6:323
a @ gtm.js?id=GTM-NMGWMT6:410

It's clearly written

Either the 'unsafe-inline' keyword, a hash ('sha256-YyZCoITruEUkQHBE3s4m6U4CtX+GRl72258hDklpmS8='), or a nonce ('nonce-...') is required to enable inline execution.

You must give the option to add our own nonce-

[SailleshPawar]

@diegomura Is this issue being priortized, as it's open since long?
We were able to solve the long running pdf issues by this but kind of stuck now due to unsafe-eval in csp.
If you can give an update on this, I will really appreciate that so that our team can make the decision to move away to some other approach.
Thanks 😊

[w90]

Yeah, unsafe-eval is a big bummer :(
Is there a chance to get rid of it?

[SailleshPawar]

Yeah, unsafe-eval is a big bummer :( Is there a chance to get rid of it?

You already know the challenge is this issue
charto/nbind#128
All hard work gone in vain now 😢

[aiavci]

Would be great to see a way to resolve this without unsafe-eval!

If someone has a way to do this in mind, perhaps describe it in an issue and it can be contributed?

[CodeWitchBella]

IMO, the best way forward is still to port yoga off of nbind and towards something else, probably embind. But for that to happen you have to have a good way to maintain the thing - either upstreaming it to yoga (I don't know how active it is nowadays) or fork it and maintain that. Or maybe there already is a working fork? I did the porting part few years ago, but do not have time to bring it up to date, nor maintain it. The port itself is not the problem - that took maybe two days. The maintenance is.
But maybe that's not problem either since yoga is not getting any major updates anyway (like css grid)

[CodeWitchBella]

New development by @shuding: https://github.com/shuding/yoga-wasm-web

Yoga ported to wasm. Used by vercel, which might help on the maintenance front. I don't know if the bindings are compatible with official yoga build, but it's worth a look.

Now it's matter of figuring out, how to use this library in react-pdf. Main difference is that instantiation of wasm is async, so you need to somehow inject it to all the right places, which right now import it directly. I did all this for previous version, but I don't think that any of this is still portable to current react-pdf and it was always hacky anyway.

[jeetiss]

it should be fixed in the next release

pdfkit and restructure didn't have evals wor a while and i updated yoga-layout to version without eval too

[w90]

That's fantastic news! Looking forward to the next release! Thanks jeetiss!

[sailleshp]

Thank you so much for prioritising this fix ❤️❤️🥳🥳💯💯

[askasp]

Hey, I still have this issue.

Im using react-pdf/renderer 3.3.8 that has a dependency on react-pdf/layout 3.11.2 that again depends yoga-layout: 2.0.1

wasm-async-web.js:13 Uncaught (in promise) RuntimeError: Aborted(CompileError: WebAssembly.instantiate(): Refused to compile or instantiate WebAssembly module because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' https://*.hotjar.com 'unsafe-inline' blob:"). Build with -sASSERTIONS for more info.

Is it not a part of the release yet?

Adding a screenshot on where the file is located

[RDyego]

I'm using "wasm-unsafe-eval" instead "unsafe-eval" temporarily until "yoga-layout" dependency be resolved, but I'm unsure if it's safe to be used.

[sangit0]

Hi there, I'm still facing the issue with latest version. Have anyone found any solution without using wasm-unsafe-eval?