No. The Redis documentation says Redis is designed for trusted clients inside trusted environments, and that exposing it directly to the internet is usually a bad idea. Bind it to the interfaces your apps use, firewall the port, add authentication as a second layer, and use TLS if traffic crosses a network you do not control.
Why the stakes are high
Redis gives any connected client a powerful command set. The security page points out that a single FLUSHALL from an outside attacker can delete the whole data set. It also describes a subtler risk: with CONFIG, a client can change the working directory and dump file name, which lets it write RDB files to arbitrary paths as the Redis user. That is why access to the port matters more than the data in the cache.
What protected mode does
Since version 3.2.0, Redis enters protected mode when it runs with the default configuration, which binds all interfaces, and has no password. In that mode it answers only loopback clients and gives other clients an error that explains how to configure it properly.
It is a safety net, not a design. The documentation says an administrator can still ignore the error, disable protected mode or bind all interfaces by hand. Many real exposures begin with someone who did exactly that to make a remote app connect.
The layers, in order
- Network path. Firewall or security group rules should allow only the machines that run your application. This is the main control.
- Bind address. A line like
bind 127.0.0.1inredis.conflimits Redis to one interface. For remote apps, bind to the private interface rather than all of them. - Authentication. The documentation describes it as a layer of redundancy if the firewall fails. Prefer ACL users over a shared
requirepass. - TLS.
AUTHand every other command is sent unencrypted, so authentication alone does not stop an eavesdropper. Redis supports TLS on client connections, replication links and the cluster bus. - Process hygiene. Run Redis as an unprivileged user, not root.
A note on rename-command
Older guides tell you to rename CONFIG to something unguessable. The current documentation marks that method deprecated and says to use ACL rules instead. If you still carry rename-command lines, plan their replacement.
Check yourself
From a machine outside your network, try to connect to your Redis port. From inside, run ACL LIST and look for user default on nopass ~* &* +@all. If that line is present and the port is reachable beyond your app servers, fix the network first and the accounts second.
Quick check
Does a firewall make authentication unnecessary?
No. The documentation frames authentication as redundancy for when the firewall or other protections fail. Use both.
Is a Redis password enough on a public network?
No. The AUTH command travels unencrypted, so someone who can watch the network can read it. Add TLS and keep the port closed.
Sources
Last reviewed: 19 October 2026.
