Why Redis Security Requires Deliberate Configuration
Out of the box, older Redis versions had no authentication at all, and a Redis instance left bound to 0.0.0.0 on a public IP with no password has historically been one of the most common causes of ransomware and cryptomining compromises reported by cloud providers. Modern Redis (6+) ships protected-mode enabled by default, which refuses external connections when no bind address or password is configured, but protected-mode is a safety net, not a substitute for deliberately configuring authentication, encryption, and network restrictions.
Cricket analogy: Like a stadium that historically left every gate unlocked until a steward finally added a single turnstile, Redis's protected-mode is a late-added safety net, not a substitute for properly staffed, ticketed gates (real authentication).
Authentication with AUTH and ACLs
The legacy approach sets requirepass in redis.conf, after which every client must run AUTH <password> before issuing other commands. Since Redis 6, ACL SETUSER lets you define named users with fine-grained permissions: ACL SETUSER app-readonly on >mypassword ~cache:* +get +mget -@all creates a user who can only run GET/MGET on keys prefixed cache: and nothing else, which follows the principle of least privilege far better than one shared password granting full access.
Cricket analogy: Like giving a substitute fielder permission only to field and throw, not to bowl or bat, ACL SETUSER can grant a user narrow permissions (+get +mget) instead of full access to every command.
# Legacy single-password auth
CONFIG SET requirepass "S3cureP@ssw0rd"
AUTH S3cureP@ssw0rd
# Modern ACL: a read-only user scoped to the cache: namespace
ACL SETUSER app-readonly on >mypassword ~cache:* +get +mget -@all
ACL SETUSER app-writer on >anotherpassword ~cache:* +get +set +expire -@all
ACL LISTEncrypting Traffic with TLS
Redis added native TLS support in version 6, configured via tls-port, tls-cert-file, tls-key-file, and tls-ca-cert-file directives, letting you run Redis without the plaintext port entirely (port 0) so all traffic between clients, replicas, and Sentinel/Cluster nodes is encrypted. Before Redis 6, encryption required a sidecar like stunnel; now it's a first-class configuration option, though it does add CPU overhead for the TLS handshake and per-packet encryption that matters at very high throughput.
Cricket analogy: Like broadcasting a match through a scrambled satellite feed that only licensed networks can decode, TLS scrambles Redis traffic on tls-port so only clients with the right certificates can read it.
You can disable the plaintext port entirely with 'port 0' and rely solely on tls-port, forcing every client, replica, and Sentinel/Cluster peer to connect over TLS — a strong default for anything internet-adjacent.
Network Isolation and Command Hardening
Beyond authentication and TLS, restrict exposure at the network layer: set bind to specific private interfaces (never 0.0.0.0 in production), keep protected-mode yes, and put Redis behind a firewall or VPC security group so only application servers can reach port 6379. Rename or disable dangerous administrative commands with rename-command (or ACL's -@dangerous category) — commands like FLUSHALL, CONFIG, KEYS, and SHUTDOWN can destroy data or leak configuration if reachable by an untrusted client, and many real-world Redis breaches trace back to an instance simply left open on the public internet with no password.
Cricket analogy: Like a ground curator locking the pitch access gate so only the groundstaff (not spectators) can reach the wicket, binding Redis to a private interface keeps only trusted application servers able to reach port 6379.
Publicly exposed, unauthenticated Redis instances (bind 0.0.0.0, no requirepass/ACL) are routinely scanned and compromised within minutes by automated botnets that use CONFIG SET and cron/authorized_keys tricks to gain shell access — this is not a theoretical risk, it is one of the most common real-world Redis incidents.
- Never bind Redis to 0.0.0.0 on a machine with a public IP; keep protected-mode enabled as a safety net, not a primary control.
- Use ACL SETUSER (Redis 6+) for least-privilege, per-application credentials instead of one shared requirepass.
- Enable TLS (tls-port, tls-cert-file, tls-ca-cert-file) to encrypt client, replica, and cluster traffic.
- Firewall Redis at the network layer (VPC security group, iptables) so only application servers can reach port 6379.
- Rename or restrict dangerous commands (FLUSHALL, CONFIG, KEYS, SHUTDOWN) away from regular application users.
- Rotate credentials and audit ACL LIST / ACL WHOAMI periodically to catch stale or over-privileged users.
- Treat 'Redis exposed with no auth' as one of the most common and most damaging real-world misconfigurations.
Practice what you learned
1. What does Redis's protected-mode do by default?
2. Since which major version does Redis support fine-grained ACL users via ACL SETUSER?
3. What is the effect of setting 'port 0' alongside a configured tls-port?
4. Why is binding Redis to 0.0.0.0 on a public-facing server risky?
5. Which technique lets you restrict a specific ACL user to only GET and MGET on keys prefixed cache:?
Was this page helpful?
You May Also Like
Redis with Node.js or Python
How to connect to, query, and manage Redis connections from Node.js (node-redis/ioredis) and Python (redis-py) application code.
Redis Interview Questions
A study guide covering the Redis concepts most commonly probed in interviews: data structures, persistence, replication, and scaling tradeoffs.
Redis Quick Reference
A condensed cheat sheet of the most-used Redis commands across data types, key management, and server administration.