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
