Open Redis and other unauthenticated databases: a quick exposure check

Why “no password by default” is a deliberate design choice, not an oversight

Redis’s own security documentation states its security model plainly: “Redis is designed to be accessed by trusted clients inside trusted environments,” adding that “usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port.” The intended architecture is that an application server sits between untrusted end users and Redis, handling access control and input validation itself — Redis is the fast internal data layer, not the public-facing boundary.

That design is reasonable in its intended context. The problem is what happens when the “trusted environment” assumption silently fails: a server gets deployed to a cloud provider with a public IP and a broader-than-expected default firewall rule, a developer binds Redis to all interfaces instead of localhost during testing and the change never gets reverted, or a container’s port gets published externally by a deployment script nobody audited closely. In each case, Redis itself hasn’t changed — the trust boundary around it has quietly disappeared.

What’s actually at stake

Redis’s documentation doesn’t understate the consequences: “failing to protect the Redis port from the outside can have a big security impact because of the nature of Redis. For instance, a single FLUSHALL command can be used by an external attacker to delete the whole data set.” Beyond data destruction, an attacker with unrestricted command access can read every key in the database — which, depending on what your application stores there, might include session tokens, cached user data, or application state never meant to leave your own infrastructure.

The safety net Redis added, and its limits

Since version 3.2.0, Redis has shipped with protected mode: when the server is running with its default configuration (bound to all interfaces) and no password configured, it automatically refuses queries from anything other than the loopback interface, replying to other connections with an explanatory error instead of serving the request. It’s a genuinely useful default-safe behavior. But it’s exactly that — a default — and it stops applying the moment an administrator sets any password (even a weak one) or explicitly re-enables broader binding, at which point the instance is back to relying entirely on whatever authentication and network controls were actually configured.

A quick self-check

1. Identify your public-facing IP with AdminKit’s what is my IP tool.
2. Test whether your database port responds from outside — port 6379 for Redis, or the relevant default port for another unauthenticated-by-default store — using AdminKit’s port check tool, only against infrastructure you own or are authorized to test.
3. If it responds, check whether a password is actually required before assuming the worst — a reachable port with strong authentication behind it is a very different risk than a reachable port with none.
4. Fix in layers, not just one. Set a strong password (or configure Access Control Lists for more granular permissions), bind to a private interface rather than all interfaces, and add a firewall rule scoped to only the clients that need access — redundancy here is the point, since any single control failing shouldn’t leave the database fully open.

Why a shared or dynamic public IP doesn’t make this safer

If your server’s outward-facing IP is shared via Carrier-Grade NAT or changes periodically, that’s not a form of security for an exposed database — see our CGNAT guide for why a shared address can actually complicate incident response (telling your traffic apart from a neighbor’s) rather than hiding you from automated scanners, which check every reachable address regardless of who else might be behind it.