CouchDB and Cloudant Security

Question

We have used CouchDB in production, mainly building apps in controlled environments. Most times, we use a middle-ware library to make direct calls onto couchdb/cloudant, hence avoiding direct (Front-End JavaScript calls direct onto CouchDB/Cloudant).

For security reasons, it is obvious that for an authenticated CouchDB database:
http://{username}:{password}@IPAddress:Port/DB
OR for cloudant:
https://{username}:{password}@username.cloudant.com/DB , If the call is directly made from JavaScript, Developer tools in the browsers today enable a person to realise this call and hence has access to your database entirely.

Attachments are usually painful when handled in the middle-ware. It is advantageous to make cloudant handle the caching and serving of the attachments directly to the front end hence relieving our middle ware from that. However, on the web and with a huge audience, making direct calls to our cloudant environment is tricky.

We started out by first of all having a separate cloudant account for all attachments such that, an inquisitive boy will not tamper with the actual meta-data or information of our users. So, the only cloudant account they can have access to is that of the attachments since we are making direct JavaScript calls to our database.

Question: How do we find a way in which we hide the Username and Password of our cloudant environment thereby allowing us to securely make direct JavaScript calls onto cloudant ? Our infrastructure is entirely in the cloud, so we don't have proxies and stuff to work with. We have heard of Url shortening services, CDNs e.t.c. but, we have not come up with a really conclusive solution.

Chlo

Answer 1

Try using the _session endpoint. This will set up cookie authentication.

Flora

Answer 2

How do we find a way in which we hide the Username and Password of our cloudant environment thereby allowing us to securely make direct JavaScript calls onto cloudant ?

As far as I know you can't do that without using a middleware or some kind of proxy. But that does not mean we are completely defenceless. couchdb gives us some spears to poke inquisitive boy :)

So a good thing that you have done is to make the attachments database seperate. You don't mention in your question if you are using couchdb authorization scheme so I going to assume that you are not. So the first step is to create a user in couchdb _users database and then assign it as a member in the attachments database. More details here and here.

After this step you should have a member on attachments database. The reason we want a member and not an admin is that members do not have permissions to write or read design documents.

It's a start but it's not enough since a member can still read via _all_docs and that is a dos attack right there. So the problem we face now is that we do this at the moment

https://{username}:{password}@username.cloudant.com/DB

A very good move would be to change it to

https://{username}:{password}@someurl.com/

What's the difference between these two? Well it hides the location of your database and makes accessing built in methods harder. This can be accomplished with the help of vhosts configuration and some rewrite rules. Some very good stuff is on Caolan's blog too

With this in place you have got two things going for you.

1. The stalker inquisitive boy will be clueless where the calls go to.

2. There will be no way he can get the contents of unknown documents by making direct calls. He can only access your database through the rules that you set.

Still not 100% secure but it's okay as far as read level security goes. Hope this helps.

Protestantism