[Good practice] Should I allow (web) clients to have direct access to CouchDB?

[cluxter]

Hi everyone,

We can create users in CouchDB with different rights. But is it okay to let the (web) clients have a direct access (read/write) to CouchDB? And most importantly: why?

The use case here would be a website used by anyone, so not only trusted users.
My concerns are mainly about security (but other comments about performance, quality of service, or other things are welcome).

Thanks & regards,

cluxter

[SinanGabel]

Here's a good reference (but there are also other considerations and possibilities). https://github.com/pouchdb-community/pouchdb-authentication/blob/master/docs/recipes.md

…

On Sat, 11 Jul 2020 at 22:12, Baptiste REBILLARD ***@***.***> wrote: Hi everyone, We can create users in CouchDB with different rights. But is it okay to let the (web) clients have a direct access (read/write) to CouchDB? And *most importantly: why*? The use case here would be a website used by anyone, so not only trusted users. My concerns are mainly about security (but other comments about performance, quality of service, or other things are welcome). Thanks & regards, cluxter — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3000>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKTZUQCUPT6KNIXMOZIJM3R3DBRBANCNFSM4OXOPIDQ> .

[ermouth]

As Couch provides http access better question is “why not”. Some notes:

• Security system of CouchDB is very simple and proven to be pretty sturdy. There was only one very serious issue, CVE-2017-12635, during last 10 years.
• Security system will not save you from DoS attacks, so consider external rate limiting for any serious production system. Very basic reverse proxy in front of Couch may help with rate limiting.
• Consider hiding some sensitive endpoints, ie exposing _all_dbs for pre-3.x might be very unsafe. Reverse proxy may help with hiding.
• Bucket read access for unauthorized users is more or less fine for not very large buckets (I mean number of docs mostly) containing no sensitive data. For large buckets consider there could exist very costly requests (like _find, as well as filtered _changes or _all_docs with include_docs=true/attachments=true). Also please remember that publicly available bucket exposes all its _design/ docs, which in some cases might be unacceptable.
• Write access for unauthorized users should be forbidden in most cases, however if a bucket is public please note that replication clients are generally allowed to write _local/ docs as checkpoints. Since _local/ docs consume space like any other docs, you may lead to disk exhaustion.
• Write permissions controlled using validate_doc_update functions are not so cheap and not so fast as unexperienced developer might think. Erlang validators are generally much more cheaper and faster, however parsing and checking JSON (especially not absolutely valid JSON, ie with duplicate keys) using Erlang validate_doc_update is very dark magic.

[janl]

@cluxter good question! CouchDB works fine in a traditional three tier architecture behind an application server that in turn is the only resource that has access to the database. But another option is having an open CouchDB on the internet. This is particularly useful when building offline-capable web-apps with PouchDB. In that case, CouchDB and PouchDB should be talking to each other directly, so you will be relying on the CouchDB authentication system for access control. It was designed for this specific use case.

There are some limitations as @ermouth points out, but for the most important ones (IMHO), rate limiting, you can introduce an otherwise transparent HTTP proxy.

tl;dr: CouchDB doesn’t force you to do this, but if you need it for sync with e.g. PouchDB, you can use it.

[cluxter]

Thanks to you all for your answers, it's really helpful!

One thought I had when reading your answers was: putting something like Node.js as a middleware between CouchDB and the client looks like it can increase the level of security, but it could as well weaken it by introducing some flaw(s). Actually a developer is more likely to introduce a flaw by himself developing a middleware than using the default CouchDB security layer which has been made and reviewed by several highly skilled people.