Should Comply to Allow CSP policies (actually this forces the use of unsafe-inline)

[Kwaadpepper]

Prerequisites

• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• The issue still exists against the latest master branch of bootstrap-fileinput.
• This is not an usage question. I confirm having read the plugin documentation and demos.
• This is not a general programming / coding question. (Those should be directed to the webtips Q & A forum).
• I have attempted to find the simplest possible steps to reproduce the issue.
• I have included a failing test as a pull request (Optional).

Steps to reproduce the issue

1. Set CSP policies to disallow inline (« style-src »)

This is a general issue. It would be necessary to rework things.
There is no quick workaround as I see it.

It should use CSSOM ( $(element).css('prop', value))
https://stackoverflow.com/a/29089970/4355295

The actual system is a tree of templates to display things with a replace function to set values.

The solution would be loaded items with no style attr, and then set them using CSSOM.

I have identified 3 entries to fix there 👍

• tZoomCache ( style="display:none" ), easy to fix using a class like d-none
• tProgress style="width" to set the progress width

return tmplt.setTokens({
    'previewId': id,
    'caption': caption,
    'title': title,
    'alt': alt,
    'frameClass': css,
    'type': self._getFileType(ftype),
    'fileindex': ind,
    'fileid': fileId || '',
    'typeCss': typeCss,
    'footer': footer,
    'data': d,
    'template': templ || cat,
    'style': styleAttribs ? 'style="' + styleAttribs + '"' : ''
});

This last one need to be investigated.
I could try to propose a PR if this interests you, and if you are not planning a rewrite of this lib actually.

I crossed this issue working on my project.

These are relevant CSP HTTP headers I am using

Content-Security-Policy: default-src 'self' 'nonce-apwNAzO8atqpImT5'; script-src 'unsafe-eval' 'nonce-apwNAzO8atqpImT5'; frame-src 'self' https://docs.google.com; style-src 'nonce-apwNAzO8atqpImT5'; object-src 'none'; base-uri 'none'; report-uri /omenfilemanager/csp/report

[kartik-v]

Thanks for the update @Kwaadpepper. Please go ahead with a PR.

[Kwaadpepper]

Thanks for the update @Kwaadpepper. Please go ahead with a PR.

All right, I did some bugs fixing waiting this answer.
Will start working on this.

[Kwaadpepper]

I have something nearly ready.
Just a note to leave some trace here

CSP policies, with this patch can be restrictive as

default-src 'self' data:; 
frame-src 'self'; 
media-src 'self' blob:;
object-src 'self' blob:; 
base-uri 'none'; 

I have found easy solutions for inline CSS and JS while keeping the template system.
On the other hand I believe media Elements such as

• default-src 'self' data: for images
• media-src 'self' blob: for audio and video
• object-src 'self' blob: for pdf

Should be allowed as local (see the csp policy upper). There is no way I think to bypass this for media elements (it would be a CSP bug otherwise). There is also no need to, since the client will display his own files to himself only.
https://stackoverflow.com/questions/18447970/content-security-policy-data-not-working-for-base64-images-in-chrome-28

I think this restricts displaying blobs from 'self' only.

I had some other toughs, should this be an bootstrap-fileinput option, or a passive functionality.
I think this could be left as a functionality. As For displaying blobs this should be left to the user.

But there could be added somewhere in the docs as small section about CSP although.

I'll do some more tests and submit a PR soon.

[Kwaadpepper]

I just hurt myself to this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1582115.
On Firefox pdf.js won't load due to CSP policies even it is a browser component.

The workaround issue seems to be

base-uri: resource://pdf.js/web/
script-src:  resource://pdf.js/

Seems to be kinda "fixed" in Firefox 77.0b6
https://bugzilla.mozilla.org/show_bug.cgi?id=1582115#c33

I just filed a follow up bug for the base-uri problem (see Bug 1638826). Uplifting Bug 1638826 is probably too big of a change that close to the end of the cycle and I rather fix that problem as a follow up.
To sum it up: The problem within this Bug that a CSPs script-src directive affects the loading for pdf.js was fixed and uplifted within this bug.
The follow up bug is to fix the problem within base-uri which might also affect pdf.js but uses a different code path within Firefox. The reason I think it was worth uplifting this bug is that the script-src directive is more likely used than base-uri. I know this is not the optimal solution, but page's using a CSP of base-uri have to wait one more iteration of Firefox till this problem is fixed - sorry about that but in this situation the best possible path forward!