1722703 - XHR from background page is marked as Sec-Fetch-Site: cross-site

Status: RESOLVED FIXED

(WebExtensions :: General, defect, P1)

Description

[Tom S [:evilpie]]

Since the Sec-Fetch-* headers are shipping in Firefox 90, XHR requests from the background page get the following headers:

Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site

This causes for example Google News to deny the request: https://github.com/nt1m/livemarks/issues/363.

I could imagine that similar to "system" requests, webextension request shouldn't be cross-site.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1695911

Comment 3

[Anne (:annevk)]

See https://w3c.github.io/webappsec-fetch-metadata/#extension-initiated. If the extension is granted access to that site, it should have same-origin as value, but otherwise it should be cross-origin.

Comment 4

[Tomislav Jovanovic :zombie]

[Tracking Requested - why for this release]: Unexpected breakage in a new config we're shipping.

Comment 5

[Julien Cristau [:jcristau]]

Should we consider unshipping the new headers in 91, or would that be worse than this bug?

Comment 6

[Niklas]

Attachment: Bug 1722703: Consider requests from extension with access to the requested site as Sec-Fetch-Site: 'same-origin'. r=ckerschb,robwu

Comment 7

[Rob Wu [:robwu]]

(In reply to Julien Cristau [:jcristau] from comment #5)

Should we consider unshipping the new headers in 91, or would that be worse than this bug?

I suggest to keep the feature, and uplift the fix to ESR91 once it lands.
Affected users can manually flip the pref.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/04ebee77f0ad
Consider requests from extension with access to the requested site as Sec-Fetch-Site: 'same-origin'. r=ckerschb,robwu

Comment 9

[Sandor Molnar[:smolnar]]

Backed out for causing clang build bustages.

Backout link: https://hg.mozilla.org/integration/autoland/rev/313b0ffc55b6a05a211c2de315f8a94955bfd476

Push with failures

Failure log

Comment 10

[Ryan VanderMeulen [:RyanVM]]

 #include "mozilla/StaticPrefs_dom.h"
+#include "mozilla/BasePrincipal.h"

Should those be alphabetical?

Comment 11

[Niklas]

I put the includes in order now but the actual issue was using BasePrincipal instead of mozilla::BasePrincipal.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f585c3e73564
Consider requests from extension with access to the requested site as Sec-Fetch-Site: 'same-origin'. r=ckerschb,robwu

Comment 13

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/f585c3e73564

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR91 approval when you get a chance.

Comment 15

[Christoph Kerschbaumer [:ckerschb]]

Comment on attachment 9234394 [details]
Bug 1722703: Consider requests from extension with access to the requested site as Sec-Fetch-Site: 'same-origin'. r=ckerschb,robwu

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Sec-Fetch-* Security headers is a new security feature we started to ship in Firefox 90 (see Bug 1695911).
• User impact if declined: Web Extensions with access to the requested site send the wrong sec-fetch-* security header.
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Not risky, it's only a small tweak which causes web extensions to send a different security header (covered by automated tests).
• String or UUID changes made by this patch: no

Comment 16

[Julien Cristau [:jcristau]]

Comment on attachment 9234394 [details]
Bug 1722703: Consider requests from extension with access to the requested site as Sec-Fetch-Site: 'same-origin'. r=ckerschb,robwu

approved for 91.1esr

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/4defecbe7eb8