Updated 10 hours ago
Redis is everywhere. If you've used a web application in the last decade, some part of your experience—your session, a cached query, a real-time notification—probably touched Redis. It's fast because it keeps everything in memory. It's simple because it was designed for developers who needed things to just work.
It listens on port 6379. And for years, that port was one of the easiest ways into a server.
The Trust Assumption
Redis was designed for a world that no longer exists—one where "inside the firewall" meant "trusted."
The original philosophy was reasonable: Redis would run on internal servers, accessed only by application code you controlled. Why add the overhead of authentication when every connection comes from your own infrastructure? Why restrict commands when the only users are your own services?
So Redis shipped with no password required. It accepted connections from any IP address. It gave every client full administrative access.
This worked fine until people started deploying Redis on cloud servers with public IPs, or misconfiguring firewalls, or assuming their VPC was more isolated than it was. Suddenly, databases designed for trusted environments were exposed to the entire Internet.
What Happens to an Exposed Redis
The attackers' playbook is almost elegant in its simplicity.
Step one: Scan the Internet for port 6379. Step two: Try to connect. Step three: If it works, you own the database.
The most common attack: Connect to an unprotected Redis instance, run FLUSHALL to delete everything, and leave a single key behind—a ransom note demanding Bitcoin for "recovery" of the data. The cruelty is that there's nothing to recover. Redis keeps its data in memory. Once it's flushed, it's gone. The ransom is pure profit because the attackers never had your data to begin with.
More sophisticated attackers use Redis to gain persistent access to the server itself. Redis can write files to disk—it's how persistence works. Attackers exploit this by writing malicious SSH keys or cron jobs, turning a database misconfiguration into full server compromise. Cryptocurrency miners follow. Your CPU bills spike. You find out weeks later.
Security researchers consistently find thousands of exposed Redis instances. They contain session tokens, API keys, cached personal data, payment information. Seconds to connect, seconds to extract.
What Redis Actually Does
Redis (Remote Dictionary Server) is an in-memory key-value store. You give it a key, it gives you back a value—in microseconds instead of milliseconds.
That speed comes from keeping everything in RAM. Traditional databases write to disk first, then respond. Redis responds from memory, optionally persisting to disk in the background. This makes it ideal for data that needs to be fast and can tolerate some loss.
Caching: Store database query results so you don't hit the database again. Store API responses. Store anything expensive to compute.
Sessions: Keep user login state in a central place that all your web servers can access. User logs in once, stays logged in regardless of which server handles their next request.
Real-time features: Pub/sub messaging for chat, notifications, live updates. Sorted sets for leaderboards and rankings. Counters for rate limiting and analytics.
Redis supports strings, hashes, lists, sets, sorted sets, streams, and more. It's not just a cache—it's a data structure server. But that versatility comes with powerful commands that become dangerous when the wrong people can run them.
Why Public Exposure Is Never Acceptable
Exposing Redis to the Internet isn't a calculated risk. It's a misconfiguration waiting to become an incident.
Even with a password, a public Redis instance faces brute force attacks. Redis has no rate limiting, no account lockout, no protection against password guessing. A strong password helps, but it's your only defense.
The INFO command tells attackers your Redis version, memory usage, and configuration—everything they need to know which exploits might work. The KEYS * command can lock up your server for seconds while it iterates through millions of keys, a trivial denial-of-service.
And when Redis vulnerabilities are discovered (they exist in all software), Internet-facing instances can be exploited before you've even read the security advisory.
The answer is simple: Redis goes behind your firewall. It binds to localhost or a private IP. It only accepts connections from application servers you control. If you need remote access, you use a VPN or SSH tunnel. There's no scenario where Redis should accept connections from arbitrary Internet addresses.
Authentication That Actually Works
Modern Redis (6.0+) has real access control.
The old way was a single password for everyone. Set requirepass in your config, and clients send AUTH <password> before running commands. Better than nothing, but crude—one password, full access once authenticated.
Access Control Lists changed this. You can create multiple users with different passwords and different permissions:
The read-only user can only run GET and TTL on keys starting with cache:. The app server has full access. The monitor can only check if Redis is alive. If any credential leaks, the damage is contained.
This is the principle of least privilege applied to a database. Your monitoring system doesn't need FLUSHALL. Your cache layer doesn't need CONFIG. Don't give them those powers.
Encryption in Transit
Redis 6.0 also added native TLS support.
Before this, Redis traffic was plaintext. Every command, every response, every piece of cached data—readable by anyone who could sniff the network. Protecting Redis traffic meant running it through a TLS proxy like stunnel.
Now you configure Redis with certificate files and clients connect over TLS directly. Your session tokens don't traverse the network in cleartext. Man-in-the-middle attacks become impractical. Client certificates can add another authentication factor.
There's a small performance cost. TLS handshakes take time. Encryption uses CPU. But for data crossing network boundaries—especially between availability zones or data centers—the protection is worth it.
Defense in Depth
Securing Redis isn't one thing. It's layers.
Network: Bind to 127.0.0.1 or a private interface, never 0.0.0.0. Firewall rules allowing only known application servers. Ideally, Redis lives in its own network segment.
Authentication: Always require it, even in development. Use ACLs to limit what each user can do. Store credentials in a secrets manager, not config files.
Dangerous commands: Rename or disable FLUSHALL, FLUSHDB, CONFIG, DEBUG, SHUTDOWN. If your application doesn't need them, they shouldn't exist.
Encryption: Enable TLS for any traffic that leaves the local machine.
Least privilege: Run Redis as an unprivileged user. If exploited, attackers inherit only those limited permissions.
Updates: Subscribe to Redis security announcements. Patch promptly. Have a process.
Monitoring: The slowlog tracks expensive operations. Unusual patterns—unexpected commands, connections from strange IPs—might indicate reconnaissance.
Persistence files: RDB snapshots and AOF logs contain your entire dataset in plaintext. Secure them like you'd secure the database itself.
What Redis Teaches Us
Redis on port 6379 is a lesson in assumptions.
The designers assumed trusted networks. That assumption was valid for years, then it wasn't. The transition to cloud infrastructure, to public IPs by default, to complex VPC configurations that developers don't fully understand—all of it made "behind the firewall" a dangerous assumption.
Redis adapted. Version 3.2 added protected mode that refuses external connections unless you explicitly configure authentication. Version 6.0 added ACLs and TLS. The defaults got safer.
But the installed base doesn't update itself. Old tutorials still show Redis without passwords. Developers copy configurations they don't understand. And the Internet keeps scanning port 6379, finding databases that assume the firewall will save them.
The fix isn't complicated: Don't expose Redis to the Internet. Require authentication. Restrict commands. Encrypt traffic. Run as unprivileged. Keep updated.
Redis is an exceptional tool—fast, versatile, battle-tested. The security story is good now, for those who configure it properly. The risk comes from treating an internal service as if it can survive public exposure.
It can't. Nothing designed for trust survives the Internet's ambient hostility. Respect what Redis is, protect it accordingly, and it will serve you well.
Frequently Asked Questions About Redis Security
Was this page helpful?