1862553 - CSP frame-src blocks link download in Firefox but not Chrome

Status: NEW

(Core :: DOM: Security, defect, P2)

Description

[Daniel Veditz [:dveditz]]

Attachment: simple testcase

In the MDN example of a link with the download attribute, the parent document has a CSP that does not include data: in its list of allowable frame-src sources. Inside the frame a download link has an href=data:image/png,... with a download="myfile.png" attribute. On Chrome this download works; in Firefox we block the load for violating the frame-src directive.

Without the download attribute it would be a navigation and both browsers would block it. With the download attribute Chrome recognizes the content isn't being loaded inside the frame and allows it, and Firefox seems to first check the CSP and block the load before realizing it's a download.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#result_6

The attached testcase is a simplified version of the broken part of the page. The document has a CSP with frame-src 'self'; which contains an iframe with 3 links.

• The first link ("download") is this compat bug, where Chrome allows it and Firefox doesn't
• The second link has target=_blank to open a new window, and neither browser stops that (once in the other window Chrome prevents it from loading for unrelated reasons)
• The third link tries to navigate to the Mozilla site which is not on on the frame-src list, so both browsers block it. Just here as a baseline check.

Comment 1

[Daniel Veditz [:dveditz]]

If this turns out to be a Firefox bug we could move it to Core::DOM: Security. My expectation in this scenario is that Chrome is right: with the download attribute the content is NOT being loaded into the frame so CSP should leave it alone like it lets the target=_blank version go. Need to see if the spec is ambiguous or clear enough on this, and adding a WPT would be nice, too.

Comment 2

[Calin Tanase]

Attachment: download painting.mp4

Verified this issue and it's still reproducible on Firefox versions 123 and 125.

Environment:
Operating system: Windows 10
Browsers: Firefox Nightly 125.0a1 (2024-02-20) / Firefox Release 123 / Chrome 121.0.6167.185

Note: Not reproducible on Chrome

Comment 3

[Frederik Braun [:freddy]]

Nominating for DOM:Security triage.

Comment 4

[Daniel Veditz [:dveditz]]

Simon: does the Fetch spec specify when the download attribute is acted on in relation to when the CSP hooks are called?

• does the spec need clarifying?
• if it's clear, is Firefox wrong or Chrome?
• if Chrome turns out to be wrong, should we match them and change the spec anyway?

Comment 5

[Simon Pieters [:zcorpan]]

The spec is more like Chrome as far as I can tell. The download is not a navigation.

Clicking a link is handled in https://html.spec.whatwg.org/#links-created-by-a-and-area-elements:activation-behaviour-2 which checks for download attribute, and step 6 calls https://html.spec.whatwg.org/#downloading-hyperlinks which doesn't do a CSP navigation check.

Comment 6

[Simon Pieters [:zcorpan]]

Anne pointed out that <a download> not using the navigate algorithm is a spec bug. See https://github.com/whatwg/html/issues/5548 , https://github.com/whatwg/html/issues/7718

Figuring out what we should do here might involve investigating what happens in Chromium and WebKit, and maybe fixing those spec bugs.