search

w3c / webappsec-csp

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

CSP violation report should not use redirect-mode: "error" #320

Open yutakahirano opened 6 years ago

yutakahirano commented 6 years ago

The fetch spec says a request with mode: 'no-cors' must have 'follow' redirect mode. CSP violation report violates the rule.

@mikewest @annevk

annevk commented 6 years ago

So the problem is that we don't want to expose that a cross-origin URL has a redirect, I think. I could dig further if we need more information. Curious why this has such a mode.

yutakahirano commented 6 years ago

@mikewest said he wanted to avoid CORS preflight for CSP violation report.

annevk commented 6 years ago

I don't see how this mode avoids the need for that?

yutakahirano commented 6 years ago

As it contains "content-type: application/csp-report" header, a CORS preflight would be made if the request mode were "cors".

annevk commented 6 years ago

Okay, but why is the redirect mode "error"?

mikewest commented 6 years ago

@mikewest said he wanted to avoid CORS preflight for CSP violation report.

For clarity, the rationale here is that we've deployed violation reports for years without preflights, and breaking existing implementations seems difficult. We've carved these kinds of reports out in https://fetch.spec.whatwg.org/#cors-protocol-exceptions, and I don't see a good reason to try to claw that back.

Okay, but why is the redirect mode "error"?

Folks decided at some point in the past that we should deliver violation reports to the specified server, but not allow that server to delegate receipt of the violation reports to third-parties. We hand-waved at this in CSP2 (step 3.2 of https://www.w3.org/TR/CSP2/#send-violation-reports) and CSP1 (step 4.1 of https://www.w3.org/TR/2012/CR-CSP-20121115/#send-a-violation-report). This redirect mode seemed like the right way of explaining that behavior. It apparently wasn't.

I'm not actually convinced that that restriction is doing any work at this point, and if we don't have a way of specifying it reasonably, perhaps we can relax it. But I might well be missing a non-obvious thread... @dveditz might remember the initial discussions around this point? I wasn't able to find them in a quick search of the public-webappsec@ archive.

mikewest commented 6 years ago

(/cc @andypaicu)