[Webkit-unassigned] [Bug 244576] New: [web extensions] Allow header modification for origins with host permissions using declarativeNetRequest

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Aug 31 02:08:28 PDT 2022


https://bugs.webkit.org/show_bug.cgi?id=244576

            Bug ID: 244576
           Summary: [web extensions] Allow header modification for origins
                    with host permissions using declarativeNetRequest
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Enhancement
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: vsr4493 at gmail.com

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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220831/3702f88d/attachment.htm>


More information about the webkit-unassigned mailing list