W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [cors] JAX-RS and preflight

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 2 Dec 2011 12:15:03 -0800
Message-ID: <CA+c2ei_pNU9C-11Ww5inMMgZC9wYjRE6=MxAxtokBcoiuZi0OQ@mail.gmail.com>
To: Benson Margulies <bimargulies@gmail.com>
Cc: public-webapps@w3.org, Sergey Beryozkin <sberyozkin@gmail.com>
On Fri, Dec 2, 2011 at 5:29 AM, Benson Margulies <bimargulies@gmail.com> wrote:
> Jonas,
>
> Let me circle back to the top now and see if I can play this back.
>
> 1. Of course, when writing a server, it's up to me to implement access
> control decisions.
>
> 2. To protect a plethora of poorly-protected servers out there, CORS
> puts an additional level of access control in clients.
>
> 3. To expose resources cross-origin, my service has to reassure the
> client that it does, indeed, know what it is doing. That  reassurance
> is delivers via the CORS headers.

Correct so far.

> 4. There's a impedance mismatch between the CORS model of resource
> control, which is URI+method, and the JAX-RS model, which adds other
> headers.

CORS provides the ability for fine-grained opt-in to various aspects
of http. This so that you can choose which parts of http you want to
guarantee that you have secured in your server-side scripts. I.e. CORS
isn't simply a on/off switch requiring perfect knowledge of everything
you do on your server in order to flip to the "on" mode.

However the fine-grained opt-in is only so fine-grained. We don't for
example have the ability to say "I'm only fine with receiving the
x-my-header header if it contains one of the following values", or say
"I only want to expose the x-my-response-header if it isn't doesn't
start with 'user-id:".

Similarly, we don't provide the values of any headers when making the
preflight OPTIONS request.

My english isn't good enough to say if this qualifies as an "impidence
mismatch" or not (wikipedia was unhelpful [1]). But I agree that it
means that means that you have to do some security checks in the code
that handles the request, and can't rely exclusively on CORS enforcing
your security model.

[1] http://en.wikipedia.org/wiki/Impedance_mismatch

> 5. A server thus must return CORS indications at the level  of
> URI+method. This 'opens the door' in the client -- and then the server
> is responsible for imposing any fine-grained access control that it
> wants at the level of the other headers.

Yup.

/ Jonas
Received on Friday, 2 December 2011 20:23:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT