Access Control for Cross-site Requests DESIGN DECISION FAQ

** Why is there a second check for non-GET requests?

For non-GET requests two checks with Access-Control HTTP headers and
<?access-control?> processing instructions are performed. Initially a
"permission to make the request" check is done on the response to the
authorization request. And then a "permission to read" check is done on the
response of the actual request. Both of these checks need to succeed in
order for success to be relayed to the protocol (e.g. XMLHttpRequest).

** Why are cookies and authentication information sent in the request?

Sending cookies and authentication information enables user-specific
cross-site widgets (external XBL file). It also allows for a user
authenticated data storage API that services can use to store data in.

Cookies and authentication information is already sent cross-site for the
HTML <img>, <script>, and <form> elements so this does not introduce a new
attack vector. It simply makes use of the Web.

** Why can't cookies authentication information be provided by the script
author for the request?

This would allow distrubted cookie / user credentials search.

** Why is the client the policy enforcement point?

The client already is the policy enforcement point for these requests. The
mechanism allows the server to opt-in to let the client expose the data.
Something it currently does not do and something which servers rely upon the
client not doing.

Note however that the server is in full control. Based on the request it can
simply opt to return no data at all or not provide the necessary handshake
(in form of the Access-Control HTTP headers and <?access-control?>
processing instructions.

** Why does the mechanism do both black- and whitelisting?

In case the server and documents hosted on the server are in control by
different people it is necessary that the server people are able to override
the document people (if the document wants to share access) and vice versa
(if the server wants to share access).