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.
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 email@example.com. 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 firstname.lastname@example.org.
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 email@example.com. 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.