Redis Security
Production hardening for Redis: authentication, ACL-based access control, and network exposure. Cover all three together — any one of them on its own leaves an exploitable gap.
When to apply
- Deploying or reviewing a Redis instance destined for production.
- Setting up application credentials beyond a shared password.
- Auditing a Redis deployment against a security checklist.
- Receiving "Redis exposed to the internet" findings from a scanner.
1. Always authenticate (and use TLS)
Never run a production Redis without a password. Pair authentication with TLS so credentials and data aren't sent in clear text.
If you can use ACL users (next section) instead of the single requirepass, do — requirepass is effectively the legacy "default user" shortcut.
See references/auth.md [blocked].
2. ACLs for least-privilege access
The default user with a shared password is fine for development. For production, give each application a dedicated ACL user with only the commands and key patterns it actually needs.
Useful command categories:
If app credentials leak, a tight ACL bounds the blast radius — the attacker can't FLUSHALL your DB just because they grabbed a cache reader's password.
See references/acls.md [blocked].
3. Restrict network access
The most common Redis breach is a public-internet Redis with no auth. Avoid that with three layers:
Anti-pattern: bind 0.0.0.0 + protected-mode no — exposes Redis to the whole network without protection.
Optional but recommended: rename or disable destructive commands so a compromised client can't trash the DB:
See references/network.md [blocked].

