The SQL Injection course covered attacks that reach the database through the application — untrusted input crossing the app's own trust boundary. This course covers a different question entirely: is the database itself, as a running piece of infrastructure, actually secured? Accounts, network exposure, encryption, backups, auditing — all of it orthogonal to whether the application's queries are parameterized correctly.

Two Threat Models, Not One

It's tempting to think "we fixed our SQL injection, our database is secure." That conflates two genuinely separate threat models:

A perfectly parameterized application sitting on top of a database with a default admin password, exposed directly to the internet, is still a breach waiting to happen — the SQLi fix never touches any of that.

Insider Threats

SQLi's threat model assumes an external attacker working through the app. But a real, sizable share of data breaches come from people who already have legitimate database access — a disgruntled employee, a departing contractor whose account was never revoked, or simply a careless staff member with far broader access than their job needs. No amount of query parameterization defends against someone who can already run SELECT * FROM customers directly, because they were handed a working set of credentials.

Misconfigured Access

Default credentials left unchanged after installation, one shared "app" account used by every service and every developer, and overly broad grants ("just give it ALL PRIVILEGES, it's easier") are some of the most common — and most preventable — real-world causes of a database breach. Chapters 2 and 3 cover the fix in depth: proper authentication and access control, and least-privilege account design.

Physical & Network Exposure

A database doesn't have to be broken into if it was never actually locked down: a database port bound to 0.0.0.0 and reachable directly from the public internet, an unencrypted connection over a network where traffic can be intercepted, or a laptop with a local copy of production data that gets lost or stolen. None of these require any cleverness from an attacker — Chapter 4 (network security) and Chapter 6 (encryption in transit) cover exactly this ground.

Backup Theft

A backup is a complete copy of the data the live database protects — and it's routinely protected far less carefully than the live system itself: sitting in a general-purpose file share, an unencrypted cloud storage bucket, or an old server nobody remembers is still running. An attacker doesn't need to breach a well-defended live database at all if an unencrypted, loosely-guarded backup of the exact same data is sitting somewhere easier to reach. Chapter 8 covers backup security as its own dedicated topic, not an afterthought to the "real" database.

What This Course Covers

Hands-On Exercises

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.

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.

Hands-On Exercises

Chapter 2 introduced GRANT/REVOKE and the concept of database roles. This chapter goes deep on actually designing those grants — the discipline of giving every account exactly the privilege it needs, and not one grant more.

The Least-Privilege Principle

Least privilege means every account — human or service — gets the minimum set of permissions required to do its actual job, nothing broader "just in case" or "to save time." It's the same principle this site's Laravel and Django courses applied to mass-assignment allowlists, and the Auth course applied to role design — here it's applied directly to the database's own grant system.

One Account Per Service, Not One Account Per "The App"

Chapter 2's reporting_job example already hinted at this: a real system is rarely just "the app" as one monolithic thing. A web application, a background job processor, a reporting/analytics job, and an admin panel are genuinely different services with genuinely different needs — each should get its own database account, scoped to exactly what that service does.

Granular GRANT/REVOKE

Privilege doesn't have to be all-or-nothing at the database level — most database engines support granting down to the table or even column level. A service that only needs a user's display name and avatar has no legitimate reason to be able to SELECT a password hash column, even on the very same table.

Read-Only vs. Read-Write Roles

Rather than hand-crafting an ad-hoc grant list for every single account, defining explicit roles — a named, reusable bundle of privileges — keeps grants consistent and reviewable.

The "Superuser for Everything" Anti-Pattern

"Just grant it ALL PRIVILEGES, it's easier" is the single most common way least privilege gets abandoned in practice — and it turns every account into an equally attractive, equally catastrophic target.

This is the exact same principle the MongoDB course's mongodb2-7 chapter drew for MongoDB's own root versus scoped readWrite roles — least privilege isn't a MySQL-specific or Postgres-specific idea, it's a property every database engine's own account system is built to support, and every engine's documentation strongly recommends applying.

Hands-On Exercises

Chapter 1's warning box described a wave of ransomware attacks against databases exposed directly to the internet — no exploit, no injection, just a reachable port with nothing guarding it. This chapter is the deep dive on exactly that failure mode: making sure the network itself never gives an attacker a path to the database in the first place.

Binding to Localhost / Private Networks Only

A database's own configuration controls which network interfaces it listens on. Binding to 127.0.0.1 (localhost only) or a private network address means the database is physically unreachable from the public internet, regardless of any firewall — there's no route to it at all from outside.

When the application and the database run on genuinely separate machines, "localhost only" isn't an option — bind instead to the private network interface (a VPC-internal IP) that only other machines on that same private network can reach, never a public IP.

Firewall Rules

Binding to a private interface handles reachability from the public internet — a firewall handles reachability from everything else, including other machines on the same private network that still shouldn't have a path to the database port. The rule to apply: allowlist only the specific hosts (application servers, a bastion host) that genuinely need to connect, and deny everything else by default.

VPN & Bastion Host Access Patterns

Developers and DBAs still legitimately need occasional direct access — but that doesn't mean opening the database port itself to their laptops. The standard pattern: route human access through a VPN (the vpn1 course covers setup) or a bastion/jump host — a single, tightly monitored server that itself is allowed to reach the database, which a person tunnels through via SSH.

The database only ever needs to trust the bastion host's own IP in its firewall rules — individual developers' laptops, on changing IPs from home or a coffee shop, never need direct network access at all.

Never Expose a DB Port Directly to the Public Internet

Every rule above serves one central conclusion: a database port reachable from 0.0.0.0/0 (anywhere on the internet) is a mistake, full stop, regardless of whether authentication is enabled. It's not a matter of "probably fine since there's a password" — it's an unnecessary, entirely avoidable exposure of a valuable target to every scanner on the internet.

Hands-On Exercises

Chapter 4 secured the network path to a running database. This chapter addresses a different question entirely: what if someone gets the raw storage itself — a stolen drive, a leaked cloud snapshot, or (Chapter 8's subject) an unprotected backup file? Encryption at rest is the answer to that scenario specifically.

What "At Rest" Means & The Threat It Addresses

Data "at rest" is data sitting on disk — data files, backups, snapshots — as opposed to data moving across a network (in transit, Chapter 6's subject). The threat model here is specific: someone obtains the physical or virtual storage medium itself, bypassing the network and the application entirely — a stolen laptop or server, a decommissioned drive that was never wiped, or a cloud storage snapshot that leaked or was misconfigured to be publicly readable.

Full-Disk Encryption

Full-disk encryption (e.g. LUKS on Linux, or a cloud provider's built-in encrypted-volume option) encrypts the entire disk or volume at the operating-system level — completely transparent to the database running on top of it, requiring no application or query changes at all.

Transparent Data Encryption (TDE)

TDE moves encryption one level down from the OS into the database engine itself — data files, logs, and the backups the engine produces are encrypted, decrypting automatically and transparently ("transparent" is literally the name) for any authenticated query. Available as a built-in or extension feature in most major engines (MySQL Enterprise, SQL Server, Oracle, PostgreSQL extensions).

TDE is closer to the data than full-disk encryption — it protects the database's own files specifically, even if they're copied out independently of the disk itself — but shares the exact same fundamental limitation: it decrypts automatically for any authenticated connection. A compromised database account, or a successful SQL injection, reads exactly the same plaintext TDE would have hidden from a stolen disk.

Column-Level Encryption

For especially sensitive individual fields — a Social Security number, a full credit card number — column-level encryption encrypts that specific value, typically at the application layer, such that even a legitimate, authenticated database query returns ciphertext unless the requesting code also independently holds the decryption key.

This is the one technique in this chapter that provides genuine defense against a compromised or overprivileged database account itself (Chapter 3's threat model) — a database account with full SELECT access still only ever sees ciphertext for that column without the separate encryption key. The trade-off: encrypted columns generally can't be indexed, searched, or sorted on directly by the database, since the stored value is no longer the real one.

Key Management Basics

Every technique above is only as strong as how its encryption key is protected — and the single most common mistake is storing that key right next to the data it encrypts (a key in the same config file, the same server, the same repository), which defeats the entire purpose: whoever obtains the data also obtains the key needed to read it.

• Never hardcode an encryption key in application source or commit it to version control — the same discipline this site has stressed for database connection strings (mongodb2-7) and CI/CD secrets (pipelines1-5) applies directly to encryption keys.
• Use a dedicated key management service (a cloud KMS, HashiCorp Vault) that stores keys separately from both the application and the data, with its own access controls and audit trail.
• Rotate keys periodically — a leaked key that's rotated regularly has a bounded window of usefulness to an attacker, rather than being valid indefinitely.

Hands-On Exercises

Chapter 5 protected data sitting on disk. This chapter protects the other half of the data's lifecycle — while it's moving across the network between an application and its database. The underlying cryptography is identical to the HTTPS/TLS course (https1) already on this site; this chapter is that same TLS applied to a database's own wire protocol instead of HTTP.

Why an Unencrypted DB Connection Is a Real Risk

Chapter 4's private-network binding controls who can reach the database's port — it says nothing about whether the traffic crossing that network, once a legitimate connection is allowed, can be observed by something in between. Even inside a "private" network, traffic still crosses physical switches, routers, and — in a cloud environment — a shared hypervisor layer other tenants' workloads also run on. An unencrypted connection means the login credentials and every query and response, including sensitive data, travel across that path in plain, readable text.

TLS for Database Connections

The same TLS mechanics the HTTPS course covered in depth — the handshake (https1-6), certificates (https1-4), symmetric and asymmetric cryptography (https1-2/https1-3) — apply directly here, just carrying a database's own wire protocol instead of HTTP. Every major database engine supports requiring TLS for connections.

Certificate Verification: The Part That's Easy to Get Wrong

Enabling TLS on its own only guarantees the connection is encrypted — it does not guarantee the server on the other end is actually the real database server, unless the client also verifies the server's certificate. This is the exact same certificate-chain-of-trust concept the HTTPS course covered (https1-5), and getting it wrong in a database connection string is a genuinely common, well-documented pitfall.

Why This Matters Even on a "Private" Network

Chapter 4's network isolation and this chapter's encryption in transit are two independent layers, not substitutes for each other — the same defense-in-depth principle Chapter 3 established for least privilege. Network isolation reduces who can attempt a connection at all; encryption in transit protects the data within a connection that's already permitted, against anything positioned to observe that traffic — a compromised intermediate host, a misbehaving piece of shared cloud infrastructure, or an insider (Chapter 1) already present on the same network segment. Neither layer alone covers what the other one does.

Hands-On Exercises

Chapter 2 argued that individual accounts are worthless for accountability without something actually recording what each one does. This chapter is that missing piece — and the database-specific instance of a category the OWASP course already named: A09 Security Logging & Monitoring Failures (owasp1-9).

Why Auditing Depends on Chapter 2's Foundation

Auditing only works if it's built on individual, non-shared accounts (Chapter 2) — a log that says "admin ran this query" for five different developers tells you nothing useful at all. This chapter assumes that foundation is already in place and builds the actual logging and detection on top of it.

Query Logging

Most database engines can log every query, along with which account ran it and when — MySQL's general query log, PostgreSQL's log_statement, MongoDB's auditLog. Logging everything is expensive in both storage and performance overhead, which is why most real deployments scope logging deliberately rather than capturing every single statement.

Audit Trails for Sensitive Table Access

Rather than logging every query against every table, a more sustainable approach specifically tracks access to sensitive tables — a customers or payments table, for instance — using dedicated audit tooling (MySQL Enterprise Audit, PostgreSQL's pgAudit extension) or triggers that record who read or modified which rows.

Detecting Anomalous Access Patterns

Logs that just accumulate and are never reviewed provide little real protection — the value is in noticing when something looks wrong, ideally close to when it happens. A few concrete anomaly signals worth watching for:

• A read-only account (Chapter 3's reporting_job) suddenly issuing an UPDATE or DELETE — either a bug, or a sign that account's credentials are being misused.
• A sudden spike in query volume from one account, especially outside its normal usage hours.
• An account reading far more rows than its typical pattern — a common signature of data exfiltration in progress.

Hands-On Exercises

Chapter 1 named backup theft as its own threat category, distinct from attacking the live database directly. This chapter is the deep dive: encryption, storage, retention, and the uncomfortable truth that a backup which has never been restored isn't actually a verified backup at all.

Backups Are a Complete Copy of Your Data

Every protection this course has covered — least privilege (Ch.3), network isolation (Ch.4), encryption (Ch.5–6), auditing (Ch.7) — has been about the live database. A backup is a complete, standalone copy of the exact same data, and by default, none of those protections automatically travel with it. Treating backup security as an afterthought means building a well-defended live system with an equally sensitive, far less defended copy sitting somewhere else.

Encrypting Backups

Chapter 5 noted that TDE encrypts the backups the database engine itself produces — but a huge share of real-world backups are made with plain dump tools (mysqldump, pg_dump) rather than the engine's own encrypted backup mechanism, and those tools produce plain-text SQL by default, regardless of whether TDE is enabled on the live database at all.

The dump tool's own encryption status has nothing to do with the live database's TDE setting — they're entirely separate mechanisms, and it's easy to assume "we have TDE, so we're covered" while a completely unencrypted mysqldump output sits on a backup server.

Secure Backup Storage & Access

The exact same principles Chapters 3 and 4 applied to the live database apply directly to wherever backups are stored: least privilege (only the specific accounts that genuinely need backup access should have it — not "the whole ops team by default"), and network security (a backup sitting in a publicly readable cloud storage bucket is exactly as exposed as a database port open to the internet, just discovered differently).

Retention Policy Trade-offs

How long to keep backups is a genuine trade-off, not a "more is always safer" decision:

• Keeping backups too long means more copies of sensitive data sitting around, each one a separate attack surface — and can conflict with privacy/compliance obligations if data that should have been deleted per policy still exists in an old backup.
• Keeping backups too short risks being unable to recover from a problem discovered late — a slow data-corruption bug, or a breach not noticed for weeks, can mean the only "clean" backup has already aged out and been deleted.

A deliberate retention policy — balancing both risks rather than defaulting to either extreme — belongs on Chapter 10's hardening checklist.

"Your Backups Are Also an Attack Target"

Testing Restore Procedures

A backup that has never actually been restored is an assumption, not a verified backup — silent corruption, an incomplete dump, a misconfigured schedule, or a permissions issue can all mean months of "successful" backup jobs produced files that don't actually restore to a working database.

Hands-On Exercises

Accounts, network, encryption, and auditing are all now covered. This chapter closes the remaining gap: is the database software itself, as installed, configured defensively — or just left running on whatever the installer defaulted to?

Disabling Unnecessary Features & Extensions

Every enabled feature is additional attack surface, whether or not it's ever actually used. MySQL's LOAD DATA LOCAL INFILE — a known vector that, combined with certain application patterns, can let a malicious server read arbitrary files off a connecting client — is a textbook example: a genuinely useful feature for specific bulk-import use cases, and a real risk left enabled everywhere else. The same logic applies to unused stored-procedure languages, unused plugins, and unused extensions generally: if it isn't actively used, disable it.

Removing Default & Sample Accounts and Databases

Many database engines have historically shipped with sample databases and demonstration accounts out of the box — MySQL's old sample test database is a well-known example. These are publicly documented; an attacker doesn't need to guess they might exist, they already know exactly what to look for and where. Removing them after installation is a five-minute task with essentially no downside.

Secure Default Configuration Review

A database engine's out-of-the-box configuration is typically optimized for "gets running with minimal friction," not "secure by default" — the same theme owasp1-5 (Security Misconfiguration) covered generally. Reviewing the actual configuration file against a published hardening guide (the CIS Benchmarks publish one for most major database engines) rather than trusting factory defaults is the concrete version of that OWASP category applied specifically to the database.

Patching & CVE Management

owasp1-6 (Vulnerable & Outdated Components) already covered the general risk of running software with known, weaponized CVEs — the database engine itself is exactly this kind of component, not a special exception. A publicly known vulnerability with a documented exploit against an old, unpatched database version is very often a far easier path in than any custom attack — no creativity required, just checking the version number and looking up whether it's still vulnerable.

Hands-On Exercises

The finale turns nine chapters of principles into practice: how to actually verify a database is secure rather than assume it, the broken-practice patterns to recognize, and a single deployable checklist pulling everything together. (Test only systems you own or are authorized to assess.)

How to Test Your Database's Security

1. Verify account design — list every database account; confirm none are shared or generic (Ch.2), and that each one's grants match least-privilege design, not a "superuser for everything" default (Ch.3).
2. Verify network exposure — attempt to connect to the database port from outside its private network; it should fail. Confirm the bind address and firewall rules actually match what's documented (Ch.4).
3. Verify encryption — confirm at-rest encryption (TDE or full-disk) is genuinely enabled, and that ad-hoc dump tools are independently encrypted too (Ch.5). Confirm connections require TLS with full certificate verification, not just sslmode=require (Ch.6).
4. Verify auditing — confirm sensitive-table access is actually logged, and that logs are shipped somewhere a compromised database account can't reach or alter (Ch.7).
5. Verify backups — perform an actual test restore, not just check that the backup job reports success. Confirm backup storage has its own least-privilege and network isolation, separate from the live system (Ch.8).
6. Verify hardening — check for lingering default accounts or sample databases, unused features left enabled, and confirm the engine version has no unpatched known CVEs (Ch.9).

The Broken-Practice Catalogue

The Hardening Checklist

How the Course Fits Together

The arc: Chapter 1 drew the line between the application-layer threat model (SQLi, already covered) and this course's infrastructure threat model. Chapters 2–3 secured who can connect and what they can do. Chapter 4 secured the network path. Chapters 5–6 secured the data itself, at rest and in transit — reusing the exact cryptography the https1 course already covered in depth. Chapter 7 made sure activity is actually recorded and tamper-resistant, directly extending owasp1-9. Chapter 8 extended every earlier protection to backups specifically. Chapter 9 hardened the software itself, applying owasp1-5 and owasp1-6 to the database engine. This chapter closes the loop: verify all of it actually holds, not just that it was configured once.

Hands-On Exercises