Re: The HTTP Origin Header (draft-abarth-origin)

On Mon, Jan 26, 2009 at 2:00 AM, Thomas Broyer <> wrote:
>> Thus I think it's a mistake to reveal the originating host name. This
>> proposal would probably be much more likely to succeed if someone
>> devised a way to describe the "URI proximity" of the origin URI to the
>> target URI.
> It would rule out communication from/to to/from
>, and it would make Origin much less appealing...
> I believe there are legitimate needs for cross-site requests that are
> not CSRF attacks (product-to-company; federated SSO; etc.)

Yes, I fully agree that it would rule out stuff like that. If the goal
of the header is to selectively allow cross-site requests from
arbitrary domains, my suggestion won't work. If the goal is only to
block CSRF, then the Origin header sends much more information than
necessary. The fact that you think it will be useful for federated SSO
should be a warning sign.

So, does the header send more information than necessary? Beats me. If
it does, then the author should come up with a little syntax to
characterize the delta between two URIs, at least to the level of host
component similarity. I do not think it is one of technology's great
unsolved problems. It is also not my job to produce such a syntax,
despite the author's implications otherwise. It might be the case that
it's more information than necessary, but it's not worth fixing the
header to make it send less information. It's hard to debate such a
point without knowing (wait for it) whether the header sends more
information than necessary.

Given the number of times unforeseen reuse has caused clients,
proxies, and servers have to block access to headers in various ways,
you'd think the most minimal approach would be best.

You can Solve Any Problem... ...if you're willing to make the problem
small enough.


Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Received on Monday, 26 January 2009 21:25:49 UTC