Api Key Exposure in Phoenix with Hmac Signatures

In Phoenix applications that use Hmac Signatures for request authentication, Api Key Exposure typically occurs when the secret key is inadvertently exposed in client-side code, logs, or error messages. Hmac Signatures rely on a shared secret to sign requests; if this secret is leaked, an attacker can forge authenticated requests. A common pattern in Phoenix is to compute an HMAC on the client using the secret and include the signature in request headers. When the client is a frontend JavaScript bundle, embedding the secret directly in the source code or build artifacts can lead to exposure through browser inspection or source code leaks.

Another exposure vector arises from debug endpoints or verbose error reporting. For example, a Phoenix controller that logs incoming headers for debugging might inadvertently log the Authorization header containing the signature alongside other metadata. If logs are centralized or retained, the combination of the API key (used to generate the Hmac) and the signature can be correlated by an attacker. Additionally, misconfigured CORS or improperly guarded routes can allow untrusted origins to trigger authenticated requests, amplifying the impact of any exposed key material.

Consider a typical Hmac flow in Phoenix: the client creates a canonical string, signs it with a secret, and sends the signature and key ID in headers. If the key ID is guessable or the secret is weak, and if the endpoint does not enforce strict input validation, SSRF or injection issues discovered by the scanner could lead to the secret being inferred or extracted. The scanner’s Authentication and BOLA/IDOR checks can surface endpoints where key material is handled without sufficient isolation, while the Data Exposure check may flag verbose responses or logs that include sensitive values. Because middleBrick scans the unauthenticated attack surface, it can detect whether an endpoint reveals key identifiers or patterns that facilitate Hmac reconstruction.

Real-world attack patterns mirror these risks. For instance, a compromised build pipeline might publish a JavaScript bundle containing the Hmac secret, and subsequent static analysis by an attacker can extract it. The presence of an Inventory Management or Unsafe Consumption check in middleBrick helps identify endpoints that expose metadata about supported authentication schemes, potentially hinting at weak key management practices. Without runtime protection or strict separation of duties, the combination of Hmac Signatures and exposed keys leads to authentication bypass, allowing attackers to impersonate legitimate clients.

To contextualize findings, middleBrick maps results to frameworks such as OWASP API Top 10, noting risks related to Broken Object Level Authorization and Security Misconfiguration. When scanning a Phoenix endpoint, the tool evaluates whether authentication relies on static secrets that could be exposed and whether signatures are validated securely. The scanner does not alter runtime behavior but provides prioritized findings with remediation guidance, enabling teams to address exposure before an attacker exploits it.

Remediation focuses on ensuring the Hmac secret is never exposed to the client and is handled only within secure server-side components. In Phoenix, keep the secret in runtime configuration that is not bundled with frontend assets, and use environment variables or encrypted secrets managed by your deployment platform. Avoid logging headers that contain authentication signatures, and ensure error messages do not reflect the computed Hmac or related metadata.

Below are concrete code examples demonstrating secure Hmac handling in Phoenix. First, a controller that validates an Hmac signature without exposing the secret:

defmodule MyAppWeb.ApiController do
  use MyAppWeb, :controller

  @hmac_header "x-api-signature"
  @key_id_header "x-api-key-id"

  def process_request(conn, _opts) do
    with { :ok, secret } <- get_hmac_secret(conn),
         { :ok, key_id } <- get_key_id(conn),
         true <- validate_signature(conn, secret) do
      # proceed with authenticated request handling
      json(conn, %{ status: "ok" })
    else
      _ -> send_resp(conn, 401, "invalid signature")
    end
  end

  defp get_hmac_secret(conn) do
    key_id = get_req_header(conn, @key_id_header) |> List.first()
    # Fetch secret securely from configuration or a vault; do not embed in source
    secrets = Application.get_env(:my_app, :hmac_secrets, %{})
    {:ok, Map.get(secrets, key_id)}
  end

  defp get_key_id(conn) do
    case get_req_header(conn, @key_id_header) do
      [id] when is_binary(id) and byte_size(id) > 0 -> {:ok, id}
      _ -> {:error, :missing_key_id}
    end
  end

  defp validate_signature(conn, secret) when is_binary(secret) do
    signature = get_req_header(conn, @hmac_header) |> List.first()
    body = conn.body_params |> Jason.encode!()
    computed = :crypto.mac(:hmac, :sha256, secret, body)
    computed_hex = Base.encode16(computed, case: :lower)
    secure_compare(computed_hex, signature)
  end

  defp secure_compare(a, a), do: true
  defp secure_compare(_, _), do: false
end

This example avoids exposing the secret by retrieving it from application configuration scoped by key ID. It performs constant-time comparison to mitigate timing attacks and ensures the secret is not present in logs or client-side code. The configuration should be injected at runtime, for example using system environment variables or a secrets manager, and must not appear in version-controlled files.

Second, ensure that telemetry or logging does not capture sensitive values. Update your logger configuration to filter headers related to authentication:

# config/config.exs
config :logger, :console,
  filter_parameters: ["x-api-signature", "x-api-key-id", "authorization"]

By filtering these parameters, Phoenix prevents accidental inclusion of Hmac signatures and keys in log output, reducing the risk of correlation attacks. Combine this with strict CORS policies and route-level authorization to ensure that only trusted origins can invoke authenticated endpoints. middleBrick’s checks for Authentication, Data Exposure, and BOLA/IDOR help verify that such controls are effective and that no endpoint inadvertently leaks key material or signatures.

Finally, rotate Hmac secrets periodically and implement key ID scoping to limit blast radius. The Pro plan’s continuous monitoring can detect regressions, while the CLI allows you to validate fixes locally with middlebrick scan <url>. The Dashboard helps track scores over time, ensuring that remediation efforts improve your security posture and remain aligned with compliance frameworks such as OWASP API Top 10 and SOC2.