Database security

Database Security Audit Fixes

These are the fixes for a database security audit: which accounts exist and what they can do, which interfaces the engine listens on, whether traffic is encrypted, and where the credentials are stored.

37
checks documented
6
audits in this category
29
need root or sudo
19
rated high severity

What these fixes cover

  • Root and anonymous accounts, blank passwords and the authentication method in use
  • Listening interfaces, exposed ports and web-based admin panels
  • Over-broad grants: wildcard hosts, FILE privilege, superusers and admin accounts
  • TLS enforcement and certificates, plus where config and backup credentials live on disk

What they do not

  • Schema design, query performance or index health. These checks read security configuration only.
  • Databases running inside containers. The probes look for host engines; audit those with the Docker checks or exec into the container.
  • Managed database services. There is no config file to read on RDS, Cloud SQL or Atlas.

How much of this is serious?

Severity of all 37 Database checks, as the scripts rate them.

  • 19High severity51%
  • 15Medium severity41%
  • 3Low severity8%
By audit

6 audits, 37 checks

Grouped by the 6 audits they belong to. Authentication and network isolation come first, because together they decide whether the database is reachable by anyone at all.

Fix these first

The highest-severity findings in Database

Ordered by the impact class the audit script assigns, then by the order the audit runs them.

Keep going

The other three platforms

Most hosts run more than one of these. The split shows how much of each platform the audit rates as high severity.

FAQ

Database fix questions

Two reasons dominate. Either no database engine was detected on the host, in which case there is genuinely nothing to audit, or the engine is present but the script could not authenticate to it. The checks require a working root socket login (mysql -N -e "SELECT 1" as root, or psql as the postgres user); without that, they report SKIP rather than guess. Containerised databases are not detected by these probes.
The checks themselves are read-only and safe on production. The fixes are not uniformly safe: changing bind-address, require_secure_transport or a pg_hba.conf auth method will drop existing connections or lock out clients that are not ready for it. Each page states what the change breaks. Test the new setting against a staging client before reloading production.
Yes. MariaDB is detected and audited by the MySQL checks throughout, and the pages call out the places where MariaDB behaves differently, most notably that it still exposes have_ssl where MySQL 8.4 removed it.
The network isolation findings matter less, though a private network is not a trust boundary once one host on it is compromised. The authentication, least-privilege and credential-storage findings matter just as much: they are what limits the damage after an application-level breach, which is how most database compromises actually begin.
Audit your fleet

Run all 37 Database checks, in one click

CtrlOps runs these audits over your existing SSH connection - no agents, no scripts to manage. $7/user/month after a 1 month free trial - no credit card required.

✓ Start instantly·✓ No credit card·✓ No sneaky autorenewals