[Html2PdfConverter] Content Security Policy (CSP) blocking images and CSS

Forge Component
(60)
Published on 17 May by Guilherme Pereira
60 votes
Published on 17 May by Guilherme Pereira

After activating the CSP on lifetime for the Production environment the PDFs are being generated without any formating or images. After a few tests we figured out that img-src and style-src rules need to have a '*' besides the 'self' to allow the corrcet generation of the PDF.

Since the 'self' is already there the '*' shouldn't be necessary since the URLs requested for the images and CSS are from the same server (self).

Any ideas on what might be happening here?

Thanks,

Pedro Delgado

Hi Pedro,

I asked for help on this one.

Let's hope someone can answer your question!

Cheers,

João

Hello,

Self is VERY restrictive. It says that the only trustworthy source is the domain itself. If the images are in a subdomain, they will not be loaded (don't know if it restricts paths, also)
The * says "load from everywhere"

So, my FIRST guess would be that the images and so on, that he is trying to load, are not exactly in the "same" place as the application. Also, if the site is http and he is trying to access is using https, it would block the images if using Self.

And, finally, what I was looking for.
Here: https://stackoverflow.com/questions/16627310/wkhtmltopdf-not-loading-local-css-and-images#16650685

It seems that if you add a "base" tag to the header, could solve the problem (it seems that is a problem of the executable not sending the information correctly to the server)

Seems really to be a problem of communication between the wkhtmltopdf executable and the server...

Cheers,
Eduardo Jauch

I'm not sure whether Eduardo's link above is really related to wkhtmltopdf's troubles with CSP. For us, the solution was to add 127.0.0.1 besides self for img-src, script-src and style-src. This is because HtmlToPdfConverter was invoking wkhtmltopdf with a local url starting with https://127.0.0.1.

Toni Juvani wrote:

I'm not sure whether Eduardo's link above is really related to wkhtmltopdf's troubles with CSP. For us, the solution was to add 127.0.0.1 besides self for img-src, script-src and style-src. This is because HtmlToPdfConverter was invoking wkhtmltopdf with a local url starting with https://127.0.0.1.

And the self is not enough because the executable is not fetching the images from the same domain (the app domain), even if they are in the same server.


Eduardo Jauch wrote:

Hello,

Self is VERY restrictive. It says that the only trustworthy source is the domain itself. If the images are in a subdomain, they will not be loaded (don't know if it restricts paths, also)
The * says "load from everywhere"

So, my FIRST guess would be that the images and so on, that he is trying to load, are not exactly in the "same" place as the application. Also, if the site is http and he is trying to access is using https, it would block the images if using Self.

And, finally, what I was looking for.
Here: https://stackoverflow.com/questions/16627310/wkhtmltopdf-not-loading-local-css-and-images#16650685

It seems that if you add a "base" tag to the header, could solve the problem (it seems that is a problem of the executable not sending the information correctly to the server)

Seems really to be a problem of communication between the wkhtmltopdf executable and the server...

Cheers,
Eduardo Jauch

Thankyou for sharing these information Mr.Jauch, 

it works..

How did you add the base tag? I tried calling HttpRequestUtility.SetBaseTag and passed in the HREF parameter (Target parameter as empty) but I didn't see a new tag when checking the source with a client.

Toni Juvani wrote:

How did you add the base tag? I tried calling HttpRequestUtility.SetBaseTag and passed in the HREF parameter (Target parameter as empty) but I didn't see a new tag when checking the source with a client.

Here I tried another method, in that i added the base tag in the value of an expression.


Hello,

We are having this exact problem when we try to use wkhtmltopdf Stable version on Outsystems Cloud. We can't load images or CSS with Content Security Policy active, unless we add '*' or 'https:' to the img-src or style-src tag.

We tried, without success, the other solutions in this thread (using the base tag or adding 127.0.0.1 to the rules). Did anyone find another solution for this, other than using '*' on the CSP rules?

Note: the Bleeding Edge version of wkhtmltopdf seems to work fine, but we can't use headers and footers on that version.


Thank you.

Hi Eduardo,


Can you try to set the header on your page only when generating the PDF using HttpRequestHandler and setting with the specific domains for your environment? 


If that doesn't work I'd say you will probably have to add the '*' but you could do it programmatically only when rendering the pdf in order to not compromise security in other scenarios (either have a specific page for that or pass an additional parameter to identify when you are in pdf generation mode).


Cheers,

Guilherme

Hi Guilherme,


Thank you for the quick reply.


I'm not sure how to add '*' programmatically. I'm trying to use the AddMetaHttpEquivTag on the page Preparation, but without success:


Do you have any working example?

Hi Eduardo,


I don't have any working sample but using the action AddHeader from HttpRequestHandler should allow you to add the header.


I suggest you take a look at the spec here and play around with the values.


Cheers,

Guilherme

Hello,


I've added the headers, and I've tested a lot of combinations, but I still can't seem to find a way to solve this issue with only meta tags.

From my research on the subject, we can only use the meta tag on the page to make the policy more strict, not to relax the policy defined on the server.


So my question is: is there any successful case of using the Stable version of WKHTMLTOPDF on Outsystems cloud with Content Security Policy on, without having to "open" img-src and style-src on the environment settings? If it is not possible we can look for another solution.


Thank you again for all the help.