Information Disclosure in Buffalo with Jwt Tokens

Information disclosure occurs when a Buffalo application exposes sensitive data such as JSON Web Token (JWT) values in logs, error messages, or API responses. In Buffalo, this commonly happens when developers inadvertently include JWTs in URLs, query parameters, or rendered HTML, making them visible to intermediaries and client-side code. Because JWTs often carry identity and authorization claims, exposing them can lead to account compromise or privilege escalation.

When a Buffalo app uses JWTs for authentication, the framework’s request lifecycle can inadvertently surface tokens if developers do not carefully control what is logged or serialized. For example, writing the incoming Authorization header directly to logs or including it in HTML attributes (e.g., data-token) can disclose the token to anyone who can view logs or inspect client-side source. Additionally, Buffalo applications that embed JWTs in redirects or referrer headers may leak tokens to third-party sites via the Referer header, especially when transitioning from HTTPS to HTTP or when third-party analytics scripts are present.

The interaction between Buffalo’s HTML rendering and JWT handling is particularly risky when developers use template helpers to inject authentication state into pages. If a JWT or a derived value is passed to a template and rendered as plain text, automated scanners and attackers can harvest tokens from page source. This becomes critical when tokens are long-lived or when refresh tokens are embedded in JavaScript, enabling persistent access if the page is cached or shared. Without strict control, what is intended as a server-side session mechanism can become a client-side disclosure vector.

Another vector involves error handling. Buffalo’s default error pages may include request metadata, headers, or parameters when exceptions occur. If a JWT is present in the Authorization header and an unhandled panic or validation error produces a detailed stack trace, the token can be exposed in logs or browser error pages. This aligns with common attack patterns such as error-based information leakage, where attackers use crafted requests to probe for tokens and session identifiers.

Compliance mappings such as OWASP API Top 10 highlight the risk of sensitive data exposure, and PCI-DSS, SOC2, and GDPR all require protection of authentication tokens. In Buffalo, this means treating JWTs as strictly sensitive data, ensuring they are never logged, cached, or serialized in a way that reaches the client. The framework encourages disciplined handling of headers and context, but developers must consciously avoid anti-patterns that turn JWTs into unintended data exposure channels.

To remediate information disclosure with JWTs in Buffalo, ensure tokens are kept server-side, never logged, and never rendered in templates or URLs. Use secure storage mechanisms such as encrypted cookies or server-side sessions for storing tokens, and avoid exposing JWTs in client-side JavaScript. Below are concrete code examples demonstrating safe handling patterns.

Example 1: Avoid logging JWTs

Never log the Authorization header or any part of the token. Instead, log only non-sensitive identifiers.

// Unsafe: logging the full Authorization header
// conn.logger.info("Auth header: #{conn.params["authorization"]}")

// Safe: log only a sanitized reference
auth_header = conn.req.header("authorization")
case auth_header do
  "Bearer " <> token ->
    conn.logger.info("Authenticated request, token omitted")
  _ ->
    conn.logger.info("No bearer token present")
end

Example 2: Do not embed JWTs in templates

Avoid passing JWTs to HTML templates. If you must transmit tokens to client-side code, use short-lived, scoped tokens and ensure they are not embedded in attributes that can be read by third-party scripts.

// Unsafe: rendering token in a template
# In your handler:
# render(conn, "show.html", token: token)

// template (show.html.eex): avoid this
# <div data-token="<%= @token %>">...</div>

// Safe: do not pass the token to the template
render(conn, "show.html", current_user: current_user)

Example 3: Secure cookie-based token storage

Store JWTs in HttpOnly, Secure cookies to prevent JavaScript access and reduce exposure in transit.

# Setting a secure cookie with a JWT
conn
|> put_resp_cookie("auth_token", token,
    http_only: true,
    secure: true,
    same_site: "Lax",
    max_age: 3600
  )
|> send_resp(200, "OK")

# Clearing the token on logout
conn
|> delete_resp_cookie("auth_token")
|> send_resp(200, "Logged out")

Example 4: Protect against Referer leaks

When redirecting after authentication, avoid exposing tokens in the Referer header. Use POST/REDIRECT/GET patterns and do not pass tokens in query strings.

# Unsafe: redirect with token in query
# redirect(conn, "/dashboard?token=#{token}")

# Safe: use session or signed cookies instead
conn
|> put_session(:user_id, user.id)
|> redirect(to: ~p"/dashboard")

Example 5: Validate and sanitize error messages

Ensure error responses do not include request headers or tokens. Use structured error handling to avoid leaking context.

rescue_from Ecto.NoResultsError, fn _conn, _error -
  conn
  |> put_status(:not_found)
  |> json(%{error: "Resource not found"})
end