CORS again

13 views
Skip to first unread message

als

unread,
Mar 24, 2014, 5:11:44 AM3/24/14
to mozilla-la...@googlegroups.com
My add-on needs to examine the background images on a page.
A content script gets a Security Error if it attempts to load the image URLs into
an img node. So as a work-around the content script ships the background URLs to the add-on script which is privileged enough to read the URLs.

It seems odd that one part of an add-on can be trusted while another isn't.
What's the reason that content scripts are subject to CORS?

David Bruant

unread,
Mar 24, 2014, 5:28:59 AM3/24/14
to mozilla-la...@googlegroups.com
Le 24/03/2014 10:11, als a écrit :
> My add-on needs to examine the background images on a page.
> A content script gets a Security Error if it attempts to load the
> image URLs into
> an img node. So as a work-around the content script ships the
> background URLs to the add-on script which is privileged enough to
> read the URLs.
>
> It seems odd that one part of an add-on can be trusted while another
> isn't.
It forces to reduce the API surface exposed by the content script to the
webpage and thus reduces the security risks associated with installing
the addon. For a webpage to attack an addon, the webpage has to abuse
the content script, pass through one of the few communication channels
between the content script and the addon script and then abuse that.

> What's the reason that content scripts are subject to CORS?
Because they have the same privilege than web pages (+ a couple of
communication channels, but these are explicitly created by the addon
author and are easier to audit/review).

David
Reply all
Reply to author
Forward
0 new messages