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

Re: Remove paths from CSP?

From: Mike West <mkwst@google.com>
Date: Thu, 5 Jun 2014 14:52:03 +0200
Message-ID: <CAKXHy=fAptbCak8TaEJ+_Ty+UMB5R_GBQ7T07Jb4+YGfsXiZqA@mail.gmail.com>
To: Sigbjørn Vik <sigbjorn@opera.com>
Cc: Daniel Veditz <dveditz@mozilla.com>, Joel Weinberger <jww@chromium.org>, "Oda, Terri" <terri.oda@intel.com>, Michal Zalewski <lcamtuf@coredump.cx>, Egor Homakov <homakov@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Eduardo' Vela" <evn@google.com>
On Thu, Jun 5, 2014 at 2:11 PM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> Alternatively, our "blank" page might be what is returned by a 200
> response on an authentication-less (e.g. no cookies) requests to the
> same URL. (To avoid timing attacks on the response time, that request
> would have to be fired off simultaneously, so this might increase
> traffic, unless we have good heuristics for when to use it.)

That sounds like a lot of overhead. We'd basically request every resource

> Referer is optional, and doesn't happen on https, and Origin only on
> CORS. Referer doesn't say anything about inline or not (Origin implies
> inline resource). An "Is-inline-element-on-embedding-URL: evil.com"
> header might achieve the same (which is essentially an Origin header
> applied to CSP-controlled requests).

Could we simplify this to a header which made it clear that the request was
cross-origin? Would that bit of information be enough, or do we need to
pass in the complete host `evil.com`?

I don't really want to put the current URL (or origin) into a request
header if we can avoid it; that would negate the ability of the `referrer`
directive to suppress referrer information completely for sensitive

Received on Thursday, 5 June 2014 12:52:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC