Question

CouchDB has a mechanism in place to prevent unauthorized writes.

Can it also prevent unauthorized reads?

Answer 1

Yes, CouchDB can prevent unauthorized reads. Unfortunately, it is slightly less straightforward.

Imagine a secret auction application. You bid $20 and I bid $10; each bid in a couch document. Couch lets us read our own bid documents but no others. However, there is a map-reduce view showing the average. I load the view and see that the average is $15, so I conclude that your bid is $20 and I have broken the security policy. View output can leak some or all of a document’s information. It is not feasible to enforce security at the document level. That is why read access is at the database level.

I know, it sucks. But that is the only correct, scalable answer.

This is part of the reason the Couch philosophy is to create many databases—even one (or more!) per user. Read permission to a database is set in the readers value of the database _security object. (Note, the field readers was renamed to members in CouchDB trunk because it also specifies who may write to the DB.)

The technique works like this:

1. Create a database for each user. It will hold all documents the user may read. Add the user (or the user’s role) to the _security object.
2. In the master database, create a filter function which implements the read policy. (It could share code with validate_doc_update.)
3. Replicate from the master database to the user’s database with ?filter=my_filter_function.
4. Allow the user to load (or replicate from) their database.

Of course, this is all for a pure Couch application, where users access Couch directly. If you have a middle layer (MVC controller, or just a reverse HTTP proxy), then you can enforce policy there, between the user and the couch. But be careful. For example, a _show function or a _rewrite rule might allow a user to load a view or document despite your policy.

Good luck!