Chrome Security FAQ


Which bugs are valid for rewards under the Chrome Vulnerability Rewards program?

Please see the VRP FAQ page.

Why are security bugs hidden in the Chromium issue tracker?

We must balance a commitment to openness with a commitment to avoiding unnecessary risk for users of widely-used open source libraries.

Can you please un-hide old security bugs?

Our goal is to open security bugs to the public once the bug is fixed and the fix has been shipped to a majority of users. However, many vulnerabilities affect products besides Chromium, and we don’t want to put users of those products unnecessarily at risk by opening the bug before fixes for the other affected products have shipped.

Therefore, we make all security bugs public within approximately 14 weeks of the fix landing in the Chromium repository. The exception to this is in the event of the bug reporter or some other responsible party explicitly requesting anonymity or protection against disclosing other particularly sensitive data included in the vulnerability report (e.g. username and password pairs).

Can I get advance notice about security bugs?

Vendors of products based on Chromium, distributors of operating systems that bundle Chromium, and individuals and organizations that significantly contribute to fixing security bugs can be added to a list for earlier access to these bugs. You can email us at to request to join the list if you meet the above criteria. In particular, vendors of anti-malware, IDS/IPS, vulnerability risk assessment, and similar products or services do not meet this bar.

Please note that the safest version of Chrome/Chromium is always the latest stable version — there is no good reason to wait to upgrade, so enterprise deployments should always track the latest stable release. When you do this, there is no need to further assess the risk of Chromium vulnerabilities: we strive to fix vulnerabilities quickly and release often.

How can I know which fixes to include in my downstream project?

Chrome is built with mitigations and hardening which aim to prevent or reduce the impact of security issues. We classify bugs as security issues if they are known to affect a version and configuration of Chrome that we ship to the public. Some classes of bug might present as security issues if Chrome was compiled with different flags, or linked against a different C++ standard library, but do not with the toolchain and configuration that we use to build Chrome. We discuss some of these cases elsewhere in this FAQ.

If we become aware of them, these issues may be triaged as Type=Vulnerability, Security_Impact-None or as Type=Bug because they do not affect the production version of Chrome. They may or may not be immediately visible to the public in the bug tracker, and may or may not be identified as security issues. If fixes are landed, they may or may not be merged from HEAD to a release branch. Chrome will only label, fix and merge security issues in Chrome, but attackers can still analyze public issues, or commits in the Chromium project to identify bugs that might be exploitable in other contexts.

Chromium embedders and other downstream projects may build with different compilers, compile options, target operating systems, standard library, or additional software components. It is possible that some issues Chrome classifies as functional issues will manifest as security issues in a product embedding Chromium - it is the responsibility of any such project to understand what code they are shipping, and how it is compiled. We recommend using Chrome's configuration whenever possible.

Can I see these security bugs so that I can back-port the fixes to my downstream project?

Many developers of other projects use V8, Chromium, and sub-components of Chromium in their own projects. This is great! We are glad that Chromium and V8 suit your needs.

We want to open up fixed security bugs (as described in the previous answer), and will generally give downstream developers access sooner. However, please be aware that backporting security patches from recent versions to old versions cannot always work. (There are several reasons for this: The patch won‘t apply to old versions; the solution was to add or remove a feature or change an API; the issue may seem minor until it’s too late; and so on.) We believe the latest stable versions of Chromium and V8 are the most stable and secure. We also believe that tracking the latest stable upstream is usually less work for greater benefit in the long run than backporting. We strongly recommend that you track the latest stable branches, and we support only the latest stable branch.

How does the Chrome team determine severity of security bugs?

See the severity guidelines for more information. Only security issues are considered under the security vulnerability rewards program. Other types of bugs, which we call “functional bugs”, are not.

Threat Model

Are timing attacks considered security vulnerabilities?

Some timing attacks are considered security vulnerabilities, and some are considered privacy vulnerabilities. Timing attacks vary significantly in terms of impact, reliability, and exploitability.

Some timing attacks weaken mitigations like ASLR (e.g. Issue 665930). Others attempt to circumvent the same origin policy, for instance, by using SVG filters to read pixels cross-origin (e.g. Issue 686253 and Issue 615851).

Many timing attacks rely upon the availability of high-resolution timing information Issue 508166; such timing data often has legitimate usefulness in non-attack scenarios making it unappealing to remove.

Timing attacks against the browser‘s HTTP Cache (like Issue 74987) can potentially leak information about which sites the user has previously loaded. The browser could attempt to protect against such attacks (e.g. by bypassing the cache) at the cost of performance and thus user-experience. To mitigate against such timing attacks, end-users can delete browsing history and/or browse sensitive sites using Chrome’s Incognito or Guest browsing modes.

Other timing attacks can be mitigated via clever design changes. For instance, Issue 544765 describes an attack whereby an attacker can probe for the presence of HSTS rules (set by prior site visits) by timing the load of resources with URLs “fixed-up” by HSTS. Prior to Chrome 64, HSTS rules were shared between regular browsing and Incognito mode, making the attack more interesting. The attack was mitigated by changing Content-Security-Policy such that secure URLs will match rules demanding non-secure HTTP urls, a fix that has also proven useful to help to unblock migrations to HTTPS. Similarly, Issue 707071 describes a timing attack in which an attacker could determine what Android applications are installed; the attack was mitigated by introducing randomness in the execution time of the affected API.

What if a Chrome component breaks an OS security boundary?

If Chrome or any of its components (e.g. updater) can be abused to perform a local privilege escalation, then it may be treated as a valid security vulnerability.

Running any Chrome component with higher privileges than intended is not a security bug and we do not recommend running Chrome as an Administrator on Windows, or as root on POSIX.

What is Chrome's threat model for fingerprinting?

Update, August 2019: Please note that this answer has changed. We have updated our threat model to include fingerprinting.

Although we do not consider fingerprinting issues to be security vulnerabilities, we do now consider them to be privacy bugs that we will try to resolve. We distinguish two forms of fingerprinting.

  • Passive fingerprinting refers to fingerprinting techniques that do not require a JavaScript API call to achieve. This includes (but is not limited to) mechanisms like ETag cookies and HSTS cookies.
  • Active fingerprinting refers to fingerprinting techniques that do require a JavaScript API call to achieve. Examples include most of the techniques in EFF's Panopticlick proof of concept.

For passive fingerprinting, our ultimate goal is (to the extent possible) to reduce the information content available to below the threshold for usefulness.

For active fingerprinting, our ultimate goal is to establish a privacy budget and to keep web origins below the budget (such as by rejecting some API calls when the origin exceeds its budget). To avoid breaking rich web applications that people want to use, Chrome may increase an origin's budget when it detects that a person is using the origin heavily. As with passive fingerprinting, our goal is to set the default budget below the threshold of usefulness for fingerprinting.

These are both long-term goals. As of this writing (August 2019) we do not expect that Chrome will immediately achieve them.

For background on fingerprinting and the difficulty of stopping it, see Arvind Narayanan's site and Peter Eckersley's discussion of the information theory behind Panopticlick. There is also a pretty good analysis of in-browser fingerprinting vectors.

I found a phishing or malware site not blocked by Safe Browsing. Is this a security vulnerability?

Malicious sites not yet blocked by Safe Browsing can be reported via Safe Browsing is primarily a blocklist of known-unsafe sites; the feature warns the user if they attempt to navigate to a site known to deliver phishing or malware content. You can learn more about this feature in these references:

In general, it is not considered a security bug if a given malicious site is not blocked by the Safe Browsing feature, unless the site is on the blocklist but is allowed to load anyway. For instance, if a site found a way to navigate through the blocking red warning page without user interaction, that would be a security bug. A malicious site may exploit a security vulnerability (for instance, spoofing the URL in the Location Bar). This would be tracked as a security vulnerability in the relevant feature, not Safe Browsing itself.

I can download a file with an unsafe extension and it is not classified as dangerous - is this a security bug?

Chrome tries to warn users before they open files that might modify their system. What counts as a dangerous file will vary depending on the operating system Chrome is running on, the default set of file handlers, Chrome settings, Enterprise policy and verdicts on both the site and the file from Safe Browsing. Because of this it will often be okay for a user to download and run a file. However, if you can clearly demonstrate how to bypass one of these protections then we’d like to hear about it. You can see if a Safe Browsing check happened by opening chrome://safe-browsing before starting the download.

What about dangerous file types not listed in the file type policy?

The file type policy controls some details of which security checks to enable for a given file extension. Most importantly, it controls whether we contact Safe Browsing about a download, and whether we show a warning for all downloads of that file type. Starting in M74, the default for unknown file types has been to contact Safe Browsing. This prevents large-scale abuse from a previously unknown file type. Starting in M105, showing a warning for all downloads of an extension became reserved for exceptionally dangerous file types that can compromise a user without any user interaction with the file (e.g. DLL hijacking). If you discover a new file type that meets that condition, we’d like to hear about it.

I found a local file or directory that may be security-sensitive and is not blocked by File System Access API - is this a security bug?

The File System Access API maintains a blocklist of directories and files that may be sensitive such as systems file, and if user chooses a file or a directory matching the list on a site using File System Access API, the access is blocked.

The blocklist is designed to help mitigate accidental granting by users by listing well-known, security-sensitive locations, as a defense in-depth strategy. Therefore, the blocklist coverage is not deemed as a security bug, especially as it requires user's explicit selection on a file or a directory from the file picker.

I can download a file with an unsafe extension but a different extension or file type is shown to the user - is this a security bug?

Extensions for downloaded files are not shown in a file dialog - is this a security bug?

The wrong description for a file type is added by Chrome - is this a security bug?

Chrome tries to let users know what they will be saving and downloading before they do so. Often operating systems will obscure a file’s type or extension and there is little we can do about that. Chrome shows information to help users make these decisions, both in Chrome-owned UI and in information that Chrome passes to OS-owned UI. If this information can be manipulated from a web site to mislead a user, then we’d like to hear about it. Example.

I can download a file and OS indicators for its provenance are not applied - is this a security bug?

Chrome attempts to label files downloaded from the internet with metadata using operating system APIs where these are available – for instance applying the Mark of the Web on Windows. This is often not possible (for instance on non-NTFS file systems on Windows, or for files inside downloaded archives) or disabled by policy. If a web site can cause Chrome to download a file without Chrome then adding this metadata as usual, we’d like to hear about it.

I can cause a hard or soft link to be written to a directory bypassing normal OS blocks - is this a security bug?

Chrome should not allow filesystem links to be created by initiating a download. Example. Example.

I can hijack a user gesture and trick a user into accepting a permission or downloading a file - is this a security bug?

Chrome tries to design its prompts to select safe defaults. If a prompt can accidentally be accepted without the user having an opportunity to make a decision about the prompt then we’d like to know. Examples might include poor defaults so that a user holding down an enter key might accept a dialog they would want to dismiss. Example.

Note that a user navigating to a download will cause a file to be downloaded.

Sandbox/CSP/etc... security properties are not inherited when navigating using the middle-click/contextual-menu - is this a security bug?

The security properties of the document providing the URL are not used/inherited when the user deliberately opens a link in a popup using one of:

  • Ctrl + left-click (Open link in new tab)
  • Shift + left-click (Open link in new window)
  • Middle-click (Open a link in a new tab)
  • Right-click > “Open link in ...”

These methods of following a link have more or less the same implications as the user copying the link's URL and pasting it into a newly-opened window. We treat them as user-initiated top-level navigations, and as such will not apply or inherit policy restrictions into the new context

Example of security related properties:

  • Content-Security-Policy
  • Cross-Origin-Embedder-Policy
  • Cross-Origin-Opener-Policy
  • Origin
  • Referrer
  • Sandbox
  • etc...

These browser's actions/shortcuts are specific to Chrome. They are different from the behavior specified by the web-platform, such as using executing or opening a link with the target=_blank attribute.

Areas outside Chrome's Threat Model

Are privacy issues considered security bugs?

No. The Chrome Privacy team treats privacy issues, such as leaking information from Incognito, fingerprinting, and bugs related to deleting browsing data as functional bugs.

Privacy issues are not considered under the security vulnerability rewards program; the severity guidelines outline the types of bugs that are considered security vulnerabilities in more detail.

What are the security and privacy guarantees of Incognito mode?

Bugs in Incognito mode are tracked as privacy bugs, not security bugs.

The Help Center explains what privacy protections Incognito mode attempts to enforce. In particular, please note that Incognito is not a “do not track” mode, and it does not hide aspects of your identity from web sites. Chrome does offer a way to send Do Not Track request to servers; see chrome://settings/?search=do+not+track

When in Incognito mode, Chrome does not store any new history, cookies, or other state in non-volatile storage. However, Incognito windows will be able to access some previously-stored state, such as browsing history.

Are XSS filter bypasses considered security bugs?

No. Chromium once contained a reflected XSS filter called the XSSAuditor that was a best-effort second line of defense against reflected XSS flaws found in web sites. The XSS Auditor was removed in Chrome 78. Consequently, Chromium no longer takes any special action in response to an X-XSS-Protection header.

Are denial of service issues considered security bugs?

No. Denial of Service (DoS) issues are treated as abuse or stability issues rather than security vulnerabilities.

  • If you find a reproducible crash (e.g. a way to hit a CHECK), we encourage you to report it.
  • If you find a site that is abusing the user experience (e.g. preventing you from leaving a site), we encourage you to report it.

DoS issues are not considered under the security vulnerability rewards program; the severity guidelines outline the types of bugs that are considered security vulnerabilities in more detail.

Why aren‘t physically-local attacks in Chrome’s threat model?

People sometimes report that they can compromise Chrome by installing a malicious DLL in a place where Chrome will load it, by hooking APIs (e.g. Issue 130284), or by otherwise altering the configuration of the device.

We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your device as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your device, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome ­— all applications must trust the physically-local user.

There are a few things you can do to mitigate risks from people who have physical control over your computer, in certain circumstances.

  • To stop people from reading your data in cases of device theft or loss, use full disk encryption (FDE). FDE is a standard feature of most operating systems, including Windows Vista and later, Mac OS X Lion and later, and some distributions of Linux. (Some older versions of Mac OS X had partial disk encryption: they could encrypt the user’s home folder, which contains the bulk of a user’s sensitive data.) Some FDE systems allow you to use multiple sources of key material, such as the combination of both a password and a key file on a USB token. When available, you should use multiple sources of key material to achieve the strongest defense. Chrome OS encrypts users’ home directories.
  • If you share your computer with other people, take advantage of your operating system’s ability to manage multiple login accounts, and use a distinct account for each person. For guests, Chrome OS has a built-in Guest account for this purpose.
  • Take advantage of your operating system’s screen lock feature.
  • You can reduce the amount of information (including credentials like cookies and passwords) that Chrome will store locally by using Chrome's Content Settings (chrome://settings/content) and turning off the form auto-fill and password storage features (chrome://settings/search#password).

There is almost nothing you can do to mitigate risks when using a public computer.

  • Assume everything you do on a public computer will become, well, public. You have no control over the operating system or other software on the machine, and there is no reason to trust the integrity of it.
  • If you must use such a computer, use Incognito mode and close all Incognito windows when you are done browsing to limit the amount of data you leave behind. Note that Incognito mode provides no protection if the system has already been compromised as described above.

Why aren‘t compromised/infected machines in Chrome’s threat model?

Although the attacker may now be remote, the consequences are essentially the same as with physically-local attacks. The attacker's code, when it runs as your user account on your machine, can do anything you can do. (See also Microsoft's Ten Immutable Laws Of Security.)

Other cases covered by this section include leaving a debugger port open to the world, remote shells, and so forth.

Does entering JavaScript: URLs in the URL bar or running script in the developer tools mean there's an XSS vulnerability?

No. Chrome does not attempt to prevent the user from knowingly running script against loaded documents, either by entering script in the Developer Tools console or by typing a JavaScript: URI into the URL bar. Chrome and other browsers do undertake some efforts to prevent paste of script URLs in the URL bar (to limit social-engineering) but users are otherwise free to invoke script against pages using either the URL bar or the DevTools console.

Does executing JavaScript from a bookmark or the Home button mean there's an XSS vulnerability?

No. Chromium allows users to create bookmarks to JavaScript URLs that will run on the currently-loaded page when the user clicks the bookmark; these are called bookmarklets.

Similarly, the Home button may be configured to invoke a JavaScript URL when clicked.

Does executing JavaScript in a PDF file mean there's an XSS vulnerability?

No. PDF files have the ability to run JavaScript, usually to facilitate field validation during form fill-out. Note that the set of bindings provided to the PDF are more limited than those provided by the DOM to HTML documents, nor do PDFs get any ambient authority based upon the domain from which they are served (e.g. no document.cookie).

Are PDF files static content in Chromium?

No. PDF files have some powerful capabilities including invoking printing or posting form data. To mitigate abuse of these capabiliies, such as beaconing upon document open, we require interaction with the document (a “user gesture”) before allowing their use.

What about URL spoofs using Internationalized Domain Names (IDN)?

We try to balance the needs of our international userbase while protecting users against confusable homograph attacks. Despite this, there are a list of known IDN display issues we are still working on.

Chrome silently syncs extensions across devices. Is this a security vulnerability?

This topic has been moved to the Extensions Security FAQ.

Why aren't null pointer dereferences considered security bugs?

Null pointer dereferences with consistent, small, fixed offsets are not considered security bugs. A read or write to the NULL page results in a non-exploitable crash. If the offset is larger than 32KB, or if there's uncertainty about whether the offset is controllable, it is considered a security bug.

All supported Chrome platforms do not allow mapping memory in at least the first 32KB of address space:

  • Windows: Windows 8 and later disable mapping the first 64k of address space; see page 33 of Exploit Mitigation Improvements in Windows 8 [archived].
  • Mac and iOS: by default, the linker reserves the first 4GB of address space with the __PAGEZERO segment for 64-bit binaries.
  • Linux: the default mmap_min_addr value for supported distributions is at least 64KB.
  • Android: CTS enforces that mmap_min_addr is set to exactly 32KB.
  • ChromeOS: the ChromeOS kernels set the default mmap_min_addr value to at least 32KB.
  • Fuchsia: the userspace base address begins at 2MB; this is configured per-platform but set to the same value on all platforms.

Indexing a container out of bounds hits a __libcpp_verbose_abort, is this a security bug?

std::vector and other containers are now protected by libc++ hardening on all platforms Indexing these containers out of bounds is now a safe crash - if a proof-of-concept reliably causes a crash in production builds we consider these to be functional rather than security issues.

Are stack overflows considered security bugs?

No. Guard pages mean that stack overflows are considered unexploitable, and are regarded as denial of service bugs. The only exception is if an attacker can jump over the guard pages allocated by the operating system and avoid accessing them, e.g.:

  • A frame with a very large stack allocation.
  • C variable length array with an attacker-controlled size.
  • A call to alloca() with an attacker-controlled size.

Are enterprise admins considered privileged?

Chrome can't guard against local attacks. Enterprise administrators often have full control over the device. Does Chrome assume that enterprise administrators are as privileged and powerful as other local users? It depends:

  • On a fully managed machine, for example a domain-joined Windows machine, a device managed via a Mobile Device Management product, or a device with Chrome managed via machine-level Chrome Browser Cloud Management, the administrator effectively has privileges to view and mutate any state on the device. Chrome policy implementations should still guide enterprise admins to the most user-respectful defaults and policy description text should clearly describe the nature of the capabilities and the user impact of them being granted.
  • On an unmanaged machine, Chrome profiles can be managed via cloud policy if users sign into Chrome using a managed account. These policies are called user policies. In this scenario, the Chrome enterprise administrator should have privileges only to view and mutate state within the profile that they administer. Any access outside that profile requires end-user consent.

Chrome administrators can force-install Chrome extensions without permissions prompts, so the same restrictions must apply to the Chrome extension APIs.

Chrome has a long history of policy support with many hundreds of policies. We recognize that there may exist policies or policy combinations that can provide capabilities outside of the guidance provided here. In cases of clear violation of user expectations, we will attempt to remedy these policies and we will apply the guidance laid out in this document to any newly added policies.

See the Web Platform Security guidelines for more information on how enterprise policies should interact with Web Platform APIs.

Can I use EMET to help protect Chrome against attack on Microsoft Windows?

There are known compatibility problems between Microsoft's EMET anti-exploit toolkit and some versions of Chrome. These can prevent Chrome from running in some configurations. Moreover, the Chrome security team does not recommend the use of EMET with Chrome because its most important security benefits are redundant with or superseded by built-in attack mitigations within the browser. For users, the very marginal security benefit is not usually a good trade-off for the compatibility issues and performance degradation the toolkit can cause.

Certificates & Connection Indicators

Where are the security indicators located in the browser window?

The topmost portion of the browser window, consisting of the Omnibox (or Location Bar), navigation icons, menu icon, and other indicator icons, is sometimes called the browser chrome (not to be confused with the Chrome Browser itself). Actual security indicators can only appear in this section of the window. There can be no trustworthy security indicators elsewhere.

Furthermore, Chrome can only guarantee that it is correctly representing URLs and their origins at the end of all navigation. Quirks of URL parsing, HTTP redirection, and so on are not security concerns unless Chrome is misrepresenting a URL or origin after navigation has completed.

Browsers present a dilemma to the user since the output is a combination of information coming from both trustworthy sources (the browser itself) and untrustworthy sources (the web page), and the untrustworthy sources are allowed virtually unlimited control over graphical presentation. The only restriction on the page's presentation is that it is confined to the large rectangular area directly underneath the chrome, called the viewport. Things like hover text and URL preview(s), shown in the viewport, are entirely under the control of the web page itself. They have no guaranteed meaning, and function only as the page desires. This can be even more confusing when pages load content that looks like chrome. For example, many pages load images of locks, which look similar to the meaningful HTTPS lock in the Omnibox, but in fact do not convey any meaningful information about the transport security of that page.

When the browser needs to show trustworthy information, such as the bubble resulting from a click on the lock icon, it does so by making the bubble overlap chrome. This visual detail can't be imitated by the page itself since the page is confined to the viewport.

Why does Chrome show a lock, even if my HTTPS connection is being proxied?

Some types of software intercept HTTPS connections. Examples include anti-virus software, corporate network monitoring tools, and school censorship software. In order for the interception to work, you need to install a private trust anchor (root certificate) onto your computer. This may have happened when you installed your anti-virus software, or when your company's network administrator set up your computer. If that has occurred, your HTTPS connections can be viewed or modified by the software.

Since you have allowed the trust anchor to be installed onto your computer, Chrome assumes that you have consented to HTTPS interception. Anyone who can add a trust anchor to your computer can make other changes to your computer, too, including changing Chrome. (See also Why aren‘t physically-local attacks in Chrome’s threat model?.)

Why can’t I select Proceed Anyway on some HTTPS error screens?

A key guarantee of HTTPS is that Chrome can be relatively certain that it is connecting to the true web server and not an impostor. Some sites request an even higher degree of protection for their users (i.e. you): they assert to Chrome (via Strict Transport Security — HSTS — or by other means) that any server authentication error should be fatal, and that Chrome must close the connection. If you encounter such a fatal error, it is likely that your network is under attack, or that there is a network misconfiguration that is indistinguishable from an attack.

The best thing you can do in this situation is to raise the issue to your network provider (or corporate IT department).

Chrome shows non-recoverable HTTPS errors only in cases where the true server has previously asked for this treatment, and when it can be relatively certain that the current server is not the true server.

How does key pinning interact with local proxies and filters?

To enable certificate chain validation, Chrome has access to two stores of trust anchors (i.e., certificates that are empowered as issuers). One trust anchor store is for authenticating public internet servers, and depending on the version of Chrome being used and the platform it is running on, the Chrome Root Store might be in use. The private store contains certificates installed by the user or the administrator of the client machine. Private intranet servers should authenticate themselves with certificates issued by a private trust anchor.

Chrome’s key pinning feature is a strong form of web site authentication that requires a web server’s certificate chain not only to be valid and to chain to a known-good trust anchor, but also that at least one of the public keys in the certificate chain is known to be valid for the particular site the user is visiting. This is a good defense against the risk that any trust anchor can authenticate any web site, even if not intended by the site owner: if an otherwise-valid chain does not include a known pinned key (“pin”), Chrome will reject it because it was not issued in accordance with the site operator’s expectations.

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

We deem this acceptable because the proxy or MITM can only be effective if the client machine has already been configured to trust the proxy’s issuing certificate — that is, the client is already under the control of the person who controls the proxy (e.g. the enterprise’s IT administrator). If the client does not trust the private trust anchor, the proxy’s attempt to mediate the connection will fail as it should.

When is key pinning enabled?

Key pinning is enabled for Chrome-branded, non-mobile builds when the local clock is within ten weeks of the embedded build timestamp. Key pinning is a useful security measure but it tightly couples client and server configurations and completely breaks when those configurations are out of sync. In order to manage that risk we need to ensure that we can promptly update pinning clients in an emergency and ensure that non-emergency changes can be deployed in a reasonable timeframe.

Each of the conditions listed above helps ensure those properties: Chrome-branded builds are those that Google provides and they all have an auto-update mechanism that can be used in an emergency. However, auto-update on mobile devices is significantly less effective thus they are excluded. Even in cases where auto-update is generally effective, there are still non-trivial populations of stragglers for various reasons. The ten-week timeout prevents those stragglers from causing problems for regular, non-emergency changes and allows stuck users to still, for example, conduct searches and access Chrome's homepage to hopefully get unstuck.

In order to determine whether key pinning is active, try loading If key pinning is active the load will fail with a pinning error.

How does Certificate Transparency interact with local proxies and filters?

Just as pinning only applies to publicly-trusted trust anchors, Chrome only evaluates Certificate Transparency (CT) for publicly-trusted trust anchors. Thus private trust anchors, such as for enterprise middle-boxes and AV proxies, do not need to be publicly logged in a CT log.

Why are some web platform features only available in HTTPS page-loads?

The full answer is here: we Prefer Secure Origins For Powerful New Features. In short, many web platform features give web origins access to sensitive new sources of information, or significant power over a user's experience with their computer/phone/watch/etc., or over their experience with it. We would therefore like to have some basis to believe the origin meets a minimum bar for security, that the sensitive information is transported over the Internet in an authenticated and confidential way, and that users can make meaningful choices to trust or not trust a web origin.

Note that the reason we require secure origins for WebCrypto is slightly different: An application that uses WebCrypto is almost certainly using it to provide some kind of security guarantee (e.g. encrypted instant messages or email). However, unless the JavaScript was itself transported to the client securely, it cannot actually provide any guarantee. (After all, a MITM attacker could have modified the code, if it was not transported securely.)

See the Web Platform Security guidelines for more information on security guidelines applicable to web platform APIs.

Which origins are “secure”?

Secure origins are those that match at least one of the following (scheme, host, port) patterns:

  • (https, *, *)
  • (wss, *, *)
  • (*, localhost, *)
  • (*, 127/8, *)
  • (*, ::1/128, *)
  • (file, *, —)
  • (chrome-extension, *, —)

That is, secure origins are those that load resources either from the local machine (necessarily trusted) or over the network from a cryptographically-authenticated server. See Prefer Secure Origins For Powerful New Features for more details.

What's the story with certificate revocation?

Chrome's primary mechanism for checking certificate revocation status is CRLsets. Additionally, by default, stapled Online Certificate Status Protocol (OCSP) responses are honored.

“Online” certificate revocation status checks using Certificate Revocation List (CRL) or OCSP URLs included in certificates are disabled by default. This is because unless a client, like Chrome, refuses to connect to a website if it cannot get a valid response, online checks offer limited security value.

Unfortunately, there are many widely-prevalent causes for why a client might be unable to get a valid certificate revocation status response to include:

  • timeouts (e.g., an OCSP responder is online but does not respond within an acceptable time limit),
  • availability issues (e.g., the OCSP responder is offline),
  • invalid responses (e.g., a “stale” or malformed status response), and
  • local network attacks misrouting traffic or blocking responses.

Additional concern with OCSP checks are related to privacy. OCSP requests reveal details of individuals' browsing history to the operator of the OCSP responder (i.e., a third party). These details can be exposed accidentally (e.g., via data breach of logs) or intentionally (e.g., via subpoena). Chrome used to perform revocation checks for Extended Validation certificates, but that behavior was disabled in 2022 for privacy reasons.

For more discussion on challenges with certificate revocation status checking, explained by Adam Langley, see and

The following enterprise policies can be used to change the default revocation checking behavior in Chrome, though these may be removed in the future:

Passwords & Local Data

What about unmasking of passwords with the developer tools?

One of the most frequent reports we receive is password disclosure using the Inspect Element feature (see Issue 126398 for an example). People reason that “If I can see the password, it must be a bug.” However, this is just one of the physically-local attacks described in the previous section, and all of those points apply here as well.

The reason the password is masked is only to prevent disclosure via “shoulder-surfing” (i.e. the passive viewing of your screen by nearby persons), not because it is a secret unknown to the browser. The browser knows the password at many layers, including JavaScript, developer tools, process memory, and so on. When you are physically local to the computer, and only when you are physically local to the computer, there are, and always will be, tools for extracting the password from any of these places.

Is Chrome's support for userinfo in HTTP URLs (e.g. considered a vulnerability?

Not at this time. Chrome supports HTTP and HTTPS URIs with username and password information embedded within them for compatibility with sites that require this feature. Notably, Chrome will suppress display of the username and password information after navigation in the URL box to limit the effectiveness of spoofing attacks that may try to mislead the user. For instance, navigating to will show an address of after the page loads.

Note: We often receive reports calling this an “open redirect”. However, it has nothing to do with redirection; rather the format of URLs is complex and the userinfo may be misread as a host.

Why does the Password Manager ignore autocomplete='off' for password fields?

Ignoring autocomplete='off' for password fields allows the password manager to give more power to users to manage their credentials on websites. It is the security team's view that this is very important for user security by allowing users to have unique and more complex passwords for websites. As it was originally implemented, autocomplete=‘off’ for password fields took control away from the user and gave control to the web site developer, which was also a violation of the priority of constituencies. For a longer discussion on this, see the mailing list announcement.

Signing out of Chrome does not delete previously-synced data?

If you have signed into Chrome and subsequently sign out of Chrome, previously saved passwords and other data are not deleted from your device unless you select that option when signing out of Chrome.

If you change your Google password, synced data will no longer be updated in Chrome instances until you provide the new password to Chrome on each device configured to sync. However, previously synced data remains available on each previously-syncing device unless manually removed.

Why doesn't the Password Manager save my Google password if I am using Chrome Sync?

In its default mode, Chrome Sync uses your Google password to protect all the other passwords in the Chrome Password Manager.

In general, it is a bad idea to store the credential that protects an asset in the same place as the asset itself. An attacker who could temporarily compromise the Chrome Password Manager could, by stealing your Google password, obtain continuing access to all your passwords. Imagine you store your valuables in a safe, and you accidentally forget to close the safe. If a thief comes along, they might steal all of your valuables. That’s bad, but imagine if you had also left the combination to the safe inside as well. Now the bad guy has access to all of your valuables and all of your future valuables, too. The password manager is similar, except you probably would not even know if a bad guy accessed it.

To prevent this type of attack, Chrome Password Manager does not save the Google password for the account you sync with Chrome. If you have multiple Google accounts, the Chrome Password Manager will save the passwords for accounts other than the one you are syncing with.

Does the Password Manager store my passwords encrypted on disk?

Chrome generally tries to use the operating system's user storage mechanism wherever possible and stores them encrypted on disk, but it is platform specific:

  • On Windows, Chrome uses the Data Protection API (DPAPI) to bind your passwords to your user account and store them on disk encrypted with a key only accessible to processes running as the same logged on user.
  • On macOS and iOS, Chrome previously stored credentials directly in the user‘s Keychain, but for technical reasons, it has switched to storing the credentials in “Login Data” in the Chrome users profile directory, but encrypted on disk with a key that is then stored in the user’s Keychain. See Issue 466638 and Issue 520437 for further explanation.
  • On Linux, Chrome previously stored credentials directly in the user‘s Gnome Secret Service or KWallet, but for technical reasons, it has switched to storing the credentials in “Login Data” in the Chrome user’s profile directory, but encrypted on disk with a key that is then stored in the user's Gnome Secret Service or KWallet. If there is no available Secret Service or KWallet, the data is not encrypted when stored.
  • On Android, Chrome doesn't store in the profile anymore, instead it uses Google Play Services to access passwords stored on a device.
  • On ChromeOS passwords are only obfuscated since all profile data is encrypted by the OS.

If there's a way to see stored passwords without entering a password, is this a security bug?

No. If an attacker has control of your login on your device, they can get to your passwords by inspecting Chrome disk files or memory. (See why aren‘t physically-local attacks in Chrome’s threat model).

On some platforms we ask for a password before revealing stored passwords, but this is not considered a robust defense. It’s historically to stop users inadvertently revealing their passwords on screen, for example if they’re screen sharing. We don’t do this on all platforms because we consider such risks greater on some than on others.


What is the security story for Service Workers?

See our dedicated Service Worker Security FAQ.

What is the security story for Extensions?

See our dedicated Extensions Security FAQ.

What's the security model for Chrome Custom Tabs?

See our Chrome Custom Tabs security FAQ.

Are all Chrome updates important?

Yes - see our updates FAQ.

What older Chrome versions are supported?

We always recommend being on the most recent Chrome stable version - see our updates FAQ.

I'm making a Chromium-based browser. How should I secure it?

If you want to make a browser based on Chromium, you should stay up to date with Chromium's security fixes. There are adversaries who weaponize fixed Chromium bugs (“n-day vulnerabilities”) to target browsers which haven’t yet absorbed those fixes.

Decide whether your approach is to stay constantly up to date with Chromium releases, or to backport security fixes onto some older version, upgrading Chromium versions less frequently.

Backporting security fixes sounds easier than forward-porting features, but in our experience, this is false. Chromium releases 400+ security bug fixes per year (example query). Some downstream browsers take risks by backporting only Medium+ severity fixes, but that's still over 300 (example query). Most are trivial cherry-picks; but others require rework and require versatile engineers who can make good decisions about any part of a large codebase.

Our recommendation is to stay up-to-date with Chrome's released versions. You should aim to release a version of your browser within just a few days of each Chrome stable release. If your browser is sufficiently widely-used, you can apply for advance notice of fixed vulnerabilities to make this a little easier.

Finally, if you choose the backporting approach, please explain the security properties to your users. Some fraction of security improvements cannot be backported. This can happen for several reasons, for example: because they depend upon architectural changes (e.g. breaking API changes); because the security improvement is a significant new feature; or because the security improvement is the removal of a broken feature.