1726500 - Firefox does not obey X-Frame-Options header if the iframe source responds with a 3XX status code.

Status: RESOLVED INVALID

(Core :: DOM: Security, defect)

Description

[Suraj Disoja]

Attachment: screenshots

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Hi there,

I have discovered an issue where firefox Firefox does not obey the X-Frame-Options header if the iframe source responds with a 3XX status code, i.e, firefox would follow the redirection instead of blocking the iframe.

To reproduce,

1. Visit, https://h1ninetynine.pythonanywhere.com/poc, which creates an iframe pointing to https://h1ninetynine.pythonanywhere.com/.
2. https://h1ninetynine.pythonanywhere.com/ responds with an X-Frame-Options: DENY header and a 302 redirect.
3. Browser follows the redirect instead of blocking the Iframe.
4. Open the same /poc endpoint in chrome, the iframe gets blocked.

Actual results:

FIrefox 91 followed the iframe's redirection even if X-Frame-Options was set to SAMEORIGIN or DENY.

Expected results:

The browser should block the iframe even during redirection, like in chrome or edge

Comment 1

[:Gijs (he/him)]

https://stackoverflow.com/questions/22077618/respect-x-frame-options-with-http-redirect suggests that the spec language indicates Firefox's behaviour is correct.

(In reply to Suraj Disoja from comment #0)

The browser should block the iframe even during redirection, like in chrome or edge

That's not what I see; Chrome follows the redirect just fine. It ends up displaying an error page because the target page to which you're redirecting redirects some more for Chrome/Edge (to the Firefox download page, using JS code in redirect.js), and because the response headers on that Firefox download page from www.mozilla.org include x-frame-options: deny, it blocks the final page from loading:

Refused to display 'https://www.mozilla.org/' in a frame because it set 'X-Frame-Options' to 'deny'.

When opening the target page from your redirect (ie https://start.mozilla.org/en-us/) in Firefox, it does not redirect to the Firefox download page, and does not have x-frame-options headers, so the page is displayed.

So I think this report is invalid, and if you used a redirect target that did not send x-frame-options: deny on any of the browsers, the result would be the same.

Can you confirm?

Comment 2

[Suraj Disoja]

Hi,

Thanks for the additional insights. I might not have paid attention to the details of why chrome blocked the iframe and jumped to the conclusion. Based on your reply, I too think that this report is invalid so please close it.

Cheers!
Suraj Disoja

Comment 3

[:Gijs (he/him)]

Thanks for the quick response!