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

[AC] Helping server admins not making mistakes

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 13 May 2008 16:58:16 -0700
Message-ID: <482A2B18.2070808@sicking.cc>
To: "WAF WG (public)" <public-appformats@w3.org>

Hi guys,

Recently mozilla received some input with regards to some aspects of the 
access-control spec, in addition to the concern that I brought up to 
hixie and which he posted about in the "Opting into cookies" thread.

I will address these new concerns in two emails, this one and one I'm 
posting in a few minutes.

There is a concern with the fact that when a server administrator 
enables cross-site access to unsafe methods (POST/DELETE etc) using the 
access-control spec he has to be able to handle almost all possible HTTP 
methods, as well as all possible http-headers. This is a problem for two 

First of all it is very possible that the server itself, or the scripts 
running on the server, performs actions that the server administrator is 
not aware of. For example an administrator might not realize that the 
server supports the PUT action such that other sites can't just POST to 
a CGI script, but also replace the script using PUT.

Second, even if the administrator is aware of the server performing a 
harmful action for certain headers or methods, it can be very hard to 
change this. The current spec has an all-or-nothing approach. To enable 
cross-site POST you also are forced to deal with all other methods, 
weather you want them or not.

To address this I propose that we add two new headers:

This header contains a whitespace separated list of headers that the 
servers wants to allow the requesting site to set. This can be both 
standard headers, as well as custom headers.

This header contains a whitespace separated list of HTTP methods that 
the server wants to allow the requesting site to use. This can be both 
standard methods, as well as custom methods.

Both these lists will be stored in the "method check result cache" (btw, 
that name sounds odd since it's not a method-check, but rather an 

Note that this proposal is much simpler than the old syntax we used to 
have where the methods were listed as part of the Access-Control header 
since the syntax is much simpler, and neither header is part of the key 
to the "method check result cache" but rather stored as values in it.

This will significantly reduce the risk that a server operator opts in 
to something which isn't secure. First of all because you opt in to much 
less (just a short whitelist of headers/methods rather than the whole 
possible space), and second because you are unlikely to opt in to 
something which you don't know how it works.

/ Jonas
Received on Wednesday, 14 May 2008 00:00:17 UTC

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