referrerpolicy attribute with value "unsafe-url" or "no-referrer-when-downgrade" ignored in crossorigin iframes
Categories
(Core :: Privacy: Anti-Tracking, defect)
Tracking
()
People
(Reporter: 1benediktwerner, Unassigned)
Details
Steps to reproduce:
Embed an iframe with <iframe src="..." referrerpolicy="unsafe-url"></iframe> where the src is on a different origin.
Example page: https://home.in.tum.de/~wernerbe/firefox-referrer-bug.html?a=b (the embedded iframe is https://httpbin.org/headers which just echos back the received headers).
Actual results:
If the src URL uses http, no referrer header is sent at all. If it uses https, a shortened (domain-only) referrer header is sent.
Expected results:
Given that referrerpolicy="unsafe-url" was specified, a full referrer including the path and query parameters should be sent in all cases.
This behaves as expected in Chrome and as far as I'm aware used to work in older versions of Firefox, though I don't know when it stopped working.
This seems like something that might have been changed due to security considerations but I haven't been able to find any announcement or further information on this being intended and it seems to violate the spec.
I am maintaining a website where I embed an iframe that I trust (though actually using https and referrerpolicy="no-referrer-when-downgrade" but that has stopped working in Firefox all the same) and it reads the query parameter of my page to adjust its content which has now stopped working (though as mentioned, I don't know since when, I just received a report about it being broken yesterday).
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
unsafe-url was unsupported in bug 1720294 in Firefox 92, based on a spec change spearheaded by Google. I thought this was long settled, but prompted by this bug I just noticed that the PR wasn't in a closed state because they made the change, but because the Chrome folks gave up on it. I'm fairly certain Safari will behave this way as well.
In addition there's the overall default change to strict-origin-when-cross-origin in bug 1589074 that has broad agreement as a default, and chrome has shipped since chrome 80-something. But Firefox and Apple don't let sites relax that setting, I believe.
The referrerpolicy spec descussion
https://github.com/w3c/webappsec-referrer-policy/pull/125 carried into 142
https://github.com/w3c/webappsec-referrer-policy/pull/142
Further discussion in the Privacy CG
https://github.com/privacycg/proposals/issues/13
|
|
||
Updated•3 years ago
|
|
||
Comment 3•3 years ago
|
||
Firefox ignores the less restricted unsafe-url referrer policy for cross-site iframes. So, this is expected behavior.
|
Reporter | |
Comment 4•3 years ago
|
||
@timhuang The header is completely useless outside a cross-site context.
But I guess thanks for the info @dveditz, with this I was at least able to find the Firefox release notes mentioning this change, though still only after searching closely. And indeed Safari seems to behave the same.
It's still very surprising to me though that this is not properly documented anywhere. E.g. MDN explains all the now unsupported header values with no mention of them not working anymore. Everywhere always just mentions the default change but not that it's now also not possible to override it anymore. And of course, the spec also hasn't been updated. And there's also no console warning or error on pages using the header or anything like that.
|
|
||
Comment 5•3 years ago
|
||
Firefox does log a console message to say that the less restricted referrer policies are ignored. But, I cannot see the message on your test site. I will look into why it doesn't log.
Description
•