W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: linking pre-check to POST and other requests?

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 16 Jan 2008 23:22:59 +0000 (UTC)
To: Thomas Roessler <tlr@w3.org>
Cc: public-appformats@w3.org
Message-ID: <Pine.LNX.4.62.0801162319390.15583@hixie.dreamhostps.com>

On Thu, 17 Jan 2008, Thomas Roessler wrote:
> One problem with the pre-flight check is that it is not bound to the 
> subsequent requests that it might authorize.
> This means that there are race conditions when policies change, as the 
> service is unable to distinguish requests that were authorized before a 
> policy change from requests that were authorized afterwards.

Actually it turns out that isn't a problem, because the server can just 
re-do the security check on the actual request. (In fact in the extreme it 
could just automatically reply "allow *" for all OPTIONS requests, and 
then make the actual determination in the real POST/DELETE/etc requests.)

The reason for the preflight isn't for servers going forward, it's just to 
make sure that existing servers aren't exposed to cross-site request 
forgery attacks using APIs that rely on Access-Control.

> It also means that a service that is intended to expose data across 
> origins can't distinguish between a request that's caused through some 
> XSRF technique, and one that has gone through the authorization 
> algorithm.

Again, it doesn't need to, as it can just do the authorization step on the 
request itself, either instead of, or as well as, on the OPTIONS preflight 

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 16 January 2008 23:23:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC