Ian Hickson wrote:
On Fri, 5 Oct 2007, Henri Sivonen wrote:
What's the expected threat of a browser performing a non-GET request
without being pre-authorized if the response isn't revealed to scripts
if the required Access-Control authorization isn't there? Presumably,
the danger is that e.g. a POST could change the state of the server-side
app. But server-side apps need to be resilient against random POSTs
anyway. Is the expectation that the browser would send login credentials
automatically with a cross-domain XHR POST? Could those credentials be
omitted (until the server demonstrates access-control and Referer-Root
awareness) so that non-GET methods could be tried optimistically? Some
services, like Validator.nu, don't require login, so as far as the
server is concerned, it could handle such an optimistic POST.
Indeed, for POST, servers already have to be resilient to authenticated
hostile POSTs of arbitrary content, since you can send any authenticated
data using <form> and text/plain enctypes today. I don't think we need to
do a pre-check for GET or POST.
I'm not comfortable doing POST without checking if it's safe first
either. I do realize that this is something that can already be done
today, but I suspect that is already a problem, just one that hasn't
gotten exploited yet. So I'd rather not add to that if I can avoid it.
For methods like DELETE it could obviously be harmful to send to random
servers that support that method. Like Ian points out, there might very
well be servers living inside firewalls that support that method and
don't do any other security authentication other than relying on the
firewall.
Also note that the server can make the GET request be cached in the
browser which should make the overhead of a GET fairly low.
/ Jonas
