W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

CORS performance proposal

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 19 Feb 2015 14:29:24 +0100
Message-ID: <CADnb78jT_a1=Q9N+7KoYk1XtvaPgrp+1-7xXneLMt2iZKBZrEQ@mail.gmail.com>
To: WebAppSec WG <public-webappsec@w3.org>
Cc: WebApps WG <public-webapps@w3.org>
When the user agent is about to make its first preflight to an origin
(timeout up to the user agent), it first makes a preflight that looks
like:

  OPTIONS *
  Access-Control-Request-Origin-Wide-Cache: [origin]
  Access-Control-Request-Method: *
  Access-Control-Request-Headers: *

If the response is

  2xx XX
  Access-Control-Allow-Origin-Wide-Cache: [origin]
  Access-Control-Allow-Methods: *
  Access-Control-Allow-Headers: *
  Access-Control-Max-Age: [max-age]

then no more preflights will be made for the duration of [max-age] (or
shortened per user agent preference). If the response includes

  Access-Control-Allow-Credentials: true

the cache scope is increased to requests that include credentials.

I think this has a reasonable tradeoff between security and opening up
all the power of the HTTP APIs on the server without the performance
hit. It still makes the developer very conscious about the various
features involved.

The cache would be on a per requesting origin basis as per the headers
above. The Origin and Access-Control-Allow-Origin would not take part
in this exchange, to make it very clear what this is about.

(This does not affect Access-Control-Expose-Headers or any of the
other headers required as part of non-preflight responses.)


-- 
https://annevankesteren.nl/
Received on Thursday, 19 February 2015 13:29:50 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC