Bug 244576 - [web extensions] Allow header modification for origins with host permissions using declarativeNetRequest
Summary: [web extensions] Allow header modification for origins with host permissions ...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Enhancement
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-08-31 02:08 PDT by vsr4493
Modified: 2023-05-22 07:06 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description vsr4493 2022-08-31 02:08:28 PDT
When using a safari web extension background page to initiate a fetch request, there isn't a way to verify that it is a trusted origin on the server since the UUID of the origin header for web extensions changes per browser launch. The origin check on the server regardless of CORS on the browser is also a necessity to prevent CSRF attacks.

## Workaround
If an extension has host permissions for a particular URL it can work around this by opening a new tab and using a content script to make fetch requests which would have the same origin as the page. But this can be weird UX since it will involve opening a new page just to act as a proxy.


## Proposal
If we allow header modification using declarativeNetRequest (only for origins for which the extension has been granted host permissions by the user), the extension could change its origin to match the expected origin and do this without the workaround above.

Alternatively, can the origin of the request be made to match the target host origin if the extension has host permissions?

Is there any other workaround for this / options on the roadmap?
Comment 1 Radar WebKit Bug Importer 2022-09-07 02:09:16 PDT
<rdar://problem/99640846>
Comment 2 Brent Fulgham 2023-04-11 17:09:56 PDT
The cause of this issue is in code outside of WebKit, so resolving as MOVED.

Work was conducted under <rdar://71867709>, and shipped in iOS 16.4.1 and macOS 13.3.1.