Chromium‎ > ‎

Chromium Security

The Chromium security team aims to provide Chrome and Chrome OS users with the most secure platform to navigate the web, and just generally make the Internet a safer place to hang out. We work on solutions for the biggest user / ux security problems, drive secure architecture design and implementation projects for the Chromium platform, find and help fix security bugs, help developers to create more secure apps, and act as a general security consulting / review group for the larger Chromium project. 

To learn more:

How can I get involved?

Find bugs
One of the quickest ways to get involved is finding and reporting security bugs. It will get prompt attention from a security sheriffbe kept private until we coordinate disclosure, and possibly qualify for a cash reward through our Vulnerability Rewards Program. We occasionally run security contests outside of our regular reward program (e.g. Pwnium2, Pwnium3) too.

For any issues other than a specific bug, email us at For non-confidential discussions, please post to the technical discussion forums, including the public security-dev list for technical discussions.

Become a committer
We encourage interested parties to work towards becoming a committer. There are many types of security related patch that we're excited to collaborate on:
  • Fixes for any security bugs you discover.
  • Implementing or improving security features, including security-related web platform features (examples: iframe sandbox, XSS auditor, CSP).
  • Implementing or improving security hardening measures (examples: defensive checks, allocator improvements, ASLR improvements).
Become an IPC reviewer
Bugs in IPC can have nasty consequences, so we take special care to make sure additions or changes to IPC avoid common security pitfalls. If you want to get involved, check out how to become an IPC reviewer here.

Join the team
Access to Chromium security bugs and our team mailing list is restricted, for obvious reasons. Before applying to join the team, applicants must be committers and are expected to have made and continue to make active and significant contributions to Chromium security. You should demonstrate some of the following before applying:
  • Relevant technical expertise and a history of patches that improve Chromium security.
  • A history of identifying and responsibly reporting Chromium security vulnerabilities.
  • Other expertise and/or roles that would allow the applicant to significantly contribute to Chromium security on a regular basis.
  • [required]: Be a committer, and have no personal or professional association that is an ethical conflict of interest (e.g. keeping vulnerabilities or exploits private, or sharing with parties other than the vendor).
To apply for membership, please email 

How can I get access to Chromium vulnerabilities?
A history of fixed Chromium security bugs is best found via security notes in Stable Channel updates on the Google Chrome releases blog. You can also find fixed, publicly visible Type=Bug-Security bugs in the issue tracker (note: security bugs automatically become publicly visible 14 weeks after they are fixed). All security bugs are rated according to our severity guidelines, which we keep in line with industry standards.

Advance notice of (fixed) Chromium security vulnerabilities is restricted to those actively building significantly deployed products based upon Chromium, or including Chromium as part of bundled software distributions. If you meet the criteria, and require advanced notice of vulnerabilities, request access via Your email should explain your need for access (embedder, Linux distribution, etc.) and your continued access will require that you follow the terms of list membership.

There is one simple rule for any party with advance access to security vulnerabilities in Chromium: any details of a vulnerability should be considered confidential and only shared on a need to know basis until such time that the vulnerability is responsibly disclosed by the Chromium project. Additionally, any vulnerabilities in third-party dependencies (e.g. Blink, open source parser libraries, etc.) must be treated with the same consideration. Access will be terminated for any member who fails to comply with this rule in letter or spirit.