Re: CORS and 304

On 12/4/13 2:51 PM, Jonas Sicking 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.

I think the argument that might be made is that in the case when a 
CORS-enabled request is made and the response is a 304 (whether with or 
without CORS headers) the UA should use the CORS headers for its cached 
response to determine whether the CORS check passes.  And presumably if 
it does it should only expose the headers/body of the cached response, 
not the headers of the 304 response.

> For example it would let me see when you last got money deposited into
> your bank account by polling the "show account summary" URL with
> different if-modified-since dates. Any time I get back a 304 it means
> that the date used was more recent than when you received money.

The idea as described above is that you wouldn't be able to tell whether 
you got a 304 or a new 200 that has the same headers as your cached 200. 
  They'd behave identically.

> However, in most cases when 304 responses are involved the website
> doesn't actually see the 304 response.

Right.

> 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.

I think we agree.

Is that what UAs do today for a 304?

-Boris

Received on Wednesday, 4 December 2013 20:09:58 UTC