w3c / webappsec-csp

WebAppSec Content Security Policy
https://w3c.github.io/webappsec-csp/
Other
206 stars 78 forks source link

CSP Report Does Not Reflect Redirected Blocked Domains #672

Open ConardLi opened 1 month ago

ConardLi commented 1 month ago

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.

image

mikewest commented 1 month ago

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 commented 1 month ago

At some point we should add a header that allows exposing the redirect: https://github.com/whatwg/fetch/issues/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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.