Proposal: Allow extension contexts to set forbidden headers in fetch() API

[oliverdunk]

The fetch API allows callers to set headers on the given request via the headers property on the RequestInit object. However, this explicitly forbids certain headers from being set; these are called forbidden header names. These headers are instead set by the browser, and often have security considerations.

One such header is the Origin header, which indicates the origin initiating the request. This allows servers to restrict which data they allow in a cross-origin context. By design, the browser does not allow websites to modify this header, since that would allow websites to imitate a same-site request even if they were cross-site.

However, extensions, by design, can modify the Origin header by listening for the request in the declarativeNetRequest or webRequest APIs and modifying the header there. Additionally, requests made from an extension origin to an origin to which the extension has access are already treated as same-site requests (and do not have the origin header set by the browser). This is not a security risk, as we limit this to extensions to which the extension has host permission (and could thus run scripts directly upon).

We would like to investigate allowing extensions to set these headers directly in the fetch API (from a suitably-trusted caller), rather than needing to separately monitor and modify the request via declarativeNetRequest or webRequest. This results in simpler, cleaner code for extensions and a significantly more performant operation.

To support this, we would like to work with the editors of other specifications to investigate the feasibility of modifying the web specification for the fetch API to indicate websites may not set forbidden header names, but that doing this may be allowed by the user agent for certain contexts, such as extensions. This follows discussions we have had about ensuring new behavior we add is covered by specifications and that we are not introducing new behavior which is undocumented and cannot benefit other clients that may have similar requirements.

[oliverdunk]

Adding support from the Chrome side. This is just support of starting these conversations, and whether we actually want to make these changes to the specification will need more discussion.

[erosman]

Another area of consideration is the userScripts manager development which traditionally allowed the modification of Cookie, Host, Origin, and Referer in XMLHttpRequest (and fetch).

In MV2, the modifications were achieved via "blocking" webRequest which is no longer available in Chrome's MV3.

Performing the same task in MV3 via declarativeNetRequest is not straightforward.

Allowing direct modification of Cookie, Host, Origin, and Referer would greatly facilitate the userScripts manager development.

[Mixesoft]

Additionally, requests made from an extension origin to an origin to which the extension has access are already treated as same-site requests (and do not have the origin header set by the browser).

Currently, Chrome and another Chromium based browsers set the Origin header to extension origin as expected so web services associated with an extension can check Origin header.
I think these headers must be set by the browser only for security reason. If extensions can set Origin header to another chrome-extension://origin sheme this is issue that introduce significant unexpected extension breakage and new ways for extensions to sabotage each other.

[derjanb]

We would like to investigate allowing extensions to set these headers directly in the fetch API (from a suitably-trusted caller), rather than needing to separately monitor and modify the request via declarativeNetRequest or webRequest.

This doesn't solve #694, but it would make the issue irrelevant for Tampermonkey. So +1 from me.

[Rob--W]

Supportive of exploring this from the Firefox side.

From the security point of view, it is worth emphasizing the following:

• host permissions should be required for this capability, like we have today.
• the current alternatives require webRequestBlocking or declarativeNetRequest or declarativeNetRequestWithHostAccess permissions. Although there is no permission warning needed, the presence of the permission can help reviewers and limit capabilities to only the extensions that really need this. It would make sense to also require a permissions for this.
• the Origin and Host permissions can be used to spoof websites. In order to specify a value, extensions should have host permissions for the specified value. This also implies that extensions cannot spoof other extensions (except possibly when the user configures a flag that allows extensions to spoof other extensions - this is however not default behavior and not relevant to ~100% of the users)
• this capability should only be available to true extension origins (such as background scripts). Not to content scripts, not to sandboxed extension origins with an opaque origin.