Database hardening comes down to six questions: who can reach it, who can log in, what each login can do, whether traffic is encrypted and verified, what gets logged, and whether you can restore it. The settings differ by engine, but the checklist does not. Work through it per database and write down the gaps.
1. Who can reach it
Databases should sit on private networks reachable only from the apps that need them.
- Redis: the documentation says to deny the port to everyone but trusted clients, and
bindto specific interfaces. - MongoDB: binds to localhost by default, so check any change to
net.bindIp. - PostgreSQL:
pg_hba.confdecides who may connect from where, see how first match rules work. - MySQL: restrict accounts by host and network rules.
2. Who can log in
- No shared accounts. One user per application, one per person.
- No passwordless defaults. A fresh Redis default user needs no password and has all permissions.
- PostgreSQL: move off MD5 hashes, see the SCRAM migration.
- MongoDB: enable access control, see the lockdown checklist.
3. What each login can do
Apps need data access, not schema or user management.
- PostgreSQL: predefined roles and revoking the public schema create privilege.
- MySQL: roles for application accounts.
- MongoDB: read or readWrite on one database.
- Redis: ACL users with key patterns.
4. Encryption and verification
Encrypting is not enough if clients do not check the server. In PostgreSQL that means verify-full, in MySQL VERIFY_IDENTITY. Redis and MongoDB support TLS and both vendors recommend it. See the PostgreSQL and MySQL posts.
5. Logging
Log authentication attempts and privileged changes, and keep secrets out of logs. For PostgreSQL see log settings and pgAudit. MongoDB's checklist recommends central log collection.
6. Backups and patching
A backup you have not restored is a guess. See PostgreSQL point in time recovery, Redis RDB versus AOF and MongoDB backup methods. Track supported versions, see PostgreSQL version planning.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a change after the first scan surfaces as a new finding. Hardening drifts, so a checklist is something you rerun.
Where Safeguard fits
Safeguard's asset discovery helps you see what you run, and dependency scanning covers the database drivers and client libraries your code pulls in. The configuration items above still need your own review. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Which item should come first?
Network reachability. Authentication and roles matter, but an exposed port makes every other weakness easier to exploit.
Sources
- Redis documentation: Redis security
- MongoDB manual: Security Checklist for Self-Managed Deployments
- MySQL 8.4 Reference Manual: Encrypted Connections
Last reviewed: 19 October 2026.
