Cache Poisoning in Phoenix with Dynamodb

Cache poisoning in a Phoenix application that uses DynamoDB as a backend data source occurs when an attacker manipulates cached responses so that malicious or incorrect data is served to users. Because Phoenix applications often cache query results to reduce DynamoDB read costs and improve latency, unsafe caching logic can cause tainted data to persist across requests.

Consider a typical DynamoDB query in Phoenix via the aws-sdk-dynamodb client. If the application uses a naive cache key that includes user-controlled input—such as a query parameter from the URL—without normalizing or validating that input, an attacker can supply crafted parameters that change the cache key in predictable ways. For example, an endpoint like /products?id=123 might cache responses using the raw id value. An attacker could then request /products?id=123&x-cache-key=evil (via parameter pollution or a similar technique) to poison the cache under a different key or force the same key to return altered data.

DynamoDB itself does not introduce cache poisoning, but its behavior can amplify risks when combined with unsafe caching. If your cache stores partial or unvalidated responses from DynamoDB—such as items with inconsistent schemas or missing fields—subsequent requests may consume that cached data and propagate the invalid state. This is especially dangerous when cache entries are reused across users or tenants, potentially exposing one user’s data to another or enabling privilege escalation if cached administrative responses are mistakenly served to regular users.

Another vector involves Time-to-Live (TTL) misconfiguration. If cached DynamoDB responses have long or inconsistent TTLs, poisoned entries can remain in the cache far longer than intended. In a distributed Phoenix setup using a shared cache like Redis or Memcached, poisoned cache entries can spread quickly across nodes, making remediation more difficult. Because Phoenix often relies on in-memory or external caches to accelerate repeated DynamoDB queries, any lack of input validation or cache-key canonicalization directly increases the likelihood of cache poisoning.

Real-world patterns mirror this risk: an attacker may probe endpoints that reflect DynamoDB query results, observe differences in timing or response structure, and then craft inputs that alter cached outputs. Because middleBrick flags such input validation and data exposure checks, it can surface these weaknesses during an unauthenticated scan, highlighting where cache keys depend on untrusted data.

Remediation focuses on strict input validation, canonical cache keys, and safe deserialization of DynamoDB responses. Ensure that user-controlled data never directly influences cache keys or cache lookup logic. Instead, derive cache keys from normalized, server-side identifiers and apply strict allow-lists for expected values.

First, validate and sanitize all inputs before using them in DynamoDB queries or cache logic. For example, if your endpoint expects a numeric product ID, enforce a positive integer check and avoid passing raw parameters into cache keys:

def get_product(conn, %{"id" => id_param}) do
  with {id, _} <- Integer.parse(id_param),
       id when id > 0 <- id do
    cache_key = {:product, id}
    case Cachex.get(:my_cache, cache_key) do
      {:ok, nil} ->
        case MyDynamo.get_product(id) do
          {:ok, product} ->
            Cachex.put(:my_cache, cache_key, product, ttl: :timer.minutes(10))
            json(conn, product)
          {:error, _} -> send_resp(conn, :not_found, "Product not found")
        end
      {:ok, cached} ->
        json(conn, cached)
    end
  else
    _ -> send_resp(conn, :bad_request, "Invalid product ID")
  end
end

Second, structure your DynamoDB access code to avoid leaking raw user input into queries that influence caching. Use prepared statements or expression attribute values, and avoid concatenating user input into keys or filter expressions:

def get_product(item_id) when is_integer(item_id) and item_id > 0 do
  key = %{
    "PK" => {"PRODUCT", item_id}
  }
  expression_attribute_values = %{
    ":pk" => %{"S" => "PRODUCT"},
    ":id" => %{"N" => Integer.to_string(item_id)}
  }
  query_input = %{
    table_name: "AppTable",
    key_condition_expression: "PK = :pk AND id = :id",
    expression_attribute_values: expression_attribute_values
  }
  case DynamoDB.query(query_input) do
    {:ok, %{items: [item]}} -> {:ok, item}
    _ -> {:error, :not_found}
  end
end

Third, normalize and sanitize cached DynamoDB responses before reuse. If cached items may contain fields controlled by users, validate and transform them on read to avoid injecting unsafe data back into the system:

def safe_cached_product(conn, cache_key) do
  case Cachex.get(:my_cache, cache_key) do
    {:ok, nil} ->
      {:miss, nil}
    {:ok, item} when is_map(item) ->
      safe_item = %{
        id: item["id"],
        name: item["name"] |> to_string() |> Phoenix.HTML.html_escape(),
        price: Decimal.new(item["price"])
      }
      {:ok, safe_item}
    _ ->
      {:invalid, nil}
  end
end

Finally, standardize TTLs and avoid caching responses that contain sensitive or user-specific data unless the cache key includes tenant or user context and proper isolation is enforced. Use middleware to reject requests with malformed or suspicious parameters before they reach DynamoDB or the cache layer. By combining these patterns, you reduce the surface area for cache poisoning while keeping DynamoDB interactions predictable and safe.