This would probably be helped by restricting to same-origin policies.
But I'd like to have good usecases even for adding that. I think site
authors would be upset if they couldn't rely on referer (which
arguably already is an issue since some firewall produces block
outbound referer headers).
There's no arguably about it, many firewall's block it, as do others to
anonymise user activity through the web, such things cannot be relied
on. I also don't see the author use cases for shopping cart checks?
Surely these use cookie based state methods.
Cookie based solutions won't work since cookies are sent with XHR. So to
the site it'll look like this was a real request.
What sites should do is to stick a random value in each form request and
use that to authenticate each form transaction. However I believe many
sites does not do that.
Site authors already cannot rely on referrer, so quite why they should
be able to rely on it with XHR I don't know, forcing special behavior on
UA's depending on where a request comes from seems to be something you
should do only in the most extreme situation.
Saying that referrer can't be overriden isn't really 'forcing special
behaviour'. The header is usually sent with every other request the UA
does without giving control to the page of its value.
/ Jonas
