- From: Mike West <notifications@github.com>
- Date: Wed, 04 Apr 2018 05:19:47 +0000 (UTC)
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/687/378483245@github.com>
> We've explored the idea of expanding `Origin` header in the request as well but the challenge we face there is deployability. It's a lot easier for websites to deploy `From-Origin` header on all resources than checking `Origin` header on every resource request while keeping it compatible with old browsers that don't send this request, etc... I think I agree that `From-Origin` is easier to deploy for servers, as it doesn't require much in the way of server-side logic. If we expand the scope of the `Origin` header, servers would need to read it, process it, and do something useful with it, which certainly takes some effort. I'd suggest that expanding the scope of `Origin` has the additional benefit of giving servers the tools to more broadly mitigate CSRF attacks, but I'm willing to believe that fewer folks would be interested in doing the extra work. I think it's worth experimenting with that approach, but there's no reason we couldn't do both. I have a few detail questions: 1. @annevk suggested that this should apply to everything except top-level navigations. That misses auxiliary browsing contexts created via `window.open`, which I imagine are same-process in some browsers. Would we want to address that vector as well? 2. Does `From-Origin: SameSite` (or however we end up spelling it), walk up the ancestor tree, or do we base the check purely on the initiating origin? We've recently fixed `X-Frame-Options: SAMEORIGIN` to align with `frame-ancestors` by checking the entire tree, and I'd suggest that that's the right behavior here as well. 3. We apparently talked about this in https://github.com/w3c/webappsec-csp/issues/17 as well. I'm less enthusiastic about adding new directives to CSP than I was in 2015, but it's worth evaluating whether we should consider this an analog to `frame-ancestors` by adding a new CSP directive, or if we should add a new header entirely. 4. Would we apply this to redirect responses, or just final responses? I vaguely recall differences in `X-Frame-Options` behavior on this point between browsers, so it's probably worth hammering out (FWIW, I'd suggest that we should apply the check to redirect responses, returning an error rather than following the redirect, as appropriate). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/687#issuecomment-378483245
Received on Wednesday, 4 April 2018 05:20:15 UTC