Content Security Policy

Extensions developed with WebExtension APIs have a Content Security Policy (CSP) applied to them by default. This restricts the sources from which they can load code such as

Compared to a website, extensions have access to additional privileged APIs, so if they are compromised by malicious code, the risks are greater. For this reason:

a fairly strict content security policy is applied to extensions by default. See default content security policy.
the extension's author can change the default policy using the content_security_policy manifest.json key, but there are restrictions on the policies that are allowed. See content_security_policy.

Default content security policy

The default content security policy for extensions using Manifest V2 is:

"script-src 'self'; object-src 'self';"

While for extensions using Manifest V3, the default content security policy is:

"script-src 'self'; upgrade-insecure-requests;"

These policies are applied to any extension that has not explicitly set its own content security policy using the content_security_policy manifest.json key. It has the following consequences:

You may only load

This doesn't load the requested resource: it fails silently, and any object that you expect to be present from the resource is not found. There are two main solutions to this:

download the resource, package it in your extension, and refer to this version of the resource.

allow the remote origin you need using the content_security_policy key or, in Manifest V3, the content_scripts property.

Note: If your modified CSP allows remote script injection, your extension will get rejected from addons.mozilla.org (AMO) during the review. For more information, see details about security best practices.

eval() and friends

Under the default CSP, extensions cannot evaluate strings as JavaScript. This means that the following are not permitted:

eval("console.log('some output');");

setTimeout("alert('Hello World!');", 500);

const f = new Function("console.log('foo');");

Inline JavaScript

Under the default CSP, inline JavaScript is not executed. This disallows both JavaScript placed directly in

html

Click me!

If you are currently using code like to run your script when the page has loaded, listen for DOMContentLoaded or load instead.

WebAssembly

Extensions wishing to use WebAssembly require 'wasm-unsafe-eval' to be specified in the script-src directive.

From Firefox 102 and Chrome 103, 'wasm-unsafe-eval' can be included in the content_security_policy manifest.json key to enable the use of WebAssembly in extensions.

Manifest V2 extensions in Firefox can use WebAssembly without 'wasm-unsafe-eval' in their CSP for backward compatibility. However, this behavior isn't guaranteed, see Firefox bug 1770909. Extensions using WebAssembly are therefore encouraged to declare 'wasm-unsafe-eval' in their CSP.

For Chrome, extensions cannot use WebAssembly in version 101 or earlier. In 102, extensions can use WebAssembly (the same behavior as Firefox 101 and earlier). From version 103, extensions can use WebAssembly if they include 'wasm-unsafe-eval' in the content_security_policy in the manifest key.

Upgrade insecure network requests in Manifest V3

Extensions should use https: and wss: when communicating with external servers. To encourage this as the standard behavior, the default Manifest V3 CSP includes the upgrade-insecure-requests directive. This directive automatically upgrades network requests to http: to use https:.

While requests are automatically upgraded, it is still recommended to use https:-URLs in the extension's source code where possible. In particular, entries in the host_permissions section of manifest.json should start with https:// or *:// instead of only http://.

Manifest V3 Extensions that need to make http: or ws: requests can opt out of this behavior by overriding the default CSP using the content_security_policy manifest.json key with a policy that excludes the upgrade-insecure-requests directive. However, to comply with the security requirements of the Add-on Policies, all user data must be transmitted securely.

CSP for content scripts

In Manifest V2, content scripts have no CSP. As of Manifest V3, content scripts share the default CSP as extensions. It is currently not possible to specify a separate CSP for content scripts (source).

The extent to which the CSP controls loads from content scripts varies by browser. In Firefox, JavaScript features such as eval are restricted by the extension CSP. Generally, most DOM-based APIs are subjected to the CSP of the web page. In Chrome, many DOM APIs are covered by the extension CSP instead of the web page's CSP (crbug 896041).

\n\n \n \n \n\n\n

Compared to a website, extensions have access to additional privileged APIs, so if they are compromised by malicious code, the risks are greater. For this reason:\n

a fairly strict content security policy is applied to extensions by default. See default content security policy.\n
the extension's author can change the default policy using the content_security_policy manifest.json key, but there are restrictions on the policies that are allowed. See content_security_policy.\n"}},{"type":"prose","value":{"id":"default_content_security_policy","title":"Default content security policy","isH3":false,"content":"The default content security policy for extensions using Manifest V2 is:\n\"script-src 'self'; object-src 'self';\"\n\nWhile for extensions using Manifest V3, the default content security policy is:\n\"script-src 'self'; upgrade-insecure-requests;\"\n\nThese policies are applied to any extension that has not explicitly set its own content security policy using the content_security_policy manifest.json key. It has the following consequences:\n \nYou may only load \n\nThis doesn't load the requested resource: it fails silently, and any object that you expect to be present from the resource is not found. There are two main solutions to this:\n\ndownload the resource, package it in your extension, and refer to this version of the resource.\nallow the remote origin you need using the content_security_policy key or, in Manifest V3, the content_scripts property.\n\n\nNote:\nIf your modified CSP allows remote script injection, your extension will get rejected from addons.mozilla.org (AMO) during the review. For more information, see details about security best practices.\n"}},{"type":"prose","value":{"id":"eval_and_friends","title":"eval() and friends","isH3":true,"content":" Under the default CSP, extensions cannot evaluate strings as JavaScript. This means that the following are not permitted:\n jseval(\"console.log('some output');\");\n\njssetTimeout(\"alert('Hello World!');\", 500);\n\njsconst f = new Function(\"console.log('foo');\");\n"}},{"type":"prose","value":{"id":"inline_javascript","title":"Inline JavaScript","isH3":true,"content":"Under the default CSP, inline JavaScript is not executed. This disallows both JavaScript placed directly in \n\nhtmlClick me! \n\nIf you are currently using code like to run your script when the page has loaded, listen for DOMContentLoaded or load instead."}},{"type":"prose","value":{"id":"webassembly","title":"WebAssembly","isH3":true,"content":" Extensions wishing to use WebAssembly require 'wasm-unsafe-eval' to be specified in the script-src directive.\n From Firefox 102 and Chrome 103, 'wasm-unsafe-eval' can be included in the content_security_policy manifest.json key to enable the use of WebAssembly in extensions.\n Manifest V2 extensions in Firefox can use WebAssembly without 'wasm-unsafe-eval' in their CSP for backward compatibility. However, this behavior isn't guaranteed, see Firefox bug 1770909. Extensions using WebAssembly are therefore encouraged to declare 'wasm-unsafe-eval' in their CSP.\n For Chrome, extensions cannot use WebAssembly in version 101 or earlier. In 102, extensions can use WebAssembly (the same behavior as Firefox 101 and earlier). From version 103, extensions can use WebAssembly if they include 'wasm-unsafe-eval' in the content_security_policy in the manifest key."}},{"type":"prose","value":{"id":"upgrade_insecure_network_requests_in_manifest_v3","title":"Upgrade insecure network requests in Manifest V3","isH3":true,"content":" Extensions should use https: and wss: when communicating with external servers. To encourage this as the standard behavior, the default Manifest V3 CSP includes the upgrade-insecure-requests directive. This directive automatically upgrades network requests to http: to use https:.\n While requests are automatically upgraded, it is still recommended to use https:-URLs in the extension's source code where possible. In particular, entries in the host_permissions section of manifest.json should start with https:// or *:// instead of only http://.\n Manifest V3 Extensions that need to make http: or ws: requests can opt out of this behavior by overriding the default CSP using the content_security_policy manifest.json key with a policy that excludes the upgrade-insecure-requests directive. However, to comply with the security requirements of the Add-on Policies, all user data must be transmitted securely."}},{"type":"prose","value":{"id":"csp_for_content_scripts","title":"CSP for content scripts","isH3":false,"content":" In Manifest V2, content scripts have no CSP.\nAs of Manifest V3, content scripts share the default CSP as extensions. It is currently not possible to specify a separate CSP for content scripts (source).\n The extent to which the CSP controls loads from content scripts varies by browser.\nIn Firefox, JavaScript features such as eval are restricted by the extension CSP. Generally, most DOM-based APIs are subjected to the CSP of the web page.\nIn Chrome, many DOM APIs are covered by the extension CSP instead of the web page's CSP (crbug 896041)."}}],"isActive":true,"isMarkdown":true,"isTranslated":false,"locale":"en-US","mdn_url":"/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy","modified":"2025-04-10T14:56:07.000Z","native":"English (US)","noIndexing":false,"other_translations":[{"locale":"de","title":"Content Security Policy","native":"Deutsch"},{"locale":"fr","title":"Content Security Policy","native":"Français"},{"locale":"ja","title":"Content Security Policy","native":"日本語"},{"locale":"ru","title":"Политика защиты содержимого","native":"Русский"},{"locale":"zh-CN","title":"Content Security Policy","native":"中文 (简体)"}],"pageTitle":"Content Security Policy - Mozilla | MDN","parents":[{"uri":"/en-US/docs/Mozilla","title":"Mozilla"},{"uri":"/en-US/docs/Mozilla/Add-ons","title":"Add-ons"},{"uri":"/en-US/docs/Mozilla/Add-ons/WebExtensions","title":"Browser extensions"},{"uri":"/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy","title":"Content Security Policy"}],"popularity":null,"short_title":"Content Security Policy","sidebarHTML":" Browser extensions Getting startedWhat are extensions? Your first extension Your second extension Anatomy of an extension Example extensions What next? ConceptsJavaScript APIs Content scripts Background scripts Match patterns Work with files Internationalization Content Security Policy Native messaging Native manifests User actions Differences between API implementations Chrome incompatibilities User interfaceToolbar button Address bar button Sidebars Context menu items Options page Extension pages Notifications Address bar suggestions devtools panels Browser styles Popups How toIntercept HTTP requests Modify a web page Insert external content Share objects with page scripts Add a button to the toolbar Implement a settings page Work with the Tabs API Work with the Bookmarks API Work with the Cookies API Work with contextual identities Interact with the clipboard Extend the developer tools Build a cross-browser extension JavaScript APIsBrowser support for JavaScript APIs action alarms bookmarks browserAction browserSettings browsingData captivePortal clipboard commands contentScripts contextualIdentities cookies declarativeNetRequest devtools dns dom downloads events extension extensionTypes find history i18n identity idle management menus notifications omnibox pageAction permissions pkcs11 privacy proxy runtime scripting search sessions sidebarAction storage tabGroups tabs theme topSites types userScripts userScripts (Legacy) webNavigation webRequest windows Manifest keysaction author background browser_action browser_specific_settings chrome_settings_overrides chrome_url_overrides commands content_scripts content_security_policy declarative_net_request default_locale description developer devtools_page dictionaries externally_connectable homepage_url host_permissions icons incognito manifest_version name offline_enabled\nDeprecated\n omnibox optional_host_permissions optional_permissions options_page options_ui page_action permissions protocol_handlers short_name sidebar_action storage theme theme_experiment user_scripts version version_name web_accessible_resources Extension WorkshopDevelop Publish Manage Enterprise Contact us ChannelsAdd-ons blog Add-ons forum Add-ons chat","source":{"folder":"en-us/mozilla/add-ons/webextensions/content_security_policy","github_url":"https://github.com/mdn/content/blob/main/files/en-us/mozilla/add-ons/webextensions/content_security_policy/index.md","last_commit_url":"https://github.com/mdn/content/commit/e9b6cd1b7fa8612257b72b2a85a96dd7d45c0200","filename":"index.md"},"summary":"Extensions developed with WebExtension APIs have a Content Security Policy (CSP) applied to them by default. This restricts the sources from which they can load code such as \u003cscript> and disallows potentially unsafe practices such as using eval(). This article briefly explains what a CSP is, what the default policy is and what it means for an extension, and how an extension can change the default CSP.","title":"Content Security Policy","toc":[{"text":"Default content security policy","id":"default_content_security_policy"},{"text":"CSP for content scripts","id":"csp_for_content_scripts"}],"pageType":"guide"}}