The reason I didn't use _security for CORS

[Jason Smith <jh...@iriscouch.com>]

Hi, Randall. Guess I'll CC the dev list too.

I remember why I decided not to use the db _security object for CORS
policy in my COUCHDB-431 patch.

Basically, CORS is about how one *domain* interacts with another. That
is primarily how browsers see things.

Of course, every resource (URL) can have its own CORS policy, however
if you read the standard I think you'll agree the basic idea is one
domain's relationship to another.

Next, CORS is sort-of a security feature and sort of not. But I got
concerned when I read around the web and it seems like everybody
thinks CORS is adding a wildcard in some header and, by magic, it
works.

That wildcard means that any web site can make any browser send any
query to your couch. Oh, pooh! You've got a _security.readers. Just
add Access-Control-Allow-Credentials: true.

Whoops. Now any site can have any browser make any change to your
database. If the user was _admin, now the site has _admin access to
your couch. validate_doc_update can help, but nobody writes
validate_doc_update. It's hard enough getting people out of the Admin
Party, much less writing a security validator by hand. (Note that the
CouchDB company with its shit together, Cloudant, has written a
dead-simple GUI to address just this issue.)

So I do think there is a security component to CORS, even security of
the couch data itself. People say CORS is about browser security or
user security and not server security, but CouchDB is so deeply "of
the web," the line is blurry.

Hence my idea was to nudge people in the direction of whitelists, and
also make them explicitly authorize _admin activities over CORS.

Hope that clarifies all the questions you don't have. Cheers!

-- 
Iris Couch