Authentication & Access Control
Database Security
Chapter 2 · Authentication & Access Control
Chapter 1 flagged misconfigured access as one of the most common, most preventable causes of a real breach. This chapter is where that gets fixed: the database's own account system — a genuinely separate authentication layer from the application-level login the Authentication & Session Security course (bc1) already covers.
Two Separate Authentication Layers
It's easy to think "we already covered authentication" after the bc1 course — but that course is about end users logging into the application. The database has its own, entirely separate authentication layer: the application itself has to authenticate to the database, using its own credentials, regardless of who the end user is.
Application-Level Auth (bc1 course) | Database-Level Auth (this chapter) | |
|---|---|---|
| Who authenticates | the end user, via the app's login form | the application itself, via a database account |
| Credential type | a hashed password, a session/token (bc1-2, bc1-7) | a database username and password (or certificate) |
| Where it happens | the app's own login endpoint | the connection string the app uses to reach the DB |
| End user ever sees it? | yes — it's their login | no — entirely invisible to end users |
An end user is never a database account. Every request an application handles — regardless of which end user made it — reaches the database as the same application-level account. That account's own security is this chapter's subject.
Database Accounts: Getting the Basics Right
A database account for an application should be created specifically for that application — never the database's own built-in superuser/root account, which exists for administration, not routine application traffic. Chapter 1's warning about default credentials applies directly here: every database ships with (or defaults to) some form of administrative account, and leaving its factory password unchanged is one of the single most common real-world misconfigurations found in the wild.
Role-Based Access Control (RBAC) in the Database
Creating an account only answers who can connect — authorization (distinct from authentication, the same distinction bc1-1 drew for the application layer) answers what that account is actually allowed to do once connected. Most databases implement this through roles and GRANT/REVOKE statements.
This chapter introduces the concept; Chapter 3 goes deep on designing exactly which grants an account should have, including the "just grant everything, it's easier" anti-pattern this chapter's next section already starts flagging.
Avoiding Shared & Generic Accounts
A single shared account — "just use the admin login, everyone does" — used by every developer, every script, and every service is a genuinely common real-world pattern, and a seriously damaging one. Beyond the obvious blast-radius problem (one leaked password compromises everything that used it), a shared account destroys something Chapter 7 (auditing) depends on entirely: the ability to answer who did something.
| One Shared Account | Individual Accounts | |
|---|---|---|
| Audit log shows | "admin ran this query" — for every person and service that ever used it | exactly which person or service ran it |
| Revoking one person's access | impossible without changing the password everyone relies on | revoke that one account; nothing else is affected |
| Blast radius of one leak | every user of the shared account is compromised | only that one account |
bc1-1 drew for the application layer applies here too: authentication is the database confirming an account's identity (a valid username/password); authorization — RBAC, GRANT/REVOKE — is the database enforcing what that authenticated account is actually allowed to do. Getting authentication right but leaving every account with blanket privileges solves only half the problem — the half Chapter 3 goes deep on.
Hands-On Exercises
Explain the difference between application-level authentication (the bc1 course) and database-level authentication (this chapter). Does an end user's login ever directly authenticate them to the database? Why or why not?
Write the SQL to create a database account called reporting_job and grant it read-only access to a database called shop. Explain why this should be a separate account rather than reusing the main application's account.
A team of five developers all connect to the production database using one shared admin login. One developer leaves the company. Explain everything that goes wrong with this setup, tying your answer to both this chapter and the forward-reference to auditing (Chapter 7).
Chapter 2 Quick Reference
- Application-level auth (
bc1) and database-level auth (this chapter) are two separate layers — an end user is never a database account - Every application needs its own dedicated database account — never the database's built-in admin/root account
- Default/factory admin passwords left unchanged are one of the most common real-world misconfigurations
- Authentication = who can connect; authorization (RBAC) = what they're allowed to do once connected
GRANT/REVOKEassign specific privileges to specific accounts — Chapter 3 covers designing these grants in depth- Shared/generic accounts destroy accountability (can't tell who did what) and widen blast radius on a leak — treat them as a finding, not a convenience
- Next chapter: Least-Privilege Account Design — separate accounts per service, granular grants, avoiding the "superuser for everything" anti-pattern