Brute Force Attack in Phoenix with Api Keys

A brute force attack against an API using static API keys in Phoenix can occur when an endpoint authenticates solely by a key exposed client-side or accepted without rate limiting. Because API keys are long-lived credentials, repeated authentication attempts with different key values do not inherently lock an account like a password login might. In a Phoenix-based API, if a route such as /api/v1/export accepts a key via header or query parameter and does not enforce strict request throttling, an attacker can systematically iterate through key values to discover a valid key. This combines the persistence of API keys with the scalability of automated requests, making unauthorized access feasible over time.

The risk is amplified when keys are embedded in JavaScript, mobile clients, or public repositories, as they can be harvested and used in offline brute force campaigns. middleBrick’s Authentication and Rate Limiting checks highlight scenarios where a key is accepted without per-IP or per-key attempt caps, allowing high-volume probing. Because the scan runs black-box and tests unauthenticated attack surfaces, it can detect endpoints that accept API keys but lack sufficient request throttling or suspicious request pattern analysis. The scanner also flags endpoints that expose key-like values in responses or logs, which can be leveraged in subsequent brute force or credential stuffing attempts.

In the context of the 12 parallel checks, brute force risk intersects with Authentication, Rate Limiting, and Data Exposure. For example, an endpoint that returns a detailed error message like “Invalid API key” versus “Forbidden” can aid an attacker in refining guesses, while missing rate limits enable rapid iteration. middleBrick’s probe sequence includes attempts to observe timing differences or response-code variations that indicate key validation logic, which can be chained to infer valid key structures. An Inventory Management check may further reveal that keys are not rotated or revoked after suspected exposure, extending the window for brute force success.

Remediation focuses on reducing the effectiveness of brute force attempts by tightening authentication and limiting request rates. Prefer short-lived tokens or session-based flows where possible, but if static API keys are required, enforce strict rate limits and avoid exposing key validity through verbose errors. In Phoenix, you can leverage plug pipelines and Guardian or Pow for key validation while ensuring each request incurs a consistent computational cost to deter automated guessing.

Example Phoenix controller with safe API key handling and rate limiting using :hammer plug throttling:

defmodule MyAppWeb.ApiKeyController do
  use MyAppWeb, :controller

  # Plug to enforce rate limits per API key (e.g., 60 requests/minute)
  plug :throttle_by_key

  def export(conn, %{"key" => key}) do
    case validate_key(key) do
      {:ok, user} ->
        # Proceed with authorized data export
        json(conn, %{data: "secure_export"})

      {:error, :invalid_key} ->
        # Generic error to avoid key enumeration hints
        conn
        |> put_status(:forbidden)
        |> json(%{error: "access denied"})
    end
  end

  defp validate_key(key) do
    # Constant-time lookup to mitigate timing attacks
    MyApp.Accounts.get_user_by_api_key(key) || {:error, :invalid_key}
  end

  # Custom throttle plug
  def throttle_by_key(conn, _opts) do
    key = conn.params["key"] || get_req_header(conn, "authorization") |> List.first()
    {limit, remaining} = RateLimiter.check(key, 60, 60_000) # 60 per minute

    if remaining < 0 do
      conn
      |> put_status(429)
      |> json(%{error: "rate limit exceeded"})
      |> halt()
    else
      # Add rate-limit headers for observability
      put_resp_header(conn, "x-ratelimit-limit", Integer.to_string(limit))
      |> put_resp_header("x-ratelimit-remaining", Integer.to_string(remaining))
    end
  end
end

Example configuration for rate limiting with :hammer in your endpoint pipeline:

defmodule MyAppWeb.Endpoint do
  use Phoenix.Endpoint, otp_app: :my_app

  plug Plug.Parsers, parsers: [:urlencoded, :multipart, :json]
  plug :accepts, ["json"]
  plug MyAppWeb.ApiKeyController, throttle_by_key: true

  # Other plugs (fetch_session, fetch_flash, etc.)
end

These examples ensure that each API key request incurs similar processing time and that responses do not disclose whether a key was structurally close to valid. Coupled with periodic key rotation and inventory checks from middleBrick’s scan reports, you reduce the feasibility of successful brute force attempts in production.