# Extensions Security FAQ [TOC] ## Purpose This document outlines many common questions we've received about extensions security and what we do or do not consider to be security bugs. This is primarily written for an audience of Chromium developers and security researchers. It is analogous to the general [Chrome Security FAQ](https://chromium.googlesource.com/chromium/src/+/main/docs/security/faq.md). ## Future Additions Add canonical examples of bugs for each of these (particularly WontFix bugs for examples of what is not considered a security bug). ## FAQ ### I've found / written an extension that can access sensitive user data, like passwords and emails. Is this a security bug in Chromium? In most cases, this is _not_ a security bug. Extensions are designed to have access to user data if and only if they have the appropriate [permissions](https://developer.chrome.com/docs/extensions/mv3/declare_permissions/). For instance, an extension may be able to access a user's data on a set of sites (or all sites) if the extension requests the appropriate permissions in its manifest file. Before an extension can use these capabilities, they must be granted by the user - as an example, the install prompt may say that the extension can "Read and change your data on google.com". If the extension is only able to access user data through permissions the extension has requested (for instance, it is able to access data on google.com because it specified host or content script permissions that match google.com), then this access is working as intended. If an extension is able to access data _without_ appropriate permission, then this would be a security bug. Please report any such bugs [here][new-security-bug]. ### Why do you allow extensions to access sensitive user data? Surely there's no reason to allow it to read my passwords! It may seem alarming that certain extensions can access certain types of sensitive data, such as passwords. However, this access can be critical to extensions' functionality. Consider, for instance, password managers (which store and retrieve your passwords) - these extensions, fundamentally, must access this type of sensitive data. There is very little data that we can deterministically say should never be available to extensions. When installing extensions, users should be sure to look both at the permissions requested by the extension (displayed in the installation prompt) and also at the extension's privacy policy and other disclosures (which may be linked from the extension's listing on the [Chrome Web Store](https://chrome.google.com/webstore)). ### If extensions can read sensitive user data, what prevents an extension from stealing my sensitive data? First, extensions should only be allowed to access data that they have permission to (and these permissions must be approved by the user before they can be used, either at installation or at runtime). Users should only install extensions and grant permissions to extensions they trust. In addition to these platform mitigations, developers distributing through the Chrome Web Store are required to adhere to a number of different policies, which describe which types of behaviors are allowed. For instance, the [user data](https://developer.chrome.com/docs/webstore/user_data/) FAQ here describes the types of data and permissions that extensions are allowed to gather and use. Google also subjects extensions to a combination of automated and manual review systems. ### I've found / written an extension that can access site data without any host patterns specified in the "permissions" or "host\_permissions" manifest keys. Is this a security bug? In most cases, this is _not_ a security bug. Extensions can also access certain sites with content scripts (specified in the `content\_scripts` key) or with the `activeTab` permission. Hosts specified in `content\_scripts` (under the `matches` key) are displayed to the user in permission requests in the same way as host permissions requested under `permissions` or `host\_permissions` - that is, it indicates the extension can "Read and change your data on ". ActiveTab requires a user to explicitly invoke the extension on a page before the extension can access data on the page, which is a form of runtime permission grant (similar to how "sharing" a page with an app on Android grants the app access to the content of the page). If an extension is able to access site data without any API or permission that allows this access, then it may be a security bug. Please report any such bugs [here][new-security-bug]. ### Are extensions able to keep running after they have been uninstalled? An extension is not able to directly keep running after it has been uninstalled (or disabled) by the user or the browser. However, any changes made by an extension to a currently loaded site (e.g. script injection or data modification) will remain in place after the extension is uninstalled until the user leaves the site (e.g. by navigating away or refreshing), and potentially beyond. This has a few implications: * Exfiltrated data is still exfiltrated. If an extension sent data from the local device to a remote server, Chromium cannot delete the data on that remote server. * Content scripts (and other injected scripts) will continue running on pages they have already been injected in after the extension is disabled. Since Chromium cannot "un-inject" these scripts, they may continue running until the user leaves the site. * Data modified by the extension remains modified. This includes data like cookies, which may influence how a site operates. Additionally, extensions may have mutated the cache, installed service workers on sites, or similar modifications. These will persist. Other extension behavior, such as running background scripts, network handlers, URL overrides, proxy settings, and preference modifications should be reverted upon uninstallation. ### I've found an extension that violates Chrome Web Store policy. Is this considered a bug in Chromium? Individual extensions are generally not considered a part of Chromium, so extensions violating Chrome Web Store policies (including distribution policies) are not considered security bugs in Chromium itself. You can report the extension with the "Report abuse" link in the extension's entry on the Chrome Web Store. ### Is adding a malicious extension to a user's profile considered a security bug? Chromium [does not consider physically-local attacks to be security bugs][physically-local-attacks]. This includes attacks like loading extensions on a user's machine. As such, attacks like loading extensions physically through loading an unpacked extension in the chrome://extensions page, via malicious software that executes outside of the Chromium browser, or updating enterprise policies to load extensions are all not within Chromium's threat model. Adding a malicious extension to the user's profile is only a security bug if you find a way to add the extension without direct access to the user's profile and bypassing the normal extension installation flow. For instance, if an extension could be installed (without user consent) when the user visits a malicious site, this would be considered a security bug. Please report any such bugs [here][new-security-bug]. ### Chrome silently syncs extensions across devices. Is this a security vulnerability? If an attacker has access to one of a victim‘s devices, the attacker can install an extension which will be synced to the victim’s other sync-enabled devices. Similarly, an attacker who phishes a victim‘s Google credentials can sign in to Chrome as the victim and install an extension, which will be synced to the victim’s other sync-enabled devices. Sync thereby enables an attacker to elevate phished credentials or physical access to persistent access on all of a victim's sync-enabled devices. To mitigate this issue, Chrome only syncs extensions that have been installed from the Chrome Web Store. Extensions in the Chrome Web Store are monitored for abusive behavior. In the future, we may pursue further mitigations. However, because an attacker must already have the victim‘s Google credentials and/or [physical access to a device][physically-local-attacks], we don’t consider this attack a security vulnerability. We **do** consider it a vulnerability if an attacker can get an extension to sync to a victim‘s device without either of the above preconditions. For example, we consider it a vulnerability if an attacker could craft a request to Google’s sync servers without proper credentials that causes an extension to be installed to a user's device, or if an attacker could entice a victim to visit a webpage that causes an extension to be installed on their device(s). Please report any such bugs [here][new-security-bug]. ### Why do some permissions (and APIs) requested by developers not display a permission warning? Permissions and APIs may not have an associated warning for a number of reasons. There is not a 1-to-1 mapping of permissions listed in the manifest and warnings shown to the user. Some permissions may grant innocuous capabilities to extensions. For instance, the `storage` permission allows an extension to store _its own data_. This does not grant the extension access to any additional data; further, this type of behavior is already possible using open web APIs like `localStorage` and Indexed DB. Since this does not provide the extension any access to any new data or dangerous capabilities, the API does not have an associated warning. Other permissions, like `webRequest`, may only apply to sites the extension has access to. The webRequest API allows extensions to monitor (and potentially modify) network requests made by web pages. However, an extension can _only_ intercept these requests for sites it has access to. Requesting access to a site already displays a permission warning ("Read and change your data on "); the webRequest API does not provide any additional access. This is also the case for the `scripting` permission and others. Some APIs may also have runtime permission prompts, such as dialogs or choosers, that are shown to the user in context. Since these APIs do not immediately grant any data access to extensions, no permission warning is shown. Finally, some permissions may be subsumed by other, more powerful, permissions. For instance, if an extension has access to the history API (which allows extensions to read and change a user's browsing history), we do not also show a warning for the `topSites` API (which allows extensions to see the top sites a user has visited). Since the history API is strictly more powerful, it subsumes the `topSites` API. You can read more [here](https://chromium.googlesource.com/chromium/src/+/main/extensions/docs/permissions.md#Determining-Permission-Warnings). ### Why do optional permissions not display a permission warning at install time? Permissions listed in the `optional\_permissions` key in the manifest are not granted to the extension at install-time. Instead, they are granted through the use of the [Permissions API](https://developer.chrome.com/docs/extensions/reference/permissions/). When the extension requests new capabilities (i.e., permissions that have not been previously granted and are not superseded by other granted permissions), a dialog is shown to the user, allowing them to grant or refuse the permissions. ### If an extension is updated to include new permissions, are users notified? If an extension updates and includes new permissions that are not already contained within its current granted capabilities, the extension is disabled on users' machines and the user is notified (and asked if they'd like to grant the new permissions and enable the extension). You can read more [here](https://chromium.googlesource.com/chromium/src/+/main/extensions/docs/permissions.md#Permission-Increases). This does not apply to newly-requested optional permissions, which are not granted by default. ### I've found / written an extension that can execute code from a remote server. Is this a security bug? This is not considered a security bug in Chromium ([example](https://crbug.com/1025017)). Prior to Manifest Version 3, extensions were allowed to execute code that was not contained in the extension package (also called remotely-hosted code); this is a pattern that is extremely common in web development. Beginning in Manifest Version 3, all logic must be contained within the extension package for developers distributing through the Chrome Web store; however, this is a _policy_ requirement (described [here](https://developer.chrome.com/docs/webstore/program_policies/)), and is not enforced by the Chromium browser. While the platform includes some restrictions through the inclusion of a default content security policy for extensions, this is not meant to be a guaranteed deterrent, and does not prevent all types of remote code execution. For instance, it is impossible for the Chromium browser to guard against an extension that includes an interpreter that processes remotely-fetched JSON commands, even though this type of behavior is prohibited by policy in Manifest V3. ### Why do we allow extensions to open or close chrome:-scheme pages? Web pages with the chrome:-scheme (such as chrome://settings) are generally protected from extensions - extensions are not allowed to read or change data on these pages (without the use of the `--extensions-on-chrome-urls` command line flag). However, extensions _are_ allowed to open and close these pages through APIs like the tabs and windows APIs. This is critical for certain types of extensions, such as tab and session managers, bookmark managers, and history managers. ### Why are extensions allowed to bypass a web page's Content Security Policy? Extensions are considered more privileged than the web pages they are allowed to run on. As such, they are allowed to circumvent restrictions put in place by those web pages. This can be critical for extension functionality. ### Is executing in the main world of a document a security bug? No ([example](https://bugs.chromium.org/p/chromium/issues/detail?id=760419)). By default, extension scripts (like content scripts and those injected with [tabs.executeScript()](https://developer.chrome.com/docs/extensions/reference/tabs/#method-executeScript) or [scripting.executeScript()](https://developer.chrome.com/docs/extensions/reference/scripting/#method-executeScript) execute in an isolated world. However, this is _not_ intended as a security boundary to protect the main page from the extension (rather, it is a soft boundary in the other direction, _slightly_ protecting the extension from the webpage and other extensions active on the page). More than anything else, this is designed to prevent collision of JavaScript variables, so that `foo` in the content script does not reference `foo` from the main world. Extensions can trivially execute in the main world of a document if they so desire - for instance, by appending a `