W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2013

Re: CORS and 304

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 9 Dec 2013 15:20:27 +0000
Message-ID: <CADnb78gakurkOdgUZ4xsQReOu7drq8qm=XbnECUTnOsnmqpuaA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Karl Dubost <karl@la-grange.net>, Mark Nottingham <mnot@mnot.net>, Odin Hørthe Omdal <odinho@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Adam Barth <w3c@adambarth.com>, WebAppSec WG <public-webappsec@w3.org>
On Wed, Dec 4, 2013 at 7:51 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> Otherwise it means that you can just read 304 responses from any website
> without any security checks at all. And I think making the claim that a 304
> response couldn't possibly contain sensitive data is too bold of a claim.

That seems fair. The logic of when to show 304 to the API and when 200
is currently not very well defined however... Need to figure that out
some day.

> However, in most cases when 304 responses are involved the website doesn't
> actually see the 304 response. Most of the time the website makes a request
> for a resource. If the UA has that resource cached, it will then make a
> if-modified-since request. If a 304 is returned, without cors headers, then
> the UA will return the originally cached response. If this cached response
> does have the appropriate cors headers then permission should be granted.

Okay, I was led to believe Firefox requires CORS headers in this scenario.

Received on Monday, 9 December 2013 15:20:58 UTC

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