Database hardening
Reduce database exposure through narrowly scoped application identities, protected administration, maintained configuration, and tested data recovery.
What it means
Database hardening reduces unnecessary exposure and authority in the systems storing application data. It covers network reachability, identity, permissions, secure transport, configuration, and maintenance. Injection defenses remain an application concern even when the database itself is configured carefully.
A practical example
An application connects through a dedicated identity with only the operations it needs. Database administration is restricted to approved management paths, backups receive appropriate protection, and the service does not expose its management interface publicly.
What to check
Review supported versions, network access, authentication, service permissions, and backup handling. Remove unused features and verify that diagnostic or maintenance paths do not bypass the intended access restrictions.
A common pitfall
A database reachable only from an internal network can still be abused through a compromised application or overprivileged service identity.
Think it through
Why separate application and administrator accounts?
Answer: The application should not inherit broad management authority when its ordinary work requires only specific data operations.
Begin with the operations the application needs
Imagine a fictional academy application reads courses and updates learner progress. Its database identity needs those operations, but it does not normally need to create administrators or alter every schema. Write the required operations before granting a role.
A separate migration workflow can use different, controlled authority when schema changes are needed. Combining routine application work and powerful maintenance in one permanent credential makes a compromised application more consequential.
Internal reachability is not the whole threat model
Suppose the database accepts connections only from the application network. That removes some direct paths, but an attacker controlling the application may still use its legitimate database identity. Review network restrictions and effective database permissions together.
The database also has backup, replication, administration, and diagnostic paths. Protecting the primary listener while leaving a backup export widely accessible can expose the same data through another route.
Maintenance should preserve a recoverable service
Track supported software, configuration changes, and credential replacement. A security update can affect compatibility or availability, so test the application's important operations and keep an appropriate recovery plan. Recovery needs access to the necessary keys and credentials as well as the data files.
For a lab exercise, define three identities: the application, a migration job, and a database administrator. List only the operations each requires and identify how each is authenticated. Then describe a compromised application and state which actions remain blocked by the separation.
Finish with a restore test using non-sensitive sample data. Explain how the team verifies both data integrity and application behavior after recovery. This demonstrates that hardening is an ongoing operational design, not a one-time checklist or an assumption that an internal address makes the stored information safe.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Database Security