Api Key Exposure in Strapi with Redis

Strapi stores sensitive configuration such as database credentials and third-party service tokens in environment variables. When developers enable Redis as the cache and session store, they often pass these values through Strapi’s configuration layer without additional protection. If a Redis instance is left exposed on a public network, lacks a strong ACL password, or is bound to an interface accessible from the internet, an unauthenticated attacker can connect to the Redis server and inspect the cached data.

Redis commands such as KEYS * and SCAN can enumerate keys, and GET can retrieve their values. If Strapi’s runtime configuration or cached sessions contain API keys stored as plaintext strings, the attacker can harvest secrets directly from Redis. This becomes particularly dangerous when developers inadvertently store JWT secrets, OAuth client secrets, or third-party API keys in the cache, assuming that Redis is an internal, trusted component.

The risk is compounded when the Redis server does not enforce TLS encryption. Without in-transit encryption, credentials can be intercepted during commands like GET or MGET. Default installations may also bind Redis to 0.0.0.0 with default ports, making it trivially reachable. In cloud environments, misconfigured security groups or open load balancers can expose Redis to the public internet, turning a trusted cache into a secret repository. Strapi’s configuration might reference environment variables that are resolved at runtime and cached, so if an attacker retrieves these values, they can pivot to other services that rely on the same keys.

For example, a Strapi application might use a third-party geocoding API with an embedded key stored in environment variables. If Strapi caches resolved locations or session data in Redis without redaction, the key can leak through standard cache operations. Because Redis does not differentiate between application data and configuration artifacts, any value written to the cache becomes a potential target.

To detect this issue with an unauthenticated scan, middleBrick tests the attack surface of any exposed Redis port, attempting to identify misconfigurations and unprotected endpoints. The scanner flags instances where Redis is reachable without authentication or encryption, highlighting the exposure of cached Strapi configuration and session data. This underscores the need to treat Redis as a potential attack surface rather than a benign cache.

Remediation focuses on network isolation, authentication, and encryption. Strapi should never rely on Redis being inaccessible; instead, enforce strict binding rules and credentials. Use environment variables to inject secrets at runtime, and avoid caching sensitive configuration values in Redis.

Bind Redis to localhost or a private network interface only. In the Redis configuration file (redis.conf), set:

bind 127.0.0.1 ::1
protected-mode yes

Require a strong password using the requirepass directive:

requirepass YourStrongPasswordHere

In Strapi’s cache configuration (config/databases.js or config/server.js), ensure the Redis connection includes the password and limits the command set if possible. For example:

module.exports = ({ env }) => ({
  cache: {
    connection: {
      host: env('REDIS_HOST', '127.0.0.1'),
      port: env.int('REDIS_PORT', 6379),
      password: env('REDIS_PASSWORD', null),
      tls: env.bool('REDIS_TLS', false),
    },
  },
});

Enable TLS to protect data in transit. With TLS enabled, the connection block would include:

tls: {
  rejectUnauthorized: false, // Set to true with proper CA in production
},

Use ACLs to restrict commands and keys. Create a dedicated Redis user that only allows necessary operations and keys via the user directive in redis.conf or through the ACL system at runtime. For example, to allow only GET and SET on specific key patterns:

user strapi_user on >password ~strapi:cache:* +get +set

Avoid storing API keys or secrets in cache. If Strapi must use Redis for session storage, ensure session data does not contain credentials. Rotate any exposed keys immediately and treat any Redis instance that was publicly accessible as compromised.

middleBrick can validate these configurations by scanning the Redis exposure surface. With the Pro plan’s continuous monitoring, you can schedule periodic checks to ensure bindings, authentication, and encryption remain properly configured, and integrate these scans into CI/CD pipelines using the GitHub Action to fail builds on risky settings.