Closed Bug 1391669 Opened 7 years ago Closed 7 years ago

FR: Different permissions for background and content scripts


(WebExtensions :: General, enhancement, P5)

54 Branch


(Not tracked)



(Reporter: arantius, Unassigned)


(Whiteboard: [design-decision-denied])

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170612122443

Steps to reproduce:

For my WebExtension, I want the <all_urls> permission for my background script.  I want it to then tabs.executeScript() a content script which does _not_ have the <all_urls> permission.

This is the one case I know of for sure; I probably have a few similar things I'd like to do like this.  In general I want runtime-generated content scripts to not have privileges that "my extension" does.
I think this could also be achieved with bug 1353468. Since the content script instantiating the sandbox would have the same privileges as the background script but the sandbox would not.
Component: Untriaged → WebExtensions: General
Product: Firefox → Toolkit
Yes, if I could construct/control a sandbox as per bug 1353468 I'd actually have exactly what I want.  Then for my needs I'd consider this bug obsolete.
Whiteboard: [design-decision-needed]
Hi Anthony, this has been added to the agenda for the September 5 WebExtensions APIs triage meeting. Would you be able to join us? 


Sorry for slow response, yes I should be able to make it.
I believe this is being replaced by the user script support in bug 1332273, although there might be more bugs. Based on what we talked about in the design-decision meeting, I think this one is not going anywhere awaiting the outcome of that bug.

Closing for now.
Severity: normal → enhancement
Closed: 7 years ago
Priority: -- → P5
Resolution: --- → DUPLICATE
Whiteboard: [design-decision-needed] → [design-decision-denied]
This one should be orthogonal to 1332273 since it is about permissions available to the content script, such as the XHRs being more powerful than the page content's.

userscript extension requires <all_urls> permission -> content scripts have cross-domain XHR -> user scripts inherit that. Additionally they also inherit access to the content script APIs such as storage, which could also pose a security issue.

Although personally I believe that problem is better solved with bug 1353468 since that one also solves all those problems, including shared globals and shared xray wrappers.
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.