CSP Report Does Not Reflect Redirected Blocked Domains

[ConardLi]

When requests on the website are redirected, the domain to which the request is redirected is blocked because it is not included in the connect-src whitelist. However, the CSP report shows the blockedURL as the original domain before the redirect. This makes it difficult to troubleshoot the issue. It would be helpful if the CSP report could include the actual domain that was blocked after the redirect, or better yet, include both the original and the redirected domains.

[mikewest]

This is unfortunately an intentional decision. Revealing information about redirect targets would absolutely help make debugging simpler, but it would also leak details about another origin's behavior that shouldn't be made accessible (consider redirections that include session IDs, usernames, etc). I don't think this is something we'll be able to easily change.

[annevk]

At some point we should add a header that allows exposing the redirect: whatwg/fetch#601

Might well be one of the more popular Fetch requests at this point.

(This would work for same-origin URLs that redirect or CORS cross-origin URLs that redirect if they opt in.)

[mikewest]

If Fetch makes this information safe to expose via an opt-in like the one discussed above, CSP could certainly rely upon it. In the absence of such an opt-in, I don't think there's anything CSP can/should do here.

[ConardLi]

This is unfortunately an intentional decision. Revealing information about redirect targets would absolutely help make debugging simpler, but it would also leak details about another origin's behavior that shouldn't be made accessible (consider redirections that include session IDs, usernames, etc). I don't think this is something we'll be able to easily change.

Can we only report the domain name after the redirection, so that we can append the domain name to the connect-src whitelist without disclosing the specific URL information

[annevk]

The domain name itself is also confidential information. It might well include the name of the user based on a login cookie or some such.

[ConardLi]

I don't understand why the domain name includes cookies and user name，If this is the case, can only report the second-level domain name?

[clelland]

The domain name doesn't include cookies, but the request which redirected would have had access to those cookies, and might have chosen the destination domain based on those cookies.

[qabandi]

I wonder if it would be more useful for the report to not display the original URL but rather some placeholder like "[Cross origin redirect]" to at least not confuse those debugging.