{
  "schema_version": 2,
  "id": "operate/oss_and_stack/management/security",
  "title": "Redis security",
  "url": "https://redis.io/docs/latest/operate/oss_and_stack/management/security/",
  "summary": "Security model and features in Redis",
  "aliases": [
    "/management/security/",
    "/manual/security/"
  ],
  "tags": [
    "docs",
    "operate",
    "stack",
    "oss"
  ],
  "last_updated": "2026-09-30T13:16:11-07:00",
  "children": [
    {
      "id": "operate/oss_and_stack/management/security/acl",
      "summary": "Redis Access Control List",
      "title": "ACL",
      "url": "https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/"
    },
    {
      "id": "operate/oss_and_stack/management/security/encryption",
      "summary": "Redis TLS support",
      "title": "TLS",
      "url": "https://redis.io/docs/latest/operate/oss_and_stack/management/security/encryption/"
    }
  ],
  "page_type": "content",
  "content_hash": "0c72c85d71fb6f623b1782b30dc8c0e5cbbcb033a41bf9ea261cfab157350e5e",
  "sections": [
    {
      "id": "overview",
      "title": "Overview",
      "role": "overview",
      "text": "This document provides an introduction to the topic of security from the point of\nview of Redis. It covers the access control provided by Redis, code security concerns,\nattacks that can be triggered from the outside by selecting malicious inputs, and\nother similar topics. \nYou can learn more about access control, data protection and encryption, secure Redis architectures, and secure deployment techniques by taking the [Redis University security course](https://university.redis.com/courses/ru330/).\n\nFor security-related contacts, open an issue on GitHub, or when you feel it\nis really important to preserve the security of the communication, use this\n[downloadable GPG key](gpgkey.txt)."
    },
    {
      "id": "security-model",
      "title": "Security model",
      "role": "security",
      "text": "Redis is designed to be accessed by trusted clients inside trusted environments.\nThis means that usually it is not a good idea to expose the Redis instance\ndirectly to the internet or, in general, to an environment where untrusted\nclients can directly access the Redis TCP port or UNIX socket.\n\nFor instance, in the common context of a web application implemented using Redis\nas a database, cache, or messaging system, the clients inside the front-end\n(web side) of the application will query Redis to generate pages or\nto perform operations requested or triggered by the web application user.\n\nIn this case, the web application mediates access between Redis and\nuntrusted clients (the user browsers accessing the web application).\n\nIn general, untrusted access to Redis should\nalways be mediated by a layer implementing ACLs, validating user input,\nand deciding what operations to perform against the Redis instance."
    },
    {
      "id": "network-security",
      "title": "Network security",
      "role": "content",
      "text": "Access to the Redis port should be denied to everybody but trusted clients\nin the network, so the servers running Redis should be directly accessible\nonly by the computers implementing the application using Redis.\n\nIn the common case of a single computer directly exposed to the internet, such\nas a virtualized Linux instance (Linode, EC2, ...), the Redis port should be\nfirewalled to prevent access from the outside. Clients will still be able to\naccess Redis using the loopback interface.\n\nNote that it is possible to bind Redis to a single interface by adding a line\nlike the following to the **redis.conf** file:\n\n    bind 127.0.0.1\n\nFailing to protect the Redis port from the outside can have a big security\nimpact because of the nature of Redis. For instance, a single [`FLUSHALL`](https://redis.io/docs/latest/commands/flushall) command can be used by an external attacker to delete the whole data set."
    },
    {
      "id": "protected-mode",
      "title": "Protected mode",
      "role": "content",
      "text": "Unfortunately, many users fail to protect Redis instances from being accessed\nfrom external networks. Many instances are simply left exposed on the\ninternet with public IPs. Since version 3.2.0, Redis enters a special mode called **protected mode** when it is\nexecuted with the default configuration (binding all the interfaces) and\nwithout any password in order to access it. In this mode, Redis only replies to queries from the\nloopback interfaces, and replies to clients connecting from other\naddresses with an error that explains the problem and how to configure\nRedis properly.\n\nWe expect protected mode to seriously decrease the security issues caused\nby unprotected Redis instances executed without proper administration. However,\nthe system administrator can still ignore the error given by Redis and\ndisable protected mode or manually bind all the interfaces."
    },
    {
      "id": "authentication",
      "title": "Authentication",
      "role": "security",
      "text": "Redis provides two ways to authenticate clients.\nThe recommended authentication method, introduced in Redis 6, is via Access Control Lists, allowing named users to be created and assigned fine-grained permissions.\nRead more about Access Control Lists [here](https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl).\n\nThe legacy authentication method is enabled by editing the **redis.conf** file, and providing a database password using the `requirepass` setting.\nThis password is then used by all clients.\n\nWhen the `requirepass` setting is enabled, Redis will refuse any query by\nunauthenticated clients. A client can authenticate itself by sending the\n**AUTH** command followed by the password.\n\nThe password is set by the system administrator in clear text inside the\nredis.conf file. It should be long enough to prevent brute force attacks\nfor two reasons:\n\n* Redis is very fast at serving queries. Many passwords per second can be tested by an external client.\n* The Redis password is stored in the **redis.conf** file and inside the client configuration. Since the system administrator does not need to remember it, the password can be very long.\n\nThe goal of the authentication layer is to optionally provide a layer of\nredundancy. If firewalling or any other system implemented to protect Redis\nfrom external attackers fails, an external client will still not be able to\naccess the Redis instance without knowledge of the authentication password.\n\nSince the [`AUTH`](https://redis.io/docs/latest/commands/auth) command, like every other Redis command, is sent unencrypted, it\ndoes not protect against an attacker who has enough access to the network to\nperform eavesdropping."
    },
    {
      "id": "tls-support",
      "title": "TLS support",
      "role": "content",
      "text": "Redis has optional support for TLS on all communication channels, including\nclient connections, replication links, and the Redis Cluster bus protocol."
    },
    {
      "id": "disallowing-specific-commands",
      "title": "Disallowing specific commands",
      "role": "content",
      "text": "> [!WARNING]\n> The method is deprecated and may be removed in future versions.\n> Instead, use [ACL rules](https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl) to disallow specific commands.\n\nIt is possible to disallow commands in Redis or to rename them as an unguessable\nname, so that normal clients are limited to a specified set of commands.\n\nFor instance, a virtualized server provider may offer a managed Redis instance\nservice. In this context, normal users should probably not be able to\ncall the Redis **CONFIG** command to alter the configuration of the instance,\nbut the systems that provide and remove instances should be able to do so.\n\nIn this case, it is possible to either rename or completely shadow commands from\nthe command table. This feature is available as a statement that can be used\ninside the redis.conf configuration file. For example:\n\n    rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52\n\nIn the above example, the **CONFIG** command was renamed into an unguessable name.  It is also possible to completely disallow it (or any other command) by renaming it to the empty string, like in the following example:\n\n    rename-command CONFIG \"\""
    },
    {
      "id": "attacks-triggered-by-malicious-inputs-from-external-clients",
      "title": "Attacks triggered by malicious inputs from external clients",
      "role": "content",
      "text": "There is a class of attacks that an attacker can trigger from the outside even\nwithout external access to the instance. For example, an attacker might insert data into Redis that triggers pathological (worst case)\nalgorithm complexity on data structures implemented inside Redis internals.\n\nAn attacker could supply, via a web form, a set of strings that\nare known to hash to the same bucket in a hash table in order to turn the\nO(1) expected time (the average time) to the O(N) worst case. This can consume more\nCPU than expected and ultimately causes a Denial of Service.\n\nTo prevent this specific attack, Redis uses a per-execution, pseudo-random\nseed to the hash function.\n\nRedis implements the SORT command using the qsort algorithm. Currently,\nthe algorithm is not randomized, so it is possible to trigger a quadratic\nworst-case behavior by carefully selecting the right set of inputs."
    },
    {
      "id": "string-escaping-and-nosql-injection",
      "title": "String escaping and NoSQL injection",
      "role": "content",
      "text": "The Redis protocol has no concept of string escaping, so injection\nis impossible under normal circumstances using a normal client library.\nThe protocol uses prefixed-length strings and is completely binary safe.\n\nSince Lua scripts executed by the [`EVAL`](https://redis.io/docs/latest/commands/eval) and [`EVALSHA`](https://redis.io/docs/latest/commands/evalsha) commands follow the\nsame rules, those commands are also safe.\n\nWhile it would be a strange use case, the application should avoid composing the body of the Lua script from strings obtained from untrusted sources."
    },
    {
      "id": "code-security",
      "title": "Code security",
      "role": "content",
      "text": "In a classical Redis setup, clients are allowed full access to the command set,\nbut accessing the instance should never result in the ability to control the\nsystem where Redis is running.\n\nInternally, Redis uses all the well-known practices for writing secure code to\nprevent buffer overflows, format bugs, and other memory corruption issues.\nHowever, the ability to control the server configuration using the **CONFIG**\ncommand allows the client to change the working directory of the program and\nthe name of the dump file. This allows clients to write RDB Redis files\nto random paths. This is [a security issue](http://antirez.com/news/96) that may lead to the ability to compromise the system and/or run untrusted code as the same user as Redis is running.\n\nRedis does not require root privileges to run. It is recommended to\nrun it as an unprivileged *redis* user that is only used for this purpose."
    },
    {
      "id": "other-security-topics",
      "title": "Other security topics",
      "role": "content",
      "text": "The other pages in this section cover security topics in more detail."
    }
  ],
  "examples": []
}