Api Key Exposure in Phoenix with Redis

Storing API keys in Redis from a Phoenix application can expose credentials when configuration and access patterns inadvertently create a broad attack surface. Redis is often run as a networked in‑memory data store; if it is reachable from web endpoints or background jobs, and keys are placed in Redis without strict controls, an attacker who can interact with the Redis instance may retrieve them.

In a Phoenix stack, developers sometimes cache API keys—such as third‑party service tokens or OAuth client secrets—in Redis for quick lookup. This becomes risky when keys are stored using predictable keys (for example api_key:service_name) and when the Redis instance permits connections without authentication or from untrusted network zones. If an endpoint deserializes user input into a Redis key name (e.g., via string interpolation to fetch a key), this can enable unauthorized reading or deletion, effectively exposing the API key to anyone who can reach Redis.

Additionally, if logs or error messages in Phoenix include full Redis commands that contain the key values—such as when developers log {"command", ["GET", key], "value", value}—keys can be leaked into log aggregation systems. The broad attack surface of Redis (network exposure, weak ACLs, or missing TLS) compounds the exposure when API keys are stored or referenced in ways that make them enumerable or extractable via an unauthenticated or poorly isolated Redis instance.

The LLM/AI Security checks available in middleBrick specifically include system prompt leakage detection and active prompt injection testing, which are designed to identify whether API keys or sensitive instructions might be exposed through model outputs or manipulated prompts. While these checks do not directly test Redis, they complement the broader security posture by ensuring that any AI-facing endpoints do not leak credentials that may be stored or referenced in your services.

When scanning an API that uses Phoenix with Redis-backed key storage, middleBrick’s checks for Data Exposure and Unsafe Consumption can surface findings related to weak authentication, missing encryption in transit, and excessive agency patterns that could lead to inadvertent key disclosure. By correlating spec definitions and runtime behavior, the scanner highlights insecure configurations—such as missing password protection on Redis or permissive network bindings—that increase the likelihood of API key exposure.

To reduce the risk of API key exposure when using Redis in Phoenix, apply strict access controls, avoid storing keys in plaintext under predictable keys, and ensure that sensitive values are never logged or exposed via endpoints.

• Use Redis ACLs and authentication: Configure Redis with a strong password and define users with limited permissions. In your redis.conf, set requirepass and create a dedicated user with only the needed commands.

# Example redis.conf snippet
requirepass your_strong_password_here
user api-reader on >api-reader-password +get +hget

• Connect with password in Phoenix using Redix with authentication: Use the password when starting the connection pool so your application authenticates on each connection.

# config/runtime.exs
config :my_app, MyApp.Redis,
  url: "rediss://:your_strong_password_here@redis-host:6379/0"

# lib/my_app/redis.ex
defmodule MyApp.Redis do
  use Redix, otp_app: :my_app
end

• Avoid storing raw API keys under guessable keys; if you must cache them, use a namespaced key with a random suffix and set an appropriate TTL. Do not construct Redis keys directly from user input.

# Good practice: generate a secure random key reference
api_key = "third_party_secret"
cache_key = "api_key:v1:{System.unique_integer()}"

# Set with TTL (seconds)
Redix.command!(MyApp.Redis, ["SET", cache_key, api_key, "EX", "3600"])

# Retrieve and use
case Redix.command(MyApp.Redis, ["GET", cache_key]) do
  {:ok, key_value} -> key_value
  {:error, _} -> nil
end

• Never log Redis command arguments or values. Ensure your logger level and any custom instrumentation do not include sensitive payloads.

# Avoid this:
value = Redix.command!(redis, ["GET", "api_key:service"])
Logger.info("Fetched API key: #{inspect(value)}")

# Safer approach — handle without exposing the value
case Redix.command(redis, ["GET", "api_key:service"]) do
  {:ok, _} -> :ok
  {:error, _} -> :error
end

• Prefer environment variables for static credentials and use Redis only for non-sensitive references or ephemeral tokens with strict TTLs. For long-lived API keys, rely on your host’s secret manager and inject them at runtime rather than caching them in Redis.