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:

• Read our core security principles, which we try to follow in all security work we do.
• Check out our security brag sheet, which lists some of the technologies and recognition we're most proud of.
• Check out some of the work we're doing to detect and prevent security bugs, ensure that Chromium is secure by design and resilient to exploitation, and make security easier for users and developers.
• Peruse the Security FAQ for answers to common questions.
• Learn about how Security Reviews work in Chrome.
• Check out some of our Chrome-specific security education documentation.
• Check out the PDFium Security page, too.
• Here is the canonical "prefer secure origins for powerful new features" proposal text.
• Here is the canonical "Marking HTTP As Non-Secure" proposal text.
• Have a look at our public Chrome Security Google Drive folder, which contains a whole bunch of useful documents as well.
• We provide quarterly updates to what we're working on, if anything piques your interest get in touch!
• Find out about our memory safety work.

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 sheriff, be 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 security@chromium.org. 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).
• [required]: A need to access information about unfixed Chromium security bugs in order to build defenses which will benefit multiple products that embed Chromium.

The final criterion above can be demonstrated by a strong organizational track record of benefiting Chromium security, such that it would be clearly obstructive for an individual to lack access. For example, if an organization were comprehensively responsible for all Chromium fuzzing, or all of Chromium supply chain security, it would be obviously necessary for some individuals to have access to all security bug information.

To apply for membership, please email security@chromium.org.

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 security@chromium.org. 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. (This is known as "security-notify" access).

Individuals with such “security-notify” access may additionally request access to non-embargoed vulnerabilities which are not yet fixed, for which there's evidence of an exploit existing in the wild. (This is known as "security-notify-itw" access). The intention here is to allow these extra-urgent fixes to be distributed to users with minimal delay. To apply for this extra membership, we require evidence that your users receive all important security fixes very rapidly, and will therefore benefit from a further reduced fix time for these fixes.

This evidence must be provided at least every six months and must cover (at least) all high severity fixes (not just those with evidence of in-the-wild exploitation). There's no set format for this evidence, but an example might be a table showing the date each high-severity, stable-impacting fix was made available to your users. Other equivalent information is also acceptable. Request and justification artifacts for this membership should be sent to security@chromium.org.

Irrespective of membership of these groups, individuals are often granted access to specific Chromium security bugs which they may be able to help fix or progress.

There is one simple rule for any party granted advance access to security vulnerabilities in Chromium: any details of a vulnerability should be considered confidential until the vulnerability is responsibly disclosed by the Chromium project. Information may only be shared with parties who need to know in order to defend Chromium or directly related software or hardware. 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 immediately for any member who fails to comply with this rule in letter or spirit.