Broken Access Control in Phoenix with Hmac Signatures

Broken Access Control occurs when authorization checks are missing or bypassed, allowing a user to access functionality or data not intended for them. In Phoenix applications that use Hmac Signatures for request authentication, this vulnerability can emerge when the server validates the signature but fails to enforce per‑resource or per‑action authorization. Hmac Signatures prove that a request was signed by a holder of a shared secret, but they do not by themselves convey what the caller is allowed to do.

Consider an endpoint like GET /api/users/:user_id/profile. If the route only verifies the Hmac Signature and the associated user identity, an attacker can simply change :user_id to another user’s ID. Because there is no check that the authenticated subject owns or is permitted to view that specific profile, the request succeeds, resulting in a Broken Access Control (BOLA/IDOR) finding under the middleBrick BOLA/IDOR check. middleBrick flags this as a high severity finding because the unauthenticated attack surface allows enumeration or unauthorized data access solely by manipulating identifiers.

Similarly, privilege escalation can occur when a Hmac-signed request includes a role or claim that the server trusts without re‑validating it against an authorization model. For example, a client might sign a request with an is_admin claim embedded in the payload or query parameters. If the server uses the claim to make authorization decisions but does not recompute authorization based on a server‑side source of truth, an attacker can forge an admin request by altering the signed parameters within the constraints of the Hmac scheme. This maps to the BFLA/Privilege Escalation checks in middleBrick, which looks for cases where signature validation does not prevent privilege abuse.

Another common pattern is missing or inconsistent authorization on collection versus individual resources. An API might allow a signed request to list all records but fail to ensure that operations on a specific record are gated by ownership or role. This inconsistency is detectable by middleBrick’s Property Authorization checks, which compare the runtime behavior against the OpenAPI/Swagger spec (including resolved $ref definitions) to see whether authorization is applied consistently across operations. When Hmac Signatures are used for authentication but authorization is sparse, the attack surface expands, increasing the likelihood of data exposure and over‑privileged operations.

Because Hmac Signatures only guarantee integrity and origin authenticity, developers must explicitly encode authorization within each handler. middleBrick’s 12 security checks run in parallel and are designed to surface these gaps without requiring credentials, making it effective at detecting Broken Access Control issues in Hmac‑protected Phoenix APIs through unauthenticated scanning.

To remediate Broken Access Control when using Hmac Signatures in Phoenix, treat the signature as authentication only and implement explicit authorization for each resource and action. Below are concrete, realistic code examples that you can adapt to your project.

1. Verify Hmac Signature and Extract Claims Safely

First, validate the signature and deserialize the payload before any authorization decision. Use constant‑time comparison to avoid timing attacks.

defmodule MyAppWeb.Plugs.VerifyHmac do
  import Plug.Conn
  import Phoenix.Controller, only: [json: 2, put_status: 2]
  alias MyAppWeb.HmacUtils

  def init(opts), do: opts

  def call(conn, _opts) do
    with [signature] <- get_req_header(conn, "x-api-signature"),
         {:ok, payload} <- HmacUtils.verify_and_decode(signature, conn.body_params) do
      # Attach subject and claims for downstream authorization
      assign(conn, :auth, %{subject: payload["sub"], roles: payload["roles"], user_id: payload["user_id"]})
    else
      _ ->
        conn
        |> put_status(:unauthorized)
        |> json(%{error: "invalid_signature"})
        |> halt()
    end
  end
end

2. Enforce Ownership in Handlers

In your controller or context, ensure the authenticated subject matches the requested resource. Do not rely on the client‑supplied ID alone; recompute or verify ownership server‑side.

defmodule MyAppWeb.ProfileController do
  use MyAppWeb, :controller
  alias MyApp.Accounts

  def show(conn, %{"user_id" => user_id}) do
    auth = conn.assigns.auth
    # Authorization: subject must match requested user_id
    if auth.subject == user_id or Enum.member?(auth.roles, "admin") do
      profile = Accounts.get_profile!(user_id)
      json(conn, profile)
    else
      conn
      |> put_status(:forbidden)
      |> json(%{error: "access_denied"})
    end
  end
end

3. Apply Role‑Based Checks for Admin Operations

For endpoints that require elevated privileges, explicitly check roles rather than trusting any client‑side claim embedded in the Hmac payload.

defmodule MyAppWeb.AdminController do
  use MyAppWeb, :controller

  def delete_user(conn, %{"id" => id}) do
    auth = conn.assigns.auth
    if Enum.member?(auth.roles, "admin") do
      MyApp.Accounts.delete_user(id)
      send_resp(conn, :no_content, "")
    else
      conn
      |> put_status(:forbidden)
      |> json(%{error: "insufficient_scope"})
    end
  end
end

4. Use a Resource‑Level Policy Module

Encapsulate authorization logic so it is consistent and testable. A simple policy module can centralize rules for each resource.

defmodule MyApp.Policies.Profile do
  def can_view?(%{roles: roles, subject: subject}, user_id) do
    subject == user_id or Enum.member?(roles, "admin")
  end

  def can_manage?(%{roles: roles}, _user_id) do
    Enum.member?(roles, "admin")
  end
end

# In controller
if MyApp.Policies.Profile.can_view?(conn.assigns.auth, user_id) do
  # proceed
else
  # deny
end

5. Validate Against OpenAPI/Swagger with middleBrick

Ensure your OpenAPI/Swagger spec accurately reflects which operations require authorization and which do not. middleBrick’s OpenAPI/Swagger spec analysis resolves $ref definitions and cross‑references them with runtime findings to highlight missing authorization on specific paths or methods. Use the insights from middleBrick’s Property Authorization and BOLA/IDOR checks to tighten your specs and handlers.

6. Combine with Rate Limiting and Monitoring

While not a fix for Broken Access Control, rate limiting helps reduce automated enumeration. Combine Hmac verification, explicit ownership checks, and monitoring to reduce risk. On the Pro plan, middleBrick’s continuous monitoring can alert you if new endpoints appear or if existing endpoints lose authorization coverage.