This is an archived page. It's not actively maintained.



Support for extensions using XUL/XPCOM or the Add-on SDK was removed in Firefox 57, released November 2017. As there is no supported version of Firefox enabling these technologies, this page will be removed by December 2020.

Add-ons using the techniques described in this document are considered a legacy technology in Firefox. Don't use these techniques to develop new add-ons. Use WebExtensions instead. If you maintain an add-on which uses the techniques described here, consider migrating it to use WebExtensions.

Starting from Firefox 53, no new legacy add-ons will be accepted on (AMO) for desktop Firefox and Firefox for Android.

Starting from Firefox 57, only extensions developed using WebExtensions APIs will be supported on Desktop Firefox and Firefox for Android.

Even before Firefox 57, changes coming up in the Firefox platform will break many legacy extensions. These changes include multiprocess Firefox (e10s), sandboxing, and multiple content processes. Legacy extensions that are affected by these changes should migrate to use WebExtensions APIs if they can. See the "Compatibility Milestones" document for more information.

A wiki page containing resources, migration paths, office hours, and more, is available to help developers transition to the new technologies.



Provides access to XMLHttpRequest functionality.


Security Concerns

By default, the XMLHttpRequest object grants full access to any protocol scheme, which means that it can be used to read from (but not write to) the host system's entire filesystem. It also has unfettered access to any local area networks, VPNs, and the internet.

Threat Model

The XMLHttpRequest object can be used by an add-on to "phone home" and transmit potentially sensitive user data to third parties.

If access to the filesystem isn't prevented, it could easily be used to access sensitive user data, though this may be inconsequential if the client can't access the network.

If access to local area networks isn't prevented, malicious code could access sensitive data.

If transmission of cookies isn't prevented, malicious code could access sensitive data.

Attenuating access based on a regular expression may be ineffective if it's easy to write a regular expression that looks safe but contains a special character or two that makes it far less secure than it seems at first glance.

Possible Attenuations

Before being exposed to unprivileged code, this object needs to be attenuated in such a way that, at the very least, it can't access the user's filesystem. This can probably be done most securely by white-listing the protocols that can be used in the URL passed to the open() method, and limiting them to http:, https:, and possibly a special scheme that can be used to access the add-on's packaged, read-only resources.

Finally, we need to also consider attenuating http/https requests such that they're "sandboxed" and don't communicate potentially sensitive cookie information.




Creates an XMLHttpRequest. This is a constructor, so its use should always be preceded by the new operator. For more information about XMLHttpRequest objects, see the MDN page on Using XMLHttpRequest and the Security Concerns section in this page.



Force relevant cookies to be sent with this XMLHttpRequest even if normally they would not be.


xhr: XMLHttpRequest
The XMLHttpRequest to allow third-party cookies for.