Explore key concepts in security and authentication for CouchDB, including access control, user management, and safe database practices. Perfect for anyone seeking to strengthen their understanding of protecting data and managing users effectively in CouchDB environments.
When a new database is created in CouchDB with default settings, who can read and write to it?
Explanation: By default, new databases allow anyone with network access to both read and write data unless specific security settings are applied. Only allowing the creator or system administrators would require additional configurations. Restricting access to authenticated users only is not the default setup. Misunderstanding these defaults can expose data unintentionally.
Which action is only allowed for an administrator in CouchDB?
Explanation: Only administrators can modify the _security object, which controls access permissions in the database. While any user may create or read documents if the database is open, changing security configuration is a privileged task. Simply browsing the database does not require special privileges unless explicitly restricted.
Which method does CouchDB use for authenticating users by default?
Explanation: CouchDB uses HTTP Basic Authentication by default, where credentials are base64-encoded in HTTP headers. OAuth and LDAP may be configured separately but are not enabled by default. Kerberos ticket-based authentication is not a built-in method in the standard setup.
What is the primary purpose of the _users database in CouchDB?
Explanation: The _users database is designed to store user documents, including credentials and metadata related to users. Document attachments and design documents are stored within other databases or specific documents. While conflict resolution is part of database operations, it is not the focus of the _users database.
Which action best helps protect sensitive data in a CouchDB database?
Explanation: Properly configuring the _security object ensures that only authorized users can access or modify sensitive data. Open read access puts sensitive data at risk, while disabling replication doesn't address security but affects data availability. Document size does not impact security directly.
In CouchDB, how are session cookies typically used during authentication?
Explanation: Session cookies are used to keep users logged in without requiring credentials for every request. Storing raw passwords in cookies is unsafe and not a standard practice. Cookies do not encrypt documents or grant admin roles automatically.
How is a new user record most commonly added to CouchDB for authentication?
Explanation: To add a new user, you create a properly structured document in the _users database. Sending email invitations is not part of the authentication system by default. The _replicator database handles replication tasks, not users, and uploading attachments is unrelated to user creation.
Applying the principle of least privilege in CouchDB means what?
Explanation: This principle ensures users are granted only permissions necessary for their tasks, reducing security risks. Allowing universal edit access or default admin rights violates this concept. Allowing deletion of system files is both unsafe and uncommon.
Why should you enable HTTPS in a CouchDB setup handling sensitive information?
Explanation: Enabling HTTPS encrypts data transmitted between clients and the server, protecting against interception. Compression may happen via other means but is not the purpose of HTTPS. Query speed or data storage formats are not affected by enabling HTTPS.
In CouchDB, what can the 'guest' user do by default on an unsecured database?
Explanation: The guest user, representing unauthenticated users, can read and write documents on unsecured databases by default. They cannot manage admin configurations, which require privileges. Restricting guests to design documents or requiring registration needs explicit settings.