Api Key Exposure in Axum with Session Cookies

When an Axum application uses session cookies to carry an API key, the risk of Api Key Exposure arises from how cookies are transmitted and stored. Axum, a web application framework for Rust, typically relies on middleware to manage session data. If the API key is stored in a session cookie without additional protections, it can be exposed in several scenarios. For example, cookies may be transmitted over unencrypted HTTP if the application does not enforce HTTPS, allowing an attacker on the network to intercept the key via packet sniffing. Session cookies that lack the Secure flag are sent over unencrypted channels, making interception trivial.

Additionally, if the cookie is not marked HttpOnly, it becomes accessible to JavaScript running in the browser. This exposes the API key to cross-site scripting (XSS) attacks, where malicious scripts can read the cookie value. The OWASP Top 10 category for Injection and Broken Access Control is relevant here, as XSS can lead to unauthorized access to the API key. Furthermore, session cookies without the SameSite attribute may be sent in cross-site requests, potentially enabling cross-site request forgery (CSRF) attacks that could lead to unauthorized API usage.

Another vector involves server-side session storage misconfigurations. If the session store (such as a Redis instance or in-memory store) is not properly secured, an attacker who gains access to the store can retrieve session data, including the embedded API key. The risk is compounded if the session ID is predictable or if the application does not rotate session identifiers after authentication. In a black-box scan, middleBrick checks for missing Secure and HttpOnly flags, SameSite settings, and whether the application transmits sensitive data in cookies over unencrypted channels. These checks map to OWASP API Top 10 items such as Broken Object Level Authorization and Security Misconfiguration.

In the context of LLM security, if an Axum endpoint exposed via an API returns session cookies in responses and those cookies contain API keys, middleBrick’s LLM/AI Security checks can detect whether such sensitive data leaks into model outputs or prompts. For instance, an active prompt injection probe might attempt to coax the system into returning cookie values in chat completions, which would indicate a pathway for key exfiltration. The scanner also reviews OpenAPI specifications to see if cookie-based authentication is documented without appropriate security schemes, ensuring that runtime behavior aligns with declared contracts.

Real-world examples include scenarios where developers set API keys directly in session cookies for convenience, bypassing secure storage mechanisms like environment variables or vaults. A vulnerable Axum route might look like this, where the API key is stored in a cookie without adequate protections:

use axum::{routing::get, Router};
use std::net::SocketAddr;

async fn handler() -> &'static str {
    // Vulnerable: API key in session cookie without Secure/HttpOnly
    "key set";
}

#[tokio::main]
async fn main() {
    let app = Router::new().route("/set", get(handler));
    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr).serve(app.into_make_service()).await.unwrap();
}

This snippet illustrates how a session-based approach can inadvertently expose credentials if cookie attributes are not rigorously enforced. middleBrick’s scan would flag missing security flags and provide remediation guidance, emphasizing the need for encrypted transmission and client-side isolation of sensitive data.

To remediate Api Key Exposure when using session cookies in Axum, developers must enforce strict cookie attributes and avoid storing sensitive data directly in cookies. The primary strategy is to store only a session identifier in the cookie and keep the API key on the server side, associated with that identifier in a secure store.

First, ensure all cookies are transmitted securely by setting the Secure flag, which guarantees they are only sent over HTTPS. This prevents network eavesdropping. Second, mark cookies as HttpOnly to protect against XSS-based theft. Third, set the SameSite attribute to Lax or Strict to mitigate CSRF risks. These settings should be applied consistently across all session-related responses.

Below is a secure Axum example that sets a session cookie with appropriate security flags and keeps the API key in server-side memory:

use axum::{routing::get, response::IntoResponse, Extension, Router};
use std::net::SocketAddr;
use std::sync::{Arc, Mutex};

struct AppState {
    api_key: String,
    session_store: std::collections::HashMap, // session_id -> api_key
}

async fn set_session(
    Extension(state): Extension,
) -> impl IntoResponse {
    let session_id = uuid::Uuid::new_v4().to_string();
    // Store API key server-side, not in the cookie
    state.session_store.lock().unwrap().insert(session_id.clone(), state.api_key.clone());
    (
        [(axum::http::header::SET_COOKIE, format!("session_id={}; Path=/; Secure; HttpOnly; SameSite=Lax", session_id))],
        "Session created",
    )
}

async fn handler() -> &'static str {
    "OK"
}

#[tokio::main]
async fn main() {
    let app_state = Arc::new(AppState {
        api_key: std::env::var("API_KEY").expect("API_KEY must be set"),
        session_store: std::collections::HashMap::new(),
    });

    let app = Router::new()
        .route("/set", get(set_session))
        .route("/data", get(handler))
        .layer(Extension(app_state));

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr).serve(app.into_make_service()).await.unwrap();
}

In this example, the API key is stored in the server’s memory (via Arc<AppState>), not in the cookie. The cookie contains only a session identifier, and it is protected with Secure, HttpOnly, and SameSite=Lax. This approach aligns with best practices for session management and reduces the attack surface for key exposure.

middleBrick’s scans can validate these configurations by checking cookie attributes in responses and verifying that sensitive data is not present in cookie values. The tool also cross-references OpenAPI specs to ensure that authentication schemes correctly describe cookie-based mechanisms without implying that keys are client-side accessible.