Api Key Exposure in Phoenix with Session Cookies

In a Phoenix application that relies on session cookies for authentication, an Api Key Exposure risk can emerge when application logic inadvertently exposes long-lived service credentials (API keys) to the client or logs. This typically occurs when a key is stored server-side but accidentally included in JSON responses, error messages, or rendered templates that are sent to the browser. Because session cookies are used to track authenticated state, an attacker who compromises a session (for example via cross-site scripting or session fixation) may be able to leverage the exposed API key to make unauthorized calls to third‑party services on behalf of the user or the application.

The risk is heightened when the API key is embedded in client‑facing JavaScript or passed to the browser via an endpoint that does not properly enforce authorization boundaries. For example, consider an endpoint that returns integration settings to the frontend:

GET /api/integration/settings
Response:
{
  "api_key": "ak_live_abc123...",
  "environment": "production"
}

If this endpoint is accessible while a session cookie is present but does not enforce strict scope checks, an attacker who hijacks or predicts a session cookie can read the key. Additionally, if the Phoenix app logs full requests or responses—including API keys—these logs become a sensitive data exposure risk that can be abused if log access is compromised.

From an OWASP API Top 10 perspective, this aligns with broken object level authorization (BOLA) and data exposure when an identifier or secret that should be server‑side leaks to the client. Unlike secrets stored in HTTP‑only, secure cookies designed for session management, API keys are not intended for browser use and must never be made available to JavaScript. middleBrick scanning of such endpoints would flag this as a high severity finding and map it to compliance frameworks such as PCI‑DSS and SOC2, emphasizing the need to restrict data exposure and tighten authorization checks.

To detect these patterns, middleBrick performs unauthenticated scans and, where appropriate, authenticated scans that include session context. Its LLM/AI Security checks specifically look for system prompt leakage and output patterns that may inadvertently expose credentials, while other checks validate input validation and data exposure controls. This ensures that combinations like Phoenix session cookies plus exposed API keys are surfaced with prioritized remediation guidance.

Remediation focuses on ensuring API keys never reach the client and that session cookies are hardened. In Phoenix, store API keys only in server‑side configuration or secrets providers, and never serialize them into JSON responses or embed them in JavaScript. Use HTTP‑only, Secure, SameSite cookies for session management, and enforce strict authorization on any endpoint that handles sensitive identifiers.

Example of a vulnerable controller that leaks an API key:

defmodule MyAppWeb.IntegrationController do
  use MyAppWeb, :controller

  def settings(conn, _params) do
    api_key = Application.get_env(:my_app, :external_api_key)
    json(conn, %{api_key: api_key, environment: "production"})
  end
end

Fixed version that removes the key from the response and uses a minimal, safe response:

defmodule MyAppWeb.IntegrationController do
  use MyAppWeb, :controller

  def settings(conn, _params) do
    # Do not expose API keys to the client.
    json(conn, %{configured: true, environment: "production"})
  end
end

Ensure session cookies are configured securely in your endpoint pipeline. In lib/my_app_web/endpoint.ex, set cookie options as follows:

plug Plug.Session,
  store: :cookie,
  key: "_my_app_key",
  signing_salt: "your_signing_salt",
  secure: true,
  http_only: true,
  same_site: "Lax"

When using a pipeline that requires authentication, confirm that the session is verified and that endpoints do not over‑authorize by checking ownership or scope. For example, if an endpoint should only return settings for the current user, validate that the requested user ID matches the session subject rather than trusting path or query parameters alone. middleBrick’s BOLA/IDOR checks will highlight cases where session context is not properly enforced, and its remediation guidance will suggest scoping rules and object ownership checks.

Finally, audit logs to ensure API keys are not present in request or response logs. Configure your logger to filter sensitive parameters, and avoid logging full responses that may contain secrets. middleBrick’s Data Exposure checks can validate that your endpoints do not inadvertently surface sensitive fields and that encryption and access controls are appropriately applied.