New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Feature

issue 268640

Sign in to add a comment

Provide tool for auditing a site's XSDB protection

Project Member Reported by, Jan 25

Issue description

In  issue 786505 , we added logic for cross-site document blocking (XSDB) when Site Isolation is enabled.  We're considering whether to enable it by default as well (in  issue 802835 ), before Site Isolation launches more generally.  This logic helps prevent sensitive data in cross-site HTML, XML, JSON, and plain text documents from leaking to an attacker's page, even if they request it directly as a subresource.

The protection depends on correct MIME type labeling and is also more effective when there is a nosniff header present.  Thus, web developers may find it useful to have a tool to audit whether their own site's subresources would be protected when this policy is enabled.

As one example, nick@ suggested having a feature in DevTools which annotates the same-origin subresources requested in a given page, indicating whether they would be protected (i.e., blocked by the browser process) if they were requested as a subresource in a cross-site page.

pfeldman@ mentioned that this may be a useful addition for Lighthouse audits, though I think that is primarily for mobile sites and this is primarily a protection on desktop.  We're open to discussing the right place to put such information, but I wanted to (finally) file the tracking bug for it.

For more details on the policy, see:
Blocking: 268640
I wonder if it also might be useful to:

- Highlight cross-origin resources that XSDB ends up sniffing and not blocking because of mime type mismatch.

- Highlight image/script/video/etc. resources that render/work successfully (because they are same-origin or because XSDB is turned off), but that can be incorrectly blocked (because of incorrect mime type / when cross-origin or when XSDB is turned on).

The implementation of the both cases above would be different, but in both cases the expected action that the web developer can take is: fix content-type headers of the affected resources.

Sign in to add a comment