Api Key Exposure in Phoenix with Saml

When Phoenix applications rely on SAML for identity federation, developers often focus on login flow correctness and may inadvertently expose API keys through misconfigured endpoints or debug routes. In a black-box scan using middleBrick, the tool tests unauthenticated attack surfaces and looks for patterns where an API key is returned in responses, logs, or error messages tied to a SAML-authenticated session. The scanner’s Authentication and Data Exposure checks run in parallel, probing for endpoints that return secrets when a SAML assertion is present but access controls are weak.

For example, if a Phoenix controller action uses SAML attributes to authorize access but still returns environment variables or configuration containing an API key in JSON or HTML, middleBrick’s Data Exposure check flags this as a finding. Common root causes include:

• Debug or health endpoints that return full configuration without considering that a SAML session may grant broader visibility than intended.
• Improper merging of SAML attributes with API key usage, where a key is embedded in a response for a service that should be accessed server-side only.
• Lack of proper Content Security Policy or referrer policies that allow API keys to be leaked via Referer headers when the client browser navigates away from a SAML-protected page.

middleBrick’s LLM/AI Security checks add another layer by testing for prompt injection and system prompt leakage, but for API key exposure, the focus is on how runtime responses can disclose secrets when SAML identity is trusted. If an endpoint echoes the current user’s attributes and also prints an API key from application config, a scanner can extract the key using a simple authenticated probe (after SAML login) and report it as high severity. This is particularly risky when the same key is used across services, because exposure in one SAML-enabled endpoint can lead to lateral movement.

Compliance frameworks mapped by middleBrick, such as OWASP API Top 10 and SOC2, highlight the importance of protecting secrets and ensuring that authenticated sessions do not inadvertently expose sensitive configuration. A typical finding will include severity, a description of how SAML context may have contributed to visibility, and remediation guidance that emphasizes separating identity from secrets and tightening output encoding.

Remediation centers on ensuring that API keys never appear in responses, logs, or error messages, even when a SAML assertion is present. In Phoenix, you should enforce strict separation between identity attributes provided by SAML and any sensitive configuration. Below are concrete patterns to apply.

1. Exclude sensitive configuration from controller responses

Do not serialize API keys or secrets in any JSON response, even if the request came with a valid SAML session. Use a view that omits sensitive fields.

defmodule MyAppWeb.UserController do
  use MyAppWeb, :controller

  def show(conn, %{"id" => id}) do
    user = Accounts.get_user!(id)
    # Never include API keys in the response
    json(conn, %{id: user.id, email: user.email, name: user.name})
  end
end

2. Protect debug and health endpoints

Ensure health or info endpoints do not return configuration or environment variables when accessed over HTTP, even if the caller presents a SAML token.

defmodule MyAppWeb.HealthController do
  use MyAppWeb, :controller

  def check(conn, _params) do
    # Return minimal status without secrets
    json(conn, %{status: "ok"})
  end
end

3. Configure SAML attributes carefully

When setting up SAML in Phoenix, avoid injecting sensitive metadata into the session that could be combined with API keys. Only assert the attributes you need for authorization.

# In your SAML configuration (e.g., via plug_saml)
config :my_app, MyApp.Saml,
  adapter: SAML.AdapterPlug,
  idp_cert_fingerprint: "AA:BB:CC:...",
  sp_cert: "-----BEGIN CERTIFICATE-----...",
  sp_key: "-----BEGIN RSA PRIVATE KEY-----...",
  assertion_consumer_service: "https://app.example.com/saml/consume",
  attributes: [:email, :name, :groups]  # Only safe attributes

4. Enforce referrer and CSP headers

Add plugs to reduce the risk of API keys leaking via Referer headers when browsers navigate away from SAML-protected pages.

defmodule MyAppWeb.Plugs.SecureHeaders do
  import Plug.Conn

  def init(opts), do: opts

  def call(conn, _opts) do
    conn
    |> put_resp_header("referrer-policy", "no-referrer")
    |> put_resp_header("content-security-policy", "default-src 'self'")
  end
end

5. Audit logs and error handling

Ensure error messages and logs do not include API keys. Use Elixir’s Logger metadata to filter sensitive items and sanitize any inspected data.

defmodule MyAppWeb.Plugs.Audit do
  import Plug.Conn

  def init(opts), do: opts

  def call(conn, _opts) do
    # Example: redact sensitive fields in logs
    Logger.metadata(request_id: conn.request_path)
    conn
  end
end

By applying these patterns, the scan results from middleBrick’s Web Dashboard and CLI will show reduced risk for API key exposure, and findings will map more cleanly to compliance requirements without relying on automatic fixes.