Broken Authentication in Phoenix with Api Keys

Broken Authentication in Phoenix when using API keys typically arises from weak key generation, insecure storage, or improper validation at the endpoint layer. In a Phoenix application, API keys are often passed via headers (e.g., x-api-key) and verified in plugs before routing reaches controller logic. If these checks are incomplete, such as using a constant-time comparison only on a subset of the key or allowing keys to be passed in query strings or logs, the authentication boundary can be bypassed.

Attackers may exploit common misconfigurations: for example, accepting keys from any HTTP method when only safe methods should be allowed, or failing to bind keys to a specific scope or rate limit. Because Phoenix pipelines process plugs in a defined order, placing the authentication plug after session or CSRF handling can inadvertently expose key validation to timing attacks or leakage via error messages. Additionally, if the same key is used across multiple services without rotation, a compromised key leads to lateral movement across systems.

During a black-box scan, middleBrick tests unauthenticated attack surfaces and flags these weaknesses under Authentication and BOLA/IDOR checks. It inspects whether keys are transmitted securely, whether they are validated for each request, and whether responses differ in timing or content when valid versus invalid keys are provided. Findings may map to OWASP API Top 10:2023 — Broken Authentication and related compliance frameworks such as SOC2 and PCI-DSS, highlighting insufficient controls around bearer credentials.

Real-world patterns observed include hard-coded keys in configuration files that appear in version control, lack of revocation mechanisms, and absence of audit logging for key usage. These issues are exacerbated when developers rely solely on obscurity (e.g., non-guessable key paths) rather than cryptographic guarantees. middleBrick’s unauthenticated scans detect such risky configurations by probing endpoints without credentials and analyzing response behavior, ensuring that authentication boundaries are verified independently of implementation assumptions.

Remediation centers on secure key generation, transport, validation, and lifecycle management. In Phoenix, implement authentication as a plug that performs strict checks using constant-time comparisons and avoids side-channel leaks. Store keys encrypted at rest, do not log them, and ensure they are transmitted only over TLS. Bind keys to metadata such as scopes, IP restrictions, or tenant identifiers where applicable, and enforce rate limiting to reduce brute-force risk.

Below are concrete code examples for a secure Phoenix setup using API keys.

defmodule MyAppWeb.ApiKeyPlug do
  import Plug.Conn
  import Timex

  # Constant-time comparison to avoid timing leaks
  defp safe_compare(a, b) when byte_size(a) != byte_size(b), do: false
  defp safe_compare(a, b) do
    do_safe_compare(binary_to_bin(a), binary_to_bin(b), 0, true)
  end
  defp do_safe_compare(<<>>, <<>>, _, acc), do: acc
  defp do_safe_compare(<>, <>, pos, acc) do
    do_safe_compare(rest, rest2, pos + 1, acc && ch == ch2)
  end

  def init(opts), do: opts

  def call(conn, _opts) do
    case get_api_key(conn) do
      {:ok, key} -> validate_and_continue(conn, key)
      :error -> send_resp(conn, 401, "Unauthorized") |> halt()
    end
  end

  defp get_api_key(conn) do
    # Prefer header; reject keys in query strings
    case get_req_header(conn, "x-api-key") do
      [key] when is_binary(key) and byte_size(key) > 0 -> {:ok, key}
      _ -> :error
    end
  end

  defp validate_and_continue(conn, key) do
    # Fetch key from encrypted storage; this example uses a mock lookup
    case MyApp.Accounts.find_valid_key(key, conn.remote_ip) do
      {:ok, metadata} ->
        # Attach metadata for downstream use, do not store key in assigns
        assign(conn, :api_key_metadata, metadata)
      :error ->
        send_resp(conn, 401, "Unauthorized") |> halt()
    end
  end
end

Ensure the plug is inserted early in the pipeline, before any business logic, and after transport security enforcement. In endpoint.ex, add the plug to the appropriate pipeline:

defmodule MyAppWeb.Endpoint do
  use MyAppWeb, :endpoint

  plug(MyAppWeb.ApiKeyPlug)
  plug(MyAppWeb.RateLimiter)
  # Other plugs...
end

For key storage, use encrypted configuration or a secrets manager, and rotate keys periodically. In production, avoid compiling keys into releases; instead inject them via environment variables that are read at runtime. middleBrick’s scans validate that such controls are present by checking for secure transport, correct HTTP method usage, and consistent authentication behavior across endpoints.