Database security

Database Security Audit Checklist: MySQL, PostgreSQL, MongoDB & Redis

MySQL and MariaDB, PostgreSQL, MongoDB and Redis.

6
audits
Database
37
individual checks
named
~78s
to run the category
read-only

Databases are where a server breach becomes a data breach. The gap between the two is usually one config mistake: a public bind address, an account with no password, or a wildcard grant left over from a migration.

  • Read-only, safe on production
  • No agent installed
  • ~78s for the category
  • 10 distros auto-detected

How much of this is serious?

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

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

What these audits cover

  • Passwordless accounts, anonymous users, remote root logins and available auth methods
  • Listening interfaces, exposed ports and web-based admin tools left reachable
  • Wildcard host grants, the FILE privilege and accounts holding more than they need
  • TLS enforcement for client connections and where credentials are stored on disk

What they do not cover

  • Query-level issues. SQL injection lives in your application code, not in the database configuration.
  • Backup integrity. Whether a dump restores cleanly is not something a configuration read can tell you.
  • Managed database services. On RDS, Cloud SQL or Atlas the provider owns most of this surface.
The catalog

The 6 Database audits

Each audit detects which engines are installed and skips the rest, so a Postgres-only host reports on Postgres and stays quiet about the others.

Authentication

Soon

Passwordless access, anonymous users, remote root and auth methods

8 checks~14s8 need root

Configuration & Hardening

Soon

Service users, installer defaults, patches, log placement and backups

7 checks~19s5 need root

Network Isolation

Soon

Engine inventory, bindings, exposed ports and web admin tools

7 checks~12s4 need root

Least-Privilege Permissions

Soon

Wildcard hosts, FILE privilege, admin accounts and allowed hosts

6 checks~12s6 need root

Transport Encryption

Soon

TLS enforcement and server certificates for client connections

5 checks~11s5 need root

Credential Storage

Soon

Config files in the web root, config permissions, exposed .git and client credential files

4 checks~10s1 need root
FAQ

Database security questions

A database security audit should check five things: how accounts authenticate and whether any are passwordless or anonymous, which network interfaces the engine listens on, whether account privileges are scoped or use wildcard grants, whether client connections are encrypted in transit, and where credentials are stored on disk and with what permissions.
MySQL and MariaDB, PostgreSQL, MongoDB and Redis. Each audit detects which engines are actually present on the host and reports only on those, so a server running one engine does not produce noise about the other three.
Redis ships with no authentication enabled by default, and older versions bound to all network interfaces out of the box. An unauthenticated Redis instance reachable from outside the host lets anyone read and write every key, and in several well-documented cases has been used to write an SSH key straight into a user's authorized_keys file.
No. The checks read configuration files, server variables, user and grant tables, and listening sockets. They do not query application tables, read row data, or export anything from the database.
Partly. Managed providers own the host configuration, patching and much of the network layer, so those checks do not apply. The account and privilege checks still matter, because wildcard grants and over-privileged application users are your responsibility on any platform.
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