Relying on CORS assumes that any sensitive data that should be available cross-origin would have appropriate headers applied to any response. -mike -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Thu, Jan 9, 2014 at 9:14 AM, Mark Nottingham <mnot@mnot.net> wrote: > Doesn't relying on CORS assume that sensitive data will never be available > cross-origin? > > Sent from my iPhone > > On 9 Jan 2014, at 3:26 pm, Michal Zalewski <lcamtuf@coredump.cx> wrote: > > >> What is the mitigation that you're agreeing with, Michal? Only > performing > >> integrity checks on resources delivered with explicitly public > cache-control > >> or CORS headers? > > > > Well, Eduardo's take is that we should just require CORS and not dance > > around it. Maybe that would work, although it does require explicit > > cooperation of the third-party site that hosts a particular download, > > has a copy of jQuery, etc. I'd imagine this won't always be painless. > > > > An alternative would be to unconditionally fail if integrity= is > > specified and none of the following three conditions are met: > > > > 1) The subresource is same-origin with the requestor, > > > > 2) The subresource is publicly cacheable by proxies (either due to > > implicit caching rules, or due to Cache-Control), > > > > 3) There is a CORS header that explicitly permits this subresource to > > be accessed across origins. > > > > /mz >
Received on Thursday, 9 January 2014 08:17:10 UTC