Test the new Content Security Policy for Content Scripts

As part of our efforts to make add-ons safer for users, and to support evolving manifest v3 features, we are making changes to apply the Content Security Policy (CSP) to content scripts used in extensions. These changes will make it easier to enforce our long-standing policy of disallowing execution of remote code.

When this feature is completed and enabled, remotely hosted code will not run, and attempts to run them will result in a network error. We have taken our time implementing this change to decrease the likelihood of breaking extensions and to maintain compatibility. Programmatically limiting the execution of remotely hosted code is an important aspect of manifest v3, and we feel it is a good time to move forward with these changes now.

We have landed a new content script CSP, the first part of these changes, behind preferences in Firefox 72. We’d love for developers to test it out to see how their extensions will be affected.

Testing instructions

Using a test profile in Firefox Beta or Nightly, please change the following preferences in about:config:

  • Set extensions.content_script_csp.enabled to true
  • Set extensions.content_script_csp.report_only to false to enable policy enforcement

This will apply the default CSP to the content scripts of all installed extensions in the profile.

Then, update your extension’s manifest to change your content_security_policy. With the new content script CSP,  content_scripts works the same as extension_pages. This means that the original CSP value moves under the extension_pages key and the new content_scripts key will control content scripts.

Your CSP will change from something that looks like:

content_security_policy: "script-src 'self'; object-src 'none'"

To something that looks like:

content_security_policy: {
  extension_pages: "script-src 'self'; object-src 'none'",
  content_scripts: "script-src 'self'; object-src 'none'"
}

Next, load your extension in about:debugging. The default CSP now applied to your content scripts will prevent the loading of remote resources, much like what happens when you try to  insert an image into a website over http, possibly causing your extension to fail. Similar to the old content_security_policy (as documented on MDN), you may make changes using the content_scripts key.

Please do not loosen the CSP to allow remote code, as we are working on upcoming changes to disallow remote scripts.

As a note, we don’t currently support any other keys in the content_security_policy object. We plan to be as compatible as possible with Chrome in this area will support the same key name they use for content_scripts in the future.

Please tell us about your testing experience on our community forums. If you think you’ve found a bug, please let us know on Bugzilla.

Implementation timeline

More changes to the CSP for extensions are expected to land behind preferences in the upcoming weeks. We will publish testing instructions once those updates are ready. The full set of changes should be finished and enabled by default in 2020, meaning that you will be able to use the new format without toggling any preferences in Firefox.

Even after the new CSP is turned on by default, extensions using manifest v2 will be able to continue using the string form of the CSP. The object format will only be required for extensions that use manifest v3 (which is not yet supported in Firefox).

There will be a transition period when Firefox supports both manifest v2 and manifest v3 so that developers have time to update their extensions. Stay tuned for updates about timing!

10 comments on “Test the new Content Security Policy for Content Scripts”

  1. Stig Nygaard wrote on

    Trying to understand. Isn’t the CSP rules mentioned above basically the same before and after?

    Post says the new configuration can be tested in “Firefox Beta or Nightly”. Does that include the Developer Edition? I guess it will, what else is the idea with a Dev.Edition?

    1. Philipp Kewisch wrote on

      The CSP before applied only to background scripts, not content scripts. The example before/after is very similar, but the object syntax allows you to specify a CSP for background scripts as before (`extension_pages`) and a separate CSP for content scripts (`content_scripts`). More on the reply to your next comment, thank you for bringing up these valuable questions!

  2. Stig Nygaard wrote on

    …and even after the about:confi configuration change, I will still need to insert these lines myself into my manifest?:

    content_security_policy: {
    extension_pages: “script-src ‘self’; object-src ‘none'”,
    content_scripts: “script-src ‘self’; object-src ‘none'”
    }

    1. Philipp Kewisch wrote on

      In most cases you will not have to insert this into your manifest. Setting the prefs will apply the default CSP, which is sufficiently strict to disallow remote scripts. The examples are provided for information on how to change the CSP in case you’d like to make it more strict, or (for testing purposes) loosen the CSP.

  3. Stig Nygaard wrote on

    …and another question 🙂 …

    What about older versions of Firefox when manifest v3 is introduced? If I upgrade my webextension to use manifest v3, will it still be installable on older versions of firefox, like f.ex. Firefox 68 ESR ? Or will I have to keep using v2 for compatibility with older versions of Firefox?

    1. Philipp Kewisch wrote on

      The time frame between v3 being available in release and v2 no longer being supported will likely be long enough that there will be at least one ESR that supports both v2 and v3. Google is still in the design and feedback phase for some of the changes, so this will be a bit down the line. You can read more about our current position on v3 here: https://blog.mozilla.org/addons/2019/09/03/mozillas-manifest-v3-faq/ Once we have an update on v3 we’ll talk about it here on this blog.

  4. LAKSHIT LOHAR wrote on

    What about older versions of Firefox when manifest v3 is introduced? If I upgrade my webextension to use manifest v3, will it still be installable on older versions of firefox, like f.ex. Firefox 68 ESR ? Or will I have to keep using v2 for compatibility with older versions of Firefox?

    1. Philipp Kewisch wrote on

      We are of course interested in maximizing ESR support for Manifest v3, but as with any software feature there is a limit to what we can backport to old versions. Therefore, we don’t expect that the majority of Manifest v3 features will be available in Firefox 68. That said, the cycle in which both v2 and v3 will be supported will likely be fairly long, so there will be enough time to upgrade. My hope is that by the time all v3 features are available, the then current ESR will support them as well.

  5. Vincent wrote on

    > Please do not loosen the CSP to allow remote code, as we are working on upcoming changes to disallow remote scripts.

    What is considered a remote script? The bug mentions:

    > script-src, worker-src, object-src, and style-src with non-local values are disallowed.

    (https://bugzilla.mozilla.org/show_bug.cgi?id=1594234)

    Does that mean that frame-src will still be allowed to point to non-local values?

    1. Philipp Kewisch wrote on

      iframes are still allowed and I believe the default csp won’t disallow it. You’ll get a chance to test this soon. If the remote iframe is used to execute remote scripts this is still disallowed by policy.