Testing, Pitfalls & Hardening Checklist
Database Security
Chapter 10 · Testing, Pitfalls & Hardening Checklist
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
- 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).
- 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).
- 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). - 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).
- 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).
- 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
| Broken practice | Why it fails | Chapter |
|---|---|---|
| "We fixed our SQLi, so we're secure" | conflates the app-layer and infrastructure threat models | 1 |
| Shared "admin" login for the whole team | no accountability; can't revoke one person without breaking everyone | 2 |
App account granted ALL PRIVILEGES "to be safe" | turns every account into an equally catastrophic single point of failure | 3 |
DB port open to 0.0.0.0 "just for now" | found by automated scanners within minutes to hours | 4 |
sslmode=require, called "encrypted" | doesn't verify server identity — still MITM-able | 6 |
| Audit log stored inside the DB it audits | an attacker with DB access can simply delete the evidence | 7 |
mysqldump left unencrypted "because TDE is on" | dump tools don't inherit the live database's TDE | 8 |
| Backups on the same access/network as the live DB | ransomware takes both in a single incident | 8 |
| Sample databases/default accounts never removed | publicly documented, automatable targets | 9 |
| Running a years-old DB version, "never been a problem" | a known CVE is a public roadmap, not an obscure risk | 9 |
The Hardening Checklist
verify-full), not just an encrypted-but-unverified connection (Ch.6)SQLi course's whole point) running on a database with default credentials, an internet-facing port, and unencrypted backups is still one incident away from disaster. Equally, a flawlessly locked-down database serving an application riddled with SQL injection is just as exposed — the attacker never needed to touch anything this course covers at all. Chapter 1's two threat models both need real, ongoing attention; neither one is optional, and neither is ever "done" as a one-time setup task.
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
Write a database security test plan for a single production database: what you'd check for accounts, network exposure, encryption, auditing, backups, and hardening, and what a passing result looks like for each.
📄 View solutionAudit this setup against the broken-practice catalogue: a single shared "admin" account is used by the whole team, the database port is open to 0.0.0.0 "temporarily," nightly mysqldump backups are unencrypted because "TDE is on," and the database still has its default sample schema. List every flaw, its chapter, and the fix.
Explain why "our application passed its SQL injection review" and "our database is secure" are two different claims, using this course's material. What would a company need to verify in addition to the SQLi review to justify the second claim?
📄 View solutionChapter 10 Quick Reference
- Test, don't assume: verify accounts, network exposure, encryption, auditing, backups, and hardening — each independently
- Broken practices: shared logins · superuser app accounts · public DB ports · unverified TLS · in-DB audit logs · unencrypted dumps · backups sharing the live system's access · unremoved defaults · unpatched versions
- Checklist: individual accounts · least privilege · network isolation · encryption at rest + in transit · tamper-resistant auditing · encrypted/isolated/tested backups · hardened, patched software · both threat models taken seriously
- The one principle: application-layer security (SQLi, XSS, Auth) and infrastructure-layer security (this course) are independent, complementary layers — neither substitutes for the other
- Security here is never a one-time setup task — grants drift, versions age, backups go untested unless periodically re-verified
★ Database Security Complete — 10 / 10 chapters
From the infrastructure-vs-application threat model split, through authentication and least-privilege account design, network security, encryption at rest and in transit, auditing, backup security, and database-specific hardening, to a deployable testing and hardening checklist. Paired with SQL Injection, HTTPS/TLS, and the OWASP Top 10, this completes the site's database-focused security coverage — the infrastructure half that application-layer defenses alone were never going to cover.