Re: CORS

On Wed, Oct 11, 2017 at 3:00 PM, Jack (Zhan, Hua Ping)
<jackiszhp@gmail.com> wrote:
>>> I have already responded this to Tab Atkins as follows:
>> You have not. And I ask again. How do you instruct a browser which resource
>> is ok to request from another origin?
>
> When I said "as follows:", the answer text followed. And I elaborated
> a bit more than asked, and at the end I challenge you to defeat me.
> Please read that or here:
> http://lists.w3.org/Archives/Public/public-webapps/2017OctDec/0024.html
> There is no point for me to copy it here again.
>
> But in one sentence: I do not need the browser to do the authorization
> check for me, I do the authorization check myself at server
> https://bankA.com/.

And that's the thing. *You* might do that, and be safe from evil
websites grabbing your customer's personal information. Long, painful
experience shows us that *most* websites do *not* do that.

So, we have two choices:
1. Make websites default to being "open" cross-origin, and depend on
website owners to lock down pages with private info on their own. Pro:
good websites can share information cross-origin really easily. Con: a
lot of people get their private information stolen, and the web as a
whole has sucky security.
2. Make websites default to being "closed" cross-origin, and let
website owners explicitly open them up if they're safe to share. Pro:
most pages are safe from evil websites by default. Con: slightly more
work for websites to share public information.

The web went with #2, and as a result you have good security by
default.  (As Jake has said, some resources that were linkable in the
early web, like images, are stuck with #1. Changing them at this point
would break too much of the web, but as a result we have regular
security issues.)

This is a result of pretty basic security practices that are now
common on the web.  It's not going to change.  You've had the
reasoning behind CORS explained to you several times, and why your
suggestions for an alternate system would be bad for security and
won't be accepted by browsers today.

Unless you have further actual questions, continuing in this thread
will not be productive. You will not change anyone's minds, because
we've thought about the security implications quite a bit before
settling on the current CORS design.  It's a compromise, and has some
downsides, but overall it results in a much safer web with relatively
little pain.

~TJ

Received on Wednesday, 11 October 2017 22:28:03 UTC