Skip to main content
Web Application Vulnerabilities
CHAPTER 14

Secure Database Practices

Updated: May 15, 2026
20 min read

# CHAPTER 14

Secure Database Practices

1. Introduction

The web application is merely the storefront; the backend database is the bank vault. While defending the web application from SQL Injection (Chapter 4) is critical, it is not enough. What if a disgruntled employee accesses the database server directly? What if a hacker bypasses the web app entirely by exploiting a flaw in the database software itself? In this chapter, we will shift our focus to Database Hardening. We will explore the Principle of Least Privilege for database users, the absolute necessity of Encryption at Rest, and the critical importance of secure backups.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define the concept of Database Hardening.
  • Implement the Principle of Least Privilege for database service accounts.
  • Understand the difference between Hashing and Encryption at Rest.
  • Explain the risks of default database configurations.
  • Understand the importance of immutable and encrypted backups.

3. Beginner-Friendly Explanation

Imagine a large corporation's filing room.
  • The Application: The receptionist at the front desk. They take requests from visitors and go to the filing room to get documents.
  • Default Database (Insecure): The receptionist has a master key that can open every filing cabinet, fire every employee, and burn the building down. If a visitor tricks the receptionist (SQL Injection), the visitor has ultimate power.
  • Hardened Database (Secure): The receptionist is only given a key to the "Public Brochures" cabinet. Furthermore, the highly sensitive "Payroll" cabinet requires a separate decryption code. Even if the receptionist goes rogue, they physically cannot access or destroy the payroll data.

4. The Principle of Least Privilege (PoLP)

When a PHP application connects to a MySQL database, it uses a username and password. The Devastating Mistake: Connecting to the database using the root or sa (System Administrator) account. If an attacker finds a SQL injection flaw, they are executing commands as root. They can drop (delete) the entire database, create new admin users, or even execute commands on the underlying Linux server. The Defense: Create a dedicated service account for the web application.
  • The webapp_user should ONLY be granted SELECT, INSERT, UPDATE, and DELETE privileges.
  • It should only have access to specific tables, not the entire server.
  • It must never have DROP privileges.

5. Encryption at Rest (TDE)

If a hacker steals the physical hard drive from the data center, or copies the raw database .mdf file, they bypass the web application entirely. To prevent this, we must use Encryption at Rest, commonly known as Transparent Data Encryption (TDE).
  • TDE encrypts the database files on the hard drive using Symmetric Cryptography (AES-256).
  • The database engine decrypts the data into memory (RAM) seamlessly when the web application requests it.
  • If a thief steals the hard drive, they only get scrambled AES ciphertexts. Without the master decryption key (stored in a secure KMS), the data is useless.

6. Eradicating Default Configurations

Databases like MySQL, PostgreSQL, and MongoDB often install with insecure defaults to make it "easy" for developers to get started.
  • Default Ports: Attackers scan the internet for port 3306 (MySQL) or 27017 (MongoDB). Change default ports, and more importantly, block these ports from the public internet using a firewall. The database should *only* accept connections from the Web Server IP.
  • Default Passwords: Ensure accounts like sa or postgres have complex passwords or are entirely disabled.
  • Remove Sample Data: Delete default databases (like the test database in MySQL) as attackers often use them to test exploits.

7. Mini Project: Secure MySQL Database Configuration

Let's execute the SQL commands to create a restricted user for our web application.

Secure SQL Configuration Concept:

sql
1234567891011 
-- 1. Create a dedicated user for the web application (NOT root)
CREATE USER 'webapp_user'@'localhost' IDENTIFIED BY 'SuperComplexRandomPassword123!';

-- 2. Grant ONLY the absolute minimum permissions required to function
GRANT SELECT, INSERT, UPDATE, DELETE ON secure_app_database.* TO 'webapp_user'@'localhost';

-- 3. Ensure the user CANNOT drop tables or alter the schema
REVOKE DROP, ALTER ON secure_app_database.* FROM 'webapp_user'@'localhost';

-- 4. Apply the privileges
FLUSH PRIVILEGES;

8. Real-World Scenarios

In the late 2010s, thousands of MongoDB databases were wiped out in a massive ransomware campaign. The root cause? The developers had installed MongoDB using the default settings. At the time, the default configuration bound the database to the public internet (0.0.0.0) and had Authentication Disabled. Anyone on the internet could simply connect to the database IP without a password, download all the data, delete the database, and leave a ransom note demanding Bitcoin. It was a catastrophic failure of basic database hardening.

9. Best Practices

  • Immutable and Encrypted Backups: Ransomware gangs specifically target database backup files to ensure you cannot recover without paying. Backups must be:
  1. 1. Encrypted: So attackers cannot read the stolen backups.
  1. 2. Immutable: Stored on a system (like AWS S3 Object Lock) where they mathematically cannot be deleted or altered, even by an Administrator, for a specified period (e.g., 30 days).

10. Legal and Ethical Notes

Storing sensitive customer data (like credit cards or health records) in plaintext on a database violates nearly every major data privacy regulation globally. The implementation of robust database access controls and Encryption at Rest is a non-negotiable legal requirement for maintaining PCI-DSS and HIPAA compliance.

11. Exercises

  1. 1. Explain the danger of connecting a web application to a backend database using the root administrative account.
  1. 2. How does Transparent Data Encryption (TDE) protect against the physical theft of a server hard drive?

12. FAQs

Q: If my database uses TDE, do I still need to hash passwords? A: YES! TDE protects the *hard drive*. When the database is running, the data is decrypted in memory. If a hacker finds a SQL Injection flaw, they query the running database and get the data in plaintext. TDE protects against physical theft; Hashing (Chapter 3) protects against application-level breaches.

13. Interview Questions

  • Q: Describe the application of the Principle of Least Privilege when provisioning a database service account for a web application. Which specific SQL commands should be explicitly revoked?
  • Q: A developer leaves a MongoDB instance exposed to the internet without authentication. Detail the automated attack vectors threat actors utilize to discover and exploit this misconfiguration.

14. Summary

In Chapter 14, we secured the core data repository. We defined Database Hardening as the process of locking down insecure defaults and severing the database from the public internet. We enforced the Principle of Least Privilege, ensuring the web application operates with the bare minimum permissions necessary, limiting the blast radius of a potential compromise. Finally, we established Encryption at Rest (TDE) and immutable backups as the final lines of defense against data theft and ransomware.

15. Next Chapter Recommendation

We have built a highly secure fortress. But how do we prove it is secure? We must attack it ourselves. Proceed to Chapter 15: Vulnerability Scanning and Security Testing.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Logging, Monitoring, and Error Handling
Next Chapter Vulnerability Scanning and Security Testing

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5