Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team.

Overview: The ChromeWebStoreNavigationThrottle attaches sensitive enterprise credentials (DM token and device ID) to requests targeting the Chrome Web Store. If the server redirects the request to a cross-origin URL, the throttle fails to remove these headers, leading to a potential credential leak to third-party domains.

Affected files:

• chrome/browser/enterprise/webstore/chrome_web_store_navigation_throttle.cc
• chrome/browser/chrome_content_browser_client_navigation_throttles.cc

Estimated timestamp from git blame: 2025-10-01

Summary

A potential vulnerability in ChromeWebStoreNavigationThrottle allows the leakage of sensitive enterprise credentials, specifically the X-Browser-Dm-Token (CBCM DM bearer token) and X-Client-Device-Id, to arbitrary third-party origins. The leakage occurs when a request initially targeting chromewebstore.google.com (or its subdomains) is redirected to an off-domain URL via an HTTP 3xx response.

Technical Details

In chrome/browser/enterprise/webstore/chrome_web_store_navigation_throttle.cc, the MaybeAppendHeaders() method is called during both WillStartRequest() and WillRedirectRequest(). When navigating to a URL within the Chrome Web Store domain, the throttle attaches the DM token and device ID using navigation_handle()->SetRequestHeader().

However, if the server responds with a redirect to a non-Chrome Web Store URL, WillRedirectRequest() re-enters MaybeAppendHeaders(). The method checks if the new URL belongs to the Web Store domain:

if (!navigation_handle()->GetURL().DomainIs(
        extension_urls::GetNewWebstoreLaunchURL().GetHost())) {
  return content::NavigationThrottle::PROCEED;
}

Because the check fails for the redirect target, the throttle returns PROCEED immediately. It fails to call navigation_handle()->RemoveRequestHeader() for the headers it previously added.

Since this is a standard navigation request (mode == network::mojom::RequestMode::kNavigate), it is not subjected to CORS header stripping logic (CorsUnsafeNotForbiddenRequestHeaderNames). The net::URLRequest preserves custom headers across redirects unless explicitly instructed to remove them. Therefore, the sensitive enterprise headers are included in the subsequent request to the redirected origin.

Potential Steps to Reproduce

Note: These steps are suggested based on code analysis; a live proof-of-concept has not been executed.

1. An attacker provisions a malicious web server at https://attacker.com/leak that logs incoming HTTP request headers.
2. The attacker identifies an open redirect or a legitimate redirect endpoint on the Chrome Web Store, crafting a URL like https://chromewebstore.google.com/redirect?url=https://attacker.com/leak.
3. The attacker convinces a victim, operating a managed enterprise Chrome browser, to visit a webpage containing an <iframe> targeting the crafted CWS URL.
4. Chrome initiates the navigation, attaching the X-Browser-Dm-Token and X-Client-Device-Id headers to the initial request to the CWS domain.
5. The CWS server responds with an HTTP 3xx redirect to https://attacker.com/leak.
6. The browser follows the redirect but fails to strip the custom headers, transmitting the enterprise credentials to the attacker’s server.

Suggested Fix

Similar to the pattern used in PlatformAuthNavigationThrottle, the ChromeWebStoreNavigationThrottle should keep track of the headers it has attached. In WillRedirectRequest(), it should explicitly remove these headers before evaluating the new URL and deciding whether to re-attach them.

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.