Why Does CouchDB Require an Admin Account to Start? posted Wednesday, July 24, 2024 by The Neighbourhoodie Team

In CouchDB 1.x, one of our [the CouchDB developers’] overarching goals was to create a database that is easy to use. We spent many years refining the CouchDB REST API to make it as easy and as convenient as possible, so people don’t get turned away from using CouchDB by how hard it is to use.

We mainly succeeded at that goal, and still today, nearly 15 years later, we keep hearing stories that people just used CouchDB for something small and that they just stuck with it, because it was so easy to use.

However, having an internet-connected database server that has no password by default leads to people accidentally leaving their CouchDB unsecured and losing their data.

In 2.x, we took great pains to build a scalable and highly-available clustered database underneath that same API, so applications built for CouchDB 1.x continued to run just fine on a 2.x installation. With 99% API compatibility, we pulled this off successfully as well and the 3.x release series continues this feat. Applications mostly just work when they are migrated to newer versions of CouchDB.

One of the aspects of getting started easily was a 1.x-era choice to make it easy to use CouchDB: the Admin Party. Admin Party means that, by default, any request made to CouchDB was done in the context of an admin user, i.e. everybody was allowed to do anything.

To make CouchDB approachable, at the time, we didn’t want to burden people with setting up accounts and passwords, and mess with permissions and whatnot. This too was a good choice for getting people started, but when building modern, internet-connected database projects, not having admin passwords is a very bad idea.

Of course, you were able to create users and set up sophisticated permissions even in CouchDB 1.x, but over time it became clear that a default of “everyone is an administrator” is not only a very bad idea, but actively terrible. While CouchDB has not been part of a larger data breach just yet, we do have reports of people getting bitcoin miners installed on their database servers through an inadequately secured CouchDB setup.

In 2.x we took some steps to make it easier to set up a more secure CouchDB installation, like enforcing an admin password when you start with a cluster setup. But you could still install a single-node setup with an Admin Party so that newly created databases were accessible to anyone until locked down.

In 2020, with the release of CouchDB 3.0, we switched our security philosophy from “open by default” to “closed by default”.

That means in all configurations of CouchDB, you will have to provide an admin password before the database server starts. You do this as usual by editing your local.ini file before starting CouchDB.

With no admin configured, CouchDB prints a loud and clear error message about that fact. The Mac and Windows binaries are going to prompt you for a password during the installation phase.

This effectively ended the era of the Admin Party. Fun was had, but we needed to move on and keep everyone safe.