Bug 244576
| Summary: | [web extensions] Allow header modification for origins with host permissions using declarativeNetRequest | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | vsr4493 |
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Enhancement | CC: | achristensen, bfulgham, timothy, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
vsr4493
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?
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/99640846>
Brent Fulgham
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.