The Infrastructure Threat Model
Database Security
Chapter 1 · The Infrastructure Threat Model
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:
| SQL Injection (already covered) | Database Security (this course) | |
|---|---|---|
| Attacker's path in | through the application's own queries | directly against the database as infrastructure |
| Trust boundary crossed | user input → query string | network perimeter, account credentials, storage media |
| Typical attacker | external, via a web form or API | external (exposed port), or an insider with legitimate access |
| Primary defence | parameterized queries (sqli1-7) | least privilege, network isolation, encryption, auditing |
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.
mongodb2-7 chapter of this site's MongoDB course covers one concrete, well-known example: a wave of ransomware attacks that specifically targeted exposed, unauthenticated MongoDB instances. The lesson generalizes far beyond MongoDB — the infrastructure threat model this course covers is not a theoretical add-on to application security; it's where a large share of real incidents actually originate.
What This Course Covers
| Chapter | Topic |
|---|---|
| 2 | Authentication & Access Control |
| 3 | Least-Privilege Account Design |
| 4 | Network Security for Databases |
| 5 | Encryption at Rest |
| 6 | Encryption in Transit |
| 7 | Auditing & Logging |
| 8 | Backup Security |
| 9 | Database-Specific Hardening |
| 10 | Testing, Pitfalls & Hardening Checklist |
Hands-On Exercises
Explain, in your own words, why "we use parameterized queries everywhere" does not mean a database is secure. Name at least three concrete attack paths this chapter covered that a SQLi fix does nothing to prevent.
📄 View solutionA company reports "no SQL injection vulnerabilities were found in our application" after a security review. List two realistic ways their database could still be breached despite that finding, using this chapter's threat categories.
📄 View solutionExplain why a database's backup can be a bigger security risk than the live database itself, even though it holds exactly the same data. What does this imply about where security effort should be spent?
📄 View solutionChapter 1 Quick Reference
- SQLi threat model = attacks reaching the DB through the app; Database Security threat model = attacks against the DB as infrastructure itself
- Insider threats — legitimate credential holders acting maliciously or carelessly; parameterized queries don't defend against this at all
- Misconfigured access — default credentials, shared accounts, over-broad grants (Chapters 2–3)
- Physical/network exposure — an internet-reachable DB port, an unencrypted connection, a lost device with local data (Chapters 4, 6)
- Backup theft — backups are often protected far less carefully than the live database holding the same data (Chapter 8)
- Many real breaches involve no query exploit at all — just an exposed, unauthenticated database or an unprotected backup
- Next chapter: Authentication & Access Control — database accounts vs. application-level auth, role-based access control in the DB itself