Security is one of our core values, alongside speed, stability and simplicity. From day one, we’ve designed Chrome’s extension system with security in mind. Since we launched the extension system, the state of the art in web security has advanced with technologies like Content-Security-Policy (CSP). Extension developers have been able to opt into these features, and now we’re enabling these security features by default.

Unfortunately, securing extensions with CSP by default is incompatible with the legacy extension system. We’re passionate about extension compatibility, so we’re going to make this change gradually to minimize pain for users and developers.

Users can continue to install extensions that are available in the store regardless of whether they are secured with CSP or not. This means they will not lose any of the functionality they've added to Chrome.

Developers will be able to choose when to enable the new behavior. To ease the transition, we've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use manifest_version 2, Chrome will enforce the following CSP policy by default:

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

This policy imposes the following restrictions on extensions:

1. Extensions can no longer use inline scripts, such as <script> ... </script>. Instead, extensions must use out-of-line scripts loaded from within their package, such as <script src="foo.js"></script>. 
2. Extensions can no longer use eval(). Note: If you’re using eval to parse JSON today, we suggest using JSON.parse instead. 
3. Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts. 

A recent study from researchers at UC Berkeley suggested that these restrictions, taken together, would substantially improve the security of the extension system:

These defenses are extremely effective: adopting one of the recommended CSPs would prevent 96% (49 out of 51) of the core extension vulnerabilities we found. 

For most extensions, updating them to manifest_version 2 will require the developer to move inline scripts out-of-line and to move scripts loaded from the network into the extension package. Developers are not required to update their extensions to manifest_version 2 immediately, but, over time, more of the extension ecosystem will encourage developers to update their extensions. For example, at some point, we’ll likely start requiring new extensions uploaded to the web store to use manifest_version 2. You can find a complete list of changes and more details about CSP in the extension documentation.

We expect these changes will make the security of Chrome’s extension system even better. If you have any feedback, please feel encouraged to email the extension developers mailing list.


Posted by Adam Barth, Chrome Security Engineer