Does the WebViewer require Content Security Policy unsafe-inline and unsafe-eval directives?

Hi, I am successfully using the 5.0.0 version of the javascript WebViewer. I recently made the Content Security Policy for our web app stricter and removed some “unsafe” entries like “unsafe-inline” and “unsafe-eval”. I am now getting these errors when I load a pdf in the developer tools console (the pdf gets loaded correctly anyway)

CoreControls.js:30008 Refused to execute inline script because it violates the following Content Security Policy directive: “script-src ‘self’”. Either the ‘unsafe-inline’ keyword, a hash (‘sha256-8VWEfV1MHXcCbi/lcOneF2oDbPdYwskZilS/Xih/+zc=’), or a nonce (‘nonce-…’) is required to enable inline execution.

>

E



@



CoreControls.js:30008

>

D.SO



@



CoreControls.js:30999

>

l.Document



@



CoreControls.js:17603

>

gr



@



CoreControls.js:26459

>

t.default



@



webviewer-ui.min.js:1

>

(anonymous)



@



webviewer-ui.min.js:1

PDFworker.js?isfull=true:136 Uncaught 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: “script-src ‘self’”. at eval () at a.loadCompiledBackend (PDFworker.js?isfull=true:136) at k (PDFworker.js?isfull=true:137) at PDFworker.js?isfull=true:137 at PDFworker.js?isfull=true:149

>

a.loadCompiledBackend



@



PDFworker.js?isfull=true:136

>

k



@



PDFworker.js?isfull=true:137

>

(anonymous)



@



PDFworker.js?isfull=true:137

>

(anonymous)



@



PDFworker.js?isfull=true:149

Is there anything wrong on my side or does the WebViewer require the 2 “unsafe” directives to be defined? That would not look like t a “best practice” to me…
Also I didn’t check the WebViewer version 5.1.0, which I see is available for download, so I don’t know if this issue has maybe already been taken care of or there is a plan for it.
Best regards
Mirko Lugano

Hi Mirko,

Thanks for contacting us regarding WebViewer!

Previously we use eval internally to run Web Worker code, but this has been changed in the latest version. So if you use the latest version you don’t need unsafe-eval.

I don’t think you would need ‘unsafe-inline’ neither with the latest version.

Best Regards,
Zhijie Zhang
Software Developer
PDFTron Systems Inc.

Hi Zhijie,
thanx for your answer. I downloaded the newest 6.2.3 version of the webViewer and yes, it does not complain about missing unsafe-eval any more.
Still, it continues to complain about unsafe-inline. The problem seems to be in CoreControls.js. I have unminified the code and on line 46386 there is this code

`
b.write(“var event = {};\x3c/script>”);
b.write(“window.__add_action = function(__script){ return function(){(1,eval)(__script); } }\x3c/script>”);

`

which seems to be causing the problem. If I outcomment these lines it does not complain any more.
I am furthermore getting another problem with the new version in PDFworker.js (also unminified by me) on line 1206

`
importScripts(URL.createObjectURL(q))

`

which leads to another Content security policy problem, since it tries to load a custom script as a blob. Here is the error

`
PDFworker.js?isfull=true&disableLogs=0:1206 Refused to load the script ‘blob:https://localhost/e59eb94f-e99a-416a-8e5f-be7019674f68’ because it violates the following Content Security Policy directive: “script-src ‘self’”.

`

if I outcomment that line too, again it does not complain any more. This last error is a bit weird, since scripts from “self” should be allowed, as far as I understand it.

Is there a fix for those or is this going to be dealt with in a future release?
Best regards
Mirko

Hi Mirko,

Thanks for sharing the code which causes the issue, this clears the things for us.

We believe the code that complains about the usage of unsafe-inline is from embedded JavaScript. You can use to disableEmbeddedJavaScript to disable it, so that you won’t see the complaints. If you do want to have embedded JavaScript enabled, you need to have unsafe-inline in the CSP.

The change we did in the recent WebViewer versions is that we are now running the workers code using a Blob instead of eval. So you’d need to configure the CSP to allow blob urls.

Let me know if this helps.

Best Regards,
Zhijie Zhang
Software Developer
PDFTron Systems Inc.

Hi Zhijie,thanx for both tips, it works now without complaining.

Best regards
Mirko

Hi Zhijie,
sorry if I reopen the issue, even though actually it’s not a reopen because the script-src directive in the Content Security Policy now works fine without ‘unsafe-inline’.
Now we are trying to restrict the CSP as much as possible, we let our web app being scanned from services like detectify.com and try to fix all potential security issues.
An issue, which still open is, is unsafe-inline in the CSP style-src directive. It looks like the webViewer needs it.
Similarly to last time I have unminified the code of webviewer-ui.min.js. At line 10101 the following code line gives an error

`
else r ? (8 === (u = t).nodeType ? (i = u.parentNode).insertBefore(l, u) : (i = u).appendChild(l), null != (u = u._reactRootContainer) || null !== i.onclick || (i.onclick = Vn)) : t.appendChild(l)

`

Error:

`
Refused to apply inline style because it violates the following Content Security Policy directive: "style-src ". Either the ‘unsafe-inline’ keyword, a hash (‘sha256-wWjs/s1zsOZRp5l2oW/XXzKS1gCcw3dP0FGNTNf5VXo=’), or a nonce (‘nonce-…’) is required to enable inline execution.

`

is there a setting/a way to avoid also this directive?

Thanx, best regards
Mirko

Hi Mirko,

By looking at the line that complains about the CSP policy, I can’t actually see where the code is setting inline style to an element.

I think we do have some places in the UI that’s setting inline styles, and I think the main reason is that we want the style to have a higher specificity. If you don’t really want to use unsafe-inline in this case then I would recommend you to fork the UI repo and remove all the inline styles.

When looking at MDN it also seems that appending a tag that doesn’t have the URL mentioned in the CSP will also violate the policy. One place that WebViewer will do this is if you are passing the css option to the WebViewer constructor. Just wondering if you happen to load a css file that’s from an origin that’s not included in your CSP?

Best Regards,
Zhijie Zhang
Software Developer
PDFTron Systems Inc.

Thanx, I’ll try to change the code then. I do include a custom css, but it’s from the same domain so it’s not a problem.
Best regards
Mirko