[whatwg] CSRF and Access-Control-Origin

[Adam Barth]

Cross-site XMLHttpRequests include an Access-Control-Origin HTTP
header that indicates the principal who initiated the request:

http://www.w3.org/TR/access-control/#access-control-origin0

If browsers attached this header to POST requests, servers could more
easily defend themselves against cross-site request forgery (CSRF)
attacks.

Currently, browsers send the Referer header, which indicates the URL
of the page that initiated the request.  The Referer header is
unreliable because many users and corporate installations suppress the
header due to privacy concerns.  For example, suppose a company hosted
a page on its Intranet with the following URL:

http://wiki/Competitive_Analysis_for_Secret_Project_XYZ

which linked to competitors for Secret Project XYZ.  The Referer
header would leak the existence of the secret project to its
competitors.  Many proxies strip the Referer header as a matter of
course.

For these reasons, sites that attempt to use the Referer header to
block CSRF attacks permit cross-site requests that omit the Referer
header.  Unfortunately, attackers can easily suppress the Referer
header in all major browsers, for example by initiating the request
from an FTP page or by first navigating to a javascript:"..." URL, and
can mount CSRF attacks against these sites.

Attaching the Access-Control-Origin header to POST requests provides
better privacy/security trade-off than attaching the Referer header to
every request:

1) The Access-Control-Origin header contains only the information
required to make a CSRF security decision and not extraneous data,
such as the path and query parameters, that can contain sensitive
information.

2) Attaching the header only to POST requests reduces the information
leakage from simply clicking hyperlinks.  Secret web pages are
unlikely to POST to untrusted web sites (although they often hyperlink
to them).

Adam