Redis Security

by redisa84871d065f3MITListed Oct 8, 2026Updated Oct 8, 2026

Redis security guidance covering authentication (requirepass and ACL users), TLS, ACL-based least-privilege access control, restricting network exposure via bind and protected-mode, firewall rules, and disabling dangerous commands. Use when deploying Redis to production, defining ACL users for an application, configuring TLS connections, locking down a Redis instance behind a firewall, or auditing a Redis deployment for security hardening.

Instructions onlySecurity
AI-generated overview

Guides hardening Redis deployments with authentication, ACL least-privilege access, TLS, and network restrictions.

What it does
This skill provides production hardening guidance for Redis, covering authentication with requirepass and ACL users, TLS configuration, ACL-based least-privilege access control, network exposure limits via bind and protected-mode, firewall rules, and disabling dangerous commands. It produces configuration snippets and command examples for redis.conf, ACL SETUSER, iptables, and client connection settings. It also points to three reference files on authentication, ACLs, and network exposure.
When to use it
Use it when deploying or reviewing a Redis instance for production, defining ACL users for an application, configuring TLS connections, locking down a Redis instance behind a firewall, or auditing a Redis deployment against security findings.
Requirements
No scripts; instructions only. Applying the guidance assumes a Redis deployment and, for the examples, a Redis client library such as redis-py, plus access to redis.conf, ACL commands, and firewall tooling.

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.

# redis.confrequirepass your-strong-passwordtls-port 6380tls-cert-file /path/to/redis.crttls-key-file  /path/to/redis.key
python
r = redis.Redis(    host="localhost",    port=6380,    password="your-strong-password",    ssl=True,    ssl_cert_reqs="required",)

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.

# Cache-only readerACL SETUSER app_readonly on >password ~cache:* +get +mget +scan
# Writer that can't run dangerous opsACL SETUSER app_writer   on >password ~*        +@all -@dangerous
# Admin (use sparingly, never for application traffic)ACL SETUSER admin        on >strong-password ~* +@all

Useful command categories:

CategoryWhat it covers
@readRead commands (GET, MGET, HGET, ...)
@writeWrite commands (SET, DEL, XADD, ...)
@dangerousFLUSHALL, DEBUG, KEYS, etc.
@adminAdministrative commands

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:

# redis.conf — bind to specific interfaces, keep protected-mode onbind 127.0.0.1 192.168.1.100protected-mode yes
bash
# Firewall — allow only application subnetsiptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPTiptables -A INPUT -p tcp --dport 6379 -j DROP

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:

rename-command FLUSHALL ""rename-command DEBUG ""rename-command CONFIG ""

See references/network.md [blocked].

References

Source and attribution

Source:redis/agent-skillsinplugins/redis-development/skills/redis-securityat commita84871d

License: MIT

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal