1365502 - CSP header blocks file download in iframe for Firefox only

Status: RESOLVED INVALID

(Core :: DOM: Security, defect)

Description

[amjad.aziz817]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36

Steps to reproduce:

I am using my website in iframe. My website is secured with following CSP headers:

default-src 'self'; frame-ancestors 'self'; img-src: 'self' data:;

I am downloading file in pdf format using following JavaScript code:

var a = doc.createElement('a');
a.download ='download.pdf';
a.href = 'data:application/pdf;base64,' + pdfdata;
doc.body.appendChild(a);
a.onclick = function () {
    a.parentNode.removeChild(a);
};
a.click();

PS: If I launch my website out of iframe then file is downloaded in Firefox as well. Moreover if I use frame-src 'self' data:; then file is downloaded in Firefox as well. But I want to know why Firefox is not allowing file download without frame-src directive while other browsers allow file to download.


Actual results:

In Chrome & IE, the file is being downloaded successfully. But for Firefox I see the following CSP error:

Content Security Policy: The page’s settings blocked the loading of a resource at data:application/pdf;base64,JVBERi0xLjcK... (“default-src self”).


Expected results:

File should be downloaded successfully without any error like other browsers.

Comment 1

[amjad.aziz817]

Had some discussion over Mozilla Support:

https://support.mozilla.org/en-US/questions/1160413?

Comment 2

[Loic]

Is it possible to provide a simple live test page on your website?

Comment 3

[amjad.aziz817]

Hi Loic,

I have deployed sample page with CSP headers.
 
http://data-uri-download-csp.bitballoon.com/

Try in Firefox and Chrome.

In Chrome its working fine but for Firefox it throws CSP violation exception.

Let me know if you need more information.

Comment 4

[Loic]

Thanks for the testcase, I can reproduce the issue.

Comment 5

[Daniel Veditz [:dveditz]]

As far as we're concerned our behavior is correct: when you click the link you are navigating the frame to the data urls (we block it before the download is triggered). If users were allowed to navigate a frame to random sites then what is the value of frame-src? Maybe Chrome only cares that the original frame load is allowed and doesn't care about the site's rules after that?

If Chrome has implemented this differently maybe the spec needs a clarification. This should be moved to a github issue on the spec.

Comment 6

[Daniel Veditz [:dveditz]]

@arberosmani offers a workaround at https://github.com/arberosmani/workaround-csp-frame-src-blocked-on-firefox
It requires either same-origin access or parent document cooperation to end up re-creating the link in a location where it will not be blocked.

Differences between Firefox and Chrome on spec behavior aren't great. Instead of filing a bug against Firefox we should create a web platform test (wpt.fyi) to demonstrate the incompatibility. Then we (the spec folks) can argue which implementation's behavior is correct and why, and if necessary file a spec bug to clarify ambiguous language.

CSP spec issues can get a bit tricky to track down because in practice the exact behavior is spread across the CSP, Fetch, and HTML specs.