Re: CORS explained simply

There are addressed in the security considerations section:
http://www.w3.org/TR/cors/#security

The particular bit of most relevance is:

"A simple cross-origin request
<http://www.w3.org/TR/cors/#simple-cross-origin-request> has been defined
as congruent with those which may be generated by currently deployed user
agents that do not conform to this specification. Simple cross-origin
requests generated outside this specification (such as cross-origin form
submissions using GETor POST or cross-origin GET requests resulting from
script elements) typically include user credentials
<http://www.w3.org/TR/cors/#user-credentials>, so resources conforming to
this specification must always be prepared to expect simple cross-origin
requests with credentials."

Essentially, CORS was designed so it did not expand the threat model of
existing services deployed in the field.  And to relax the existing
security model, a resource (AKA the server) must explicitly indicate that
it is amenable to such relaxation.

Nothing stops a user agent from allowing users to grant cross-origin
privileges to some code, but that is not standardized.  Typically the way
do to this is through an extension mechanism.  I think there is little or
no interest in standardizing a mechanism to grant web resources permissions
to break the Same Origin Policy with user permission, because of the long
and entirely ignominious history of similar things (see: ActiveX).  You
can't simply allow code to declare itself privileged in that regard, and
experience shows that it is extraordinarily difficult to ask the user to
make a meaningful and informed choice that maintains their safety.  So the
fallback position has been to reserve such privileges for extension
mechanisms where some level of additional review and feedback can be
applied at the distribution points, on the user's behalf, to protect their
interests.  Or you can write your own extension for your own browser to do
such things.

In the near future, we may be able to do more interesting things for users
if we are able to create robust confinement mechanisms that allow new kinds
of information flows without violating the security assumptions of existing
applications.  The proposed COWL deliverable on this group's new charter is
a step in that direction.  But I don't think you will find much support for
anything resembling a pop-up dialog that asks users if they'd like to let
this web page read their banking details, etc.



On Thu Feb 19 2015 at 2:19:54 PM henry.story@bblfish.net <
henry.story@bblfish.net> wrote:

> Hi,
>
>  I find that understanding CORS is a really not easy.
> It seems that what is missing is an general overview document,
> that would start by explaining why the simplest possible method
> won't work, in order to help the user understand then why more
> complex method are needed.
>
> For example the first thing one should start by explaining is for
>
> 1) requests that do not require authentication
>   q1: why is the origin sent at all? And why are there still restictions?
>   q2: why does POSTing a url encoded form not require pre-flight? But why
> does POSTing other data do?
>
> 2) On requests that do need authentication:
>   q3: Why are the pre-flight requests needed at all?
>
> I know that the answer to q1 is that some servers have access control
> methods
> based on ip address of the client. But it is worth stating clearly the
> requirement
> in the specs so that this can be understood.
>
> There is also the question as to why the server needs to make a decision
> as to
> what the client can see. But why can't it be the client? After all the
> user could
> decide to give more rights to some JS apps than to others, and that would
> work too.
>
> I am not saying that these questions don't have answers. It is just that
> they
> would help a developer understand why CORS has taken the shape it has, and
> so
> understanding the reaons for the decisions taken, better be able to think
> about it.
>
> Henry
>
>
> Social Web Architect
> http://bblfish.net/
>
> Social Web Architect
> http://bblfish.net/
>
>
>