W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: CSP, Fetch, and frame-ancestors

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 4 Jun 2014 14:56:35 +0200
Message-ID: <CADnb78gDnn8xE_pLS9AjagmRBGbJfkNUN6CWoRZAfzenAnc29g@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Brad Hill <hillbrad@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
On Wed, Jun 4, 2014 at 2:46 PM, Mike West <mkwst@google.com> wrote:
> On Wed, Jun 4, 2014 at 10:44 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> How would that work, exactly?
>>
>> I guess the other thing here is that this only applies as part of
>> navigate actions and those never follow redirects automatically (HTML
>> needs to handle them itself for various reasons), so either way I
>> think we'd be good.
>
> I'm thinking of a case where a frame loads `http://a.com/`, which redirects
> to `http://b.com/`, which redirects to `http://c.com/`. If `b.com` sends
> `frame-ancestors 'none'` or `X-Frame-Options: DENY`, I think we shouldn't
> follow the redirect to `c.com`.

That would be the only case where CSP is applied from a response
that's a redirect. What would window.location return in that case? I
guess the same as if it was a network error? I wonder what that is...

Seems a bit weird to me. But as navigate has the manual redirect flag
set, that would work I guess.


> I doubt that's currently how Blink works, now that I think about it, but
> it's probably something we should support.




-- 
http://annevankesteren.nl/
Received on Wednesday, 4 June 2014 12:57:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC