Database-Specific Hardening

Database Security

Chapter 9 · Database-Specific Hardening

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.

-- checking and disabling a feature that isn't actually needed
SHOW VARIABLES LIKE 'local_infile';
SET GLOBAL local_infile = 0;

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.

DROP DATABASE IF EXISTS test;
DROP USER IF EXISTS ''@'localhost'; -- the old MySQL "anonymous" account

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.

	Unpatched, Known-Vulnerable Version	Current, Patched Version
Attacker effort required	minimal — a public exploit already exists	none of the known paths work
Discoverability	version banners/fingerprinting reveal it instantly	same fingerprinting reveals nothing exploitable

A known CVE is a published roadmap, not a secret

Once a database vendor publishes a CVE and a patch, the vulnerability details are public — anyone can look up exactly what's broken in unpatched versions and how to exploit it. Running an old version isn't a matter of "obscure enough that no one will bother" — it's leaving a documented, searchable weakness live and waiting, indefinitely, until it's patched.

This chapter is two OWASP categories, applied to the database engine

owasp1-5's Security Misconfiguration and owasp1-6's Vulnerable & Outdated Components both already covered these exact failure modes generally. This chapter isn't a new idea — it's confirming those two categories get applied to the database software itself, not just to application dependencies and web-server configuration.

Hands-On Exercises

Exercise 1

Explain why a feature like MySQL's LOAD DATA LOCAL INFILE should be disabled if it isn't actively used, even though it isn't inherently a bug. What general principle does this illustrate?

📄 View solution

Exercise 2

Explain why a default sample database or demo account is more dangerous than a custom, undocumented misconfiguration would be. What does "publicly documented" change about the risk?

📄 View solution

Exercise 3

Explain how this chapter's patching/CVE material relates to owasp1-6. Is a database engine a fundamentally different kind of risk than an outdated application dependency, or the same category applied to different software?

📄 View solution

Chapter 9 Quick Reference

Disable unused features/extensions — every enabled feature is attack surface, whether or not anyone uses it (e.g. MySQL's LOAD DATA LOCAL INFILE)
Remove default/sample accounts and databases — these are publicly documented, well-known targets, not obscure risks
Vendor defaults optimize for ease of setup, not security — review configuration against a published hardening guide (e.g. CIS Benchmarks)
The database engine is a component like any other — owasp1-6's outdated-components risk applies to it directly, not just application dependencies
A known, unpatched CVE is a public roadmap for an attacker, not an obscure risk
This chapter = owasp1-5 + owasp1-6, applied specifically to the database engine itself
Next chapter: Testing, Pitfalls & Hardening Checklist — the closing chapter, following this curriculum's established format, with a deployable checklist