the Chromium logo

The Chromium Projects

Reporting Security Bugs

The Chromium project takes security very seriously, but any complex software project is going to have some vulnerabilities. You can help us make Chromium more secure by following the guidelines below when filing security bugs against Chromium. And as an added benefit to you, following these guidelines will increase both the chance and size of the reward you could receive under the Vulnerability Rewards Program.


Do not report physically-local attacks. For example, please do not report that you can compromise Chromium by installing a malicious DLL on a computer in a place where Chromium will find it and load it. Similarly, please do not report password disclosure using the Inspect Element feature to convert the "*******" into the underlying text.

To understand why, see the Chromium Security FAQ.

General Guidelines

These are the criteria that we expect from a good security bug report:

Reporting Crash Bugs

In addition to the general guidelines above, we look for the following information on bugs that trigger browser crashes or sad tabs:

Signs A Crash Is Not A Security Bug

Generally, we do not consider a denial of service (DoS) issues to be security vulnerabilities. Examples of these bug classes include: consistent fixed-offset NULL pointer dereferences, call stack overflows (stack exhaustion), and out of memory (OOM) errors. Some of these crashes are valid bugs, and should be reported; however, they are not security bugs and should be filed through the normal defect template.

Going Above and Beyond

While we don't expect security vulnerability reporters to provide us any of the following information, we certainly find it extremely helpful and would take it into consideration when determining whether or not a particular report qualified for a larger award:

Bug Visibility

The visibility of security bugs is restricted until a fix has been widely deployed. For more information see the Security FAQ.