W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

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

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 22 Jan 2009 17:35:28 -0800
Message-ID: <7789133a0901221735g72c193fcjc95e6f182f088432@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Larry Masinter <LMM@acm.org>, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org, Lisa Dusseault <ldusseault@commerce.net>

On Thu, Jan 22, 2009 at 3:07 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> 1) CSRF is not a security issue for the Web.  A well-designed Web
> service should be capable of receiving requests directed by any host,
> by design, with appropriate authentication where needed.

Many Web sites contains CSRF vulnerabilities and find it difficult to
engineer CSRF defenses.  The goal of the Origin header is to make it
easier for these sites to defend themselves against CSRF attacks.  For
example, a site can use the header to defend itself against CSRF using
a simple Web application firewall.

> If browsers
> create a security issue because they allow scripts to automatically
> direct requests with stored security credentials onto third-party
> sites, without any user intervention/configuration, then the obvious
> fix is within the browser.

What obvious fix do you have in mind?  A browser vendor who removes
cookies from cross-site requests would quickly find that their users
choose to use another browser.

> 2) It doesn't prevent CSRF attacks because it doesn't prevent the
> Origin header field from being spoofed.

Do you have an example of how the Origin header can be spoofed in a
cross-site request in a browser with more than 1% market share?  You
can "spoof" the Origin header when sending a same-site request, but I
don't know of any techniques for spoofing the header in a cross-site

> It therefore only improves
> a very small situation: a new browser that has implemented this new
> header *and* allows cross-site scripted requests *and* prevents any
> manipulation of the request header fields *and* is still stupid
> enough to include stored credentials in the cross-site request.

An browser-side CSRF defense will have this property.  As more
browsers adopt the header, this situation will grow to encompass a
large percentage of the browser market share.

> 3) It requires servers to maintain a table of "compliant" user
> agents in order to distinguish spoofed or dropped origin fields,

I experimentally measured how often the Origin header is dropped in
the real world, an it is not dropped greater than 99.9% of the time.
The details of the experiment are described in:


I don't believe such a table is necessary.  The presence of the Origin
header itself indicates that the user agent supports the header.

> 4) Even if such a feature becomes necessary, it can be far
> easier accomplished by changing the operational behavior of
> browsers such that they always send Referer

The Referer header is suppressed in the network for HTTP requests
approximately 3% of the time.  As a Web site operator, I cannot use
strict Referer validation to defend against CSRF because I'll miss out
on 3% of my customers.  (Again, these numbers come from the same
measurement study.)

> and simply reduce
> the value of that field (similar to that specified for Origin)
> in those cases where it is currently not set at all.

The Referer header is stripped in the network layer regardless of the
value it contains.  Truncating its contents does not help defend
against CSRF.

> 5) The author seems to be unaware that URL is a deprecated term
> defined in RFC 3986. The field values would be better defined
> in terms on the standard URI grammar and terminology.

I'll fix this in the next version.

Thanks for your comments,
Received on Friday, 23 January 2009 01:36:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:48 UTC