Security and Privacy: Best Practices on Building a Chrome Extension

By   ISBuzz Team
Writer , Information Security Buzz | May 27, 2015 06:00 pm PST

As Chrome continues to eat the marketshare of browsers, the security and privacy implications of Chrome extensions will become even more prominent. Chrome extensions can be powerful because they can run arbitrary Javascript inside any web pages. If the user grants additional permissions, an extension can access sensitive information such as all HTTP requests, clipboard, cookies, and beyond. These powerful permissions can be valuable to developers of Chrome extensions, but at the same time present security and privacy implications for users.

The Chrome web store, which has historically relied on users themselves to safeguard their own security, has stepped up their game in protecting users by cleaning the Chrome web store of adwares, enhancing the screening process, and controlling sources of distribution.

As developers of Chrome extensions, it is really important to follow the best practices to ensure the security and privacy of our users in order to keep their trust. On the security side, developers should:

  • Store user credentials securely. A malicious Chrome extension can bypass safeguards that are effective against regular web attacks. Sensitive information should be protected from malicious software, including not only websites, but also Chrome extensions.
  • Abide by major web-security standards. Since Chrome extensions are technically web applications, following the same security principals goes a long way. XSRF protection, avoiding unsafe eval() function in Javascript are just a few good practices.
  • Never compromise the security of an existing webpage. Since Chrome extensions can access all the DOM, cookies, and web requests on a web page a user visits, it is easy to compromise a web page’s security unintentionally by modifying HTML or other information.

On the privacy side:

  • Only ask for permissions that are necessary. Fewer permissions means less exposure of user privacy, lower adoption drop-off, and fewer security holes. There are ways to incrementally ask for new permissions without compromising user retention.

Security: How to store user credentials securely

Developers can leverage chrome.identity API to store user credentials. A Chrome extension usually makes API requests to external resources. A best practice is to store an OAuth API token. Such tokens can perform authorized requests on behalf of users without user names / passwords, and can be revoked by the user anytime.

Chrome API provides a chrome.identity service, which provides a secure way for an extension to authenticate, fetch and refresh tokens. This API enables a user to perform authentication against a third-party service. Chrome can interactively display a popup UI, which:

  • Can store cookies and session information
  • Is protected against any script injection, even by other Chrome extensions

Each Chrome extension has its own chrome.identity instance, and is only accessible by the Chrome extension owning that instance. This makes the token private, even from other malicious Chrome extensions.

Permissions: how to incrementally ask for new permissions?

The traditional / sub-optimal practice is to ask for all permissions up front. Here we introduce the “Optional Permissions”, which allows developers to ask for permissions incrementally.

The Sub-optimal “Request Everything on-Install” Experience

The Chrome API provides a wealth of permissions for a Chrome extension, from querying a device’s CPU metadata to accessing clipboard history, from keeping a device from asleep, to accessing all HTTP requests… You name it, they have it.

The likelihood of a user agreeing blindly, together with the risk of being disabled by Chrome makes it tempting for developers to over-request permissions, thinking that “some day” these permissions may be used.

The Chrome web store presents a user with all required permissions on install. At that particular moment, a user is presented a binary decision of accepting or denying the permissions. Let’s be honest, in most cases a user will accept the permissions request without even reading the overwhelmingly long list.




What also contributes to the problem of over-requested permissions is that, if a Chrome extension happens to require an additional required permission in a later release, Chrome will disable the extension and ask the user to confirm new permissions in a tip, which the user usually ignores unintentionally. The next morning when you check the retention dashboard, you will find your extension’s DAU suddenly dropped 50%.

However, over-privileged apps not only overwhelm the user at the permissions request screen, but also potentially reduce security if the extension is exploited by malicious software.

Making Permissions “Optional”

The good news is that the Chrome API provides the “Optional Permissions”, which:

  • Lets the app request for additional permissions proactively
  • Avoids the “disable” issue if all new permissions are “optional” in an update

At RelateIQ, when we released the Read Receipts feature as part of our Chrome extension, we needed to request one additional permission. We successfully solved this problem by requesting it as an optional permission.

Best Practices of Asking “Optional Permissions”

Since the “Optional Permission” lets the app proactively ask for new permissions, it provides the opportunity to explain to the user why the new permission is requested. If an additional permission is critical to a new feature, the best practice to ask for the new permission is to:

  • Ask only when a user triggers an action that absolutely requires the new permission
  • Explain clearly what the user gets in return

… in order to maximize the likelihood of a user accepting a new permission.

These are just a few of the things I’ve learned as I’ve built and expanded on our own Chrome extension at RelateIQ. What else would you add?

By Keven Wang, Software Engineer at RelateIQ

About RelateIQ

RelateIQRelateIQ, a subsidiary of, is an American enterprise software company based in Palo Alto, California. The company’s software is a relationship intelligence platform that combines data from email systems, smartphone calls, and appointments to augment or replace standard relationship management tools or database solutions. It scans “about 10,000 emails, calendar entries, and other data points per minute at first run”.In July 2014, announced plans to acquire the company for close to $400 million. Industry insiders predict that the acquisition will bulk up’s data science offering, enabling the world’s #1 CRM provider to compete amid rapidly changing enterprise software requirements. One article on the acquisition states, “If RelateIQ fulfills its promises of stopping team members from accidentally emailing the same queries to clients or customers, or allows salespeople to decipher the corporate hierarchies of their potential contacts through algorithms, there could be some lasting changes to the world of sales.

Notify of
0 Expert Comments
Inline Feedbacks
View all comments

Recent Posts

Would love your thoughts, please comment.x