[Privacy] Potential side-channel in downloadTotal enforcement for cross-origin resources

[yoshisatoyanagisawa]

There appears to be a discrepancy between the Background Fetch specification's enforcement of downloadTotal and the requirements for cross-origin resource isolation. Current behavior may allow for XS-Leaks (Cross-Site Leaks) regarding the size of cross-origin resources.

Observable Side-Channel via downloadTotal
The specification defines a mechanism where the total bytes downloaded across all records are monitored against a downloadTotal limit. If this limit is exceeded by any single record, the entire background fetch operation is aborted through the abort all flag.

The privacy issue arises because cross-origin resources contribute to this total count before a final CORS check is concluded. Because the abort state of the overall fetch operation is observable to the script, the downloadTotal limit can be used as an "oracle" to determine whether a cross-origin resource's size is above or below a specific threshold. This allows an origin to leak the size of resources it should not have access to.

Comparison with Precedents
This information leak is analogous to the vulnerability recently addressed in the Fetch API (cf. crbug.com/474435504), where handling of specific status codes for opaque responses provided a side-channel for resource size detection. In that case, the fix involved ensuring symmetric behavior for such responses to eliminate the observable difference.

Proposed Solution
The specification and implementations should ensure that cross-origin resource failures (such as CORS violations) do not impact the overall state of a background fetch in an observable way.

We recommend refining the abortion logic so that if a fetch would be aborted due to a downloadTotal violation by a cross-origin resource, the failure is either handled silently or the error state is masked to prevent size-based side-channel attacks.

[jakearchibald]

Which CORS checks happen after the start of the body?

[yoshisatoyanagisawa]

Thanks for the question, Jake. While standard CORS header checks (ACAO) strictly happen at the header stage, there are a few reasons why this remains an observable side-channel in the current spec and implementations:

1. Asymmetric Abortion Logic: In the Perform a background fetch algorithm, download-total-exceeded triggers an immediateFailure (Step 5.5), which sets the abort all flag without waiting for other records (Step 6 and 7). Other errors like CORS failures (fetch-error) are not immediate failures and wait for all parallel records to settle (Step 6). An attacker can use a slow parallel request to distinguish these two states via timing.

2. Observability of the Failure Reason: The failureReason attribute on BackgroundFetchRegistration explicitly exposes whether the job failed due to "download-total-exceeded" or "fetch-error". If an implementation processes Content-Length or early body chunks (e.g., in a multi-process environment) before the CORS failure is fully handled, the script can directly read the size-based error state.

3. ORB/CORB: Mechanisms like ORB/CORB, which inspect the start of the body to block sensitive cross-origin data, are examples of security checks that conclude after the body has started. Even if ACAO happens early, these checks can still be the point where a resource is officially "failed," potentially after bytes have been counted against the total.

For more technical details, I’ve added your chromium.org email to the CC list of crbug.com/40061131. If that account is still active, you should be able to view the PoC there.