Add request metadata to COEP Reporting

[agampafb]

I am working on rolling our the COEP by evaluating violations and enabling CORP headers for the resources. However, violations that result from http request failures and missing CORP headers cannot be filtered based on current violation reporting syntax.

This request is to add 'status-code' reporting as part of the browser reporting syntax similar to the CSP (https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#violation_report_syntax).

Similar Reference Post: #5391

[yutakahirano]

@whatwg/cross-origin-isolation

[annevk]

This is the status code of the document that holds the policy? I suspect we could give that out (though you could also include it in the reporting URL yourself if you need it).

[ArthurSonzogni]

What "request failure" is exactly?

If this is a network error (no more connectivity for instance) and some COEP reports are sent as a result, maybe this should be considered as a bug, and fixing it would resolve your problem.

---

I suspect leaking the status of the response in reports would be restricted to same-origin ressources. I think this is what CSP does. Would you be happy despite this restriction?

[agampafb]

This is the status code of the document that holds the policy? I suspect we could give that out (though you could also include it in the reporting URL yourself if you need it).

I am referring to the status code for a COEP Blocked Url. How can this be added to the reporting URL without support from the browser violation reporting?

[annevk]

I see, we don't want to report that status code as it would violate the same-origin policy to do so.

[agampafb]

I see, we don't want to report that status code as it would violate the same-origin policy to do so.

The request for status codes of resources embedded by a domain is to enable us to to understand the violations reported by the browser in COEP report-only mode similar to that done by CSP. As a legacy site with multiple domains and wanting to roll out COEP, we need to audit violations before enforcing the policy. However, auditing these 1000s of violations reported currently has been difficult as we don't know what type of failures these include.
Here is an example:
We have a subdomain of instagram that serves assets such as images and videos embedded in Instagram endpoints. Although we have enabled these endpoint handlers to add a CORP header set to 'cross-origin', there are still numerous violation reported for this domain. Based on the current reporting, there is no way of understanding if that was a valid request or a failure request not providing all headers.

My proposed solution for auditing these violations was to:

1. Verify if the embedded resource was reported as a violation because it simply failed to fetch the resource and not necessarily just because it was missing the CORP header for the resource. (So anything apart from 200 OK)
2. For valid violations that would violation COEP due to CORP headers, working with internal/external resource owners to enable these headers

Fetching status codes of a request made by 3rd party client would be a violation of same-origin policy. However, COEP violation reporting is for the resources embedded within its service. I am not sure that it necessarily makes it a violation of same-origin policy to fetch and report the status returned by the embedded resource in 'report-only' mode similar to CSP? CSP status code could arguably 'leak' cross origin for blocked-uri as well as the cross-origin response didn't have CSP policy.

Please provide any other suggestions you may have for enabling COEP for our service here.

[mikewest]

CSP status code could arguably 'leak' cross origin for blocked-uri as well as the cross-origin response didn't have CSP policy.

There's a small misunderstanding here, I think: CSP's reporting doesn't include the status code of the blocked resource. It includes "the HTTP status code of the resource for which the global object was instantiated". That is, it might include the status code of the document which initiated the request which was blocked, not the status code of that object itself.

I understand the challenge you're facing, but I don't think it's a good idea for us to create a mechanism which would reveal status codes cross-origin. That has a reasonable potential to leak interesting information about a user's status (e.g. a signed-in user might get a 2xx response, while a signed-out user might receive a 4xx).

I don't think there's a clean way for us to reveal that information cross-origin without the resource that's been blocked doing some work to opt-in to such reporting. I recognize that for this specific use case, that's something of a chicken and egg problem.

That said, @lweichselbaum or @arturjanc may have some insight into strategies Google has used for similar rollouts in the past. You may also be able to narrow in on the problem by including more metadata in the request's URL (which the requesting document knows, and which can therefore be revealed easily in the reporting)? I'm sorry there's not a straightforward answer here, but I don't think we can safely give you the information you're asking for.