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. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: The DevTools protocol command Network.enableDeviceBoundSessions registers an observer for Device Bound Session Credentials (DBSC) events across the entire StoragePartition. However, the handler fails to filter the returned sessions and events against the client’s allowed origins, allowing a restricted DevTools client to observe DBSC metadata for sites it is blocked from accessing.

Affected files:

• content/browser/devtools/protocol/network_handler.cc
• services/network/device_bound_session_manager.cc

Estimated timestamp from git blame: 2026-02-20

Description

When a DevTools client (such as a Chrome extension with the debugger permission) invokes the Network.enableDeviceBoundSessions command, the request is handled by NetworkHandler::EnableDeviceBoundSessions in content/browser/devtools/protocol/network_handler.cc.

The handler retrieves the DeviceBoundSessionManager for the current StoragePartition and registers a global observer (DeviceBoundSessionEventObserver) for all DBSC events. The network service then immediately broadcasts the current state of all active sessions in the profile, and subsequently broadcasts any new session creation, refresh, or termination events.

Crucially, when these events are received back in the browser process, NetworkHandler::AddDeviceBoundSessionDisplays and NetworkHandler::OnDeviceBoundSessionEventReceived forward the data directly to the DevTools frontend. Unlike other profile-wide DevTools methods in the same file (such as NetworkHandler::GetAllCookies, which explicitly filters results using client_->MayAttachToURL()), the DBSC event handlers perform no origin-based filtering.

This oversight allows a DevTools client to bypass enterprise security policies. If an extension is explicitly blocked from accessing a sensitive site (e.g., via the runtime_blocked_hosts policy), it can still attach a debugger to an permitted target (like its own background page) and receive DBSC metadata for the restricted site.

Impact

This is a permissions bypass resulting in information disclosure. An untrusted or restricted DevTools client can observe DBSC session activity across the entire profile, including origins it is explicitly forbidden from inspecting.

The leaked data includes session metadata such as:

• Site origins and session IDs.
• Refresh URLs (which may contain tracking identifiers).
• Cookie cravings (cookie names and attributes, indicating application structure).
• Error response bodies from failed refresh requests.

While sensitive cryptographic keys and actual cookie values are not exposed, the ability to track session lifecycle events on restricted origins violates the DevTools security boundary.

Potential Reproduction Steps

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

1. On a system with DBSC enabled, log into a site that creates a Device Bound Session (e.g., https://example.com).
2. Configure the ExtensionSettings enterprise policy with runtime_blocked_hosts to explicitly block a specific extension from accessing https://example.com.
3. Install the blocked extension, ensuring it has the debugger permission.
4. From the extension’s background script, attach the debugger to its own background page (which is not blocked by the policy).
5. Send the Network.enableDeviceBoundSessions command with {"enable": true}.
6. Observe that the extension receives Network.deviceBoundSessionsAdded events containing DBSC metadata for https://example.com, despite being blocked by policy.
7. Interact with https://example.com in another tab to trigger session refreshes, and observe that the extension receives Network.deviceBoundSessionEventOccurred events for those actions.

Suggested Fix

The NetworkHandler must filter DBSC events before sending them to the frontend, ensuring the client is authorized to view data for the associated origin.

1. In NetworkHandler::AddDeviceBoundSessionDisplays, iterate through the sessions vector. Before adding a session to protocol_sessions, construct a URL from session.key.site (using both HTTP and HTTPS schemes, similar to CanAccessCookie) and verify it against client_->MayAttachToURL(). Only include authorized sessions in the DevTools response.
2. In NetworkHandler::OnDeviceBoundSessionEventReceived, construct a URL from event.site and verify it against client_->MayAttachToURL(). If the client is not authorized, drop the event and do not call frontend_->DeviceBoundSessionEventOccurred.

Evaluated with Chrome root at commit: a1e33f5848218e21d4a16ae2c1bc94e815c30c7f

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.