Api Key Exposure in Actix with Jwt Tokens

When JWT tokens are used in Actix applications without strict transport and storage controls, API keys and signing secrets can be inadvertently exposed. This typically occurs when tokens are passed in URLs, debug logs, or insecure headers, allowing an attacker to harvest credentials needed to impersonate services. Because JWTs often carry authorization claims, exposure can lead to privilege escalation, data access, and lateral movement across microservices.

Actix applications that embed API keys inside JWT payloads or place tokens in non-secure cookie attributes increase the risk of exposure through client-side inspection or network interception. For example, if a token is transmitted over HTTP or with Secure and HttpOnly flags omitted, an attacker may capture the token and reuse it to access protected endpoints. Similarly, verbose error messages in Actix handlers can leak token material or key identifiers in stack traces, aiding an attacker in refining further attacks such as token replay or signature manipulation.

The interplay between Actix routing, middleware, and JWT extraction logic can unintentionally broaden the attack surface. If token validation skips audience or issuer checks, or if the middleware trusts unverified claims, an attacker might supply a crafted token that exposes internal API keys or service metadata during introspection. Insecure deserialization of token claims, or failure to rotate signing keys, compounds the risk by enabling long-lived tokens to remain valid after a key is compromised.

During a black-box scan, middleBrick tests for these conditions by probing unauthenticated endpoints and inspecting response headers, cookies, and error payloads for token leakage. Checks include verifying HTTPS enforcement, secure cookie attributes, absence of tokens in URLs, and ensuring error responses do not contain sensitive material. The LLM/AI Security module further evaluates whether system prompts or configuration details could be coaxed into revealing token formats or API key locations through prompt injection techniques.

To illustrate secure implementation, the following code examples show how to handle JWTs safely in Actix. These examples emphasize strict validation, secure transport, and minimal exposure of sensitive data in logs or responses.

use actix_web::{web, App, HttpServer, HttpResponse, middleware::Logger};
use actix_web_httpauth::extractors::bearer::BearerAuth;
use jsonwebtoken::{decode, Validation, Algorithm, DecodingKey};
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    company: String,
    exp: usize,
    api_key_id: String,
}

async fn validate_token(auth: BearerAuth) -> Result {
    let token = auth.token();
    let validation = Validation::new(Algorithm::HS256);
    let token_data = decode::(
        token,
        &DecodingKey::from_secret("super_secret_key".as_ref()),
        &validation,
    ).map_err(|_| HttpResponse::Unauthorized().finish())?;

    // Avoid logging token or raw API key material
    info!("token validated for user: {}", token_data.claims.sub);

    Ok(HttpResponse::Ok().json(token_data.claims))
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    std::env::set_var("RUST_LOG", "actix_web=info");
    env_logger::init();

    HttpServer::new(|| {
        App::new()
            .wrap(Logger::default())
            .route("/protected", web::get()._to(validate_token))
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

Remediation focuses on preventing token and API key exposure by enforcing transport security, tightening validation, and avoiding unsafe logging. Actix configurations should mandate HTTPS, use secure cookie attributes when storing tokens, and validate all JWT claims strictly. Tokens must never appear in URLs or logs, and signing keys must be managed externally and rotated regularly.

Implementing middleware that checks for secure transport and validates token metadata reduces the likelihood of exposure. Error handling should be generic to avoid leaking token details, and responses must avoid including raw tokens or keys. The following code examples demonstrate secure patterns for JWT handling in Actix.

use actix_web::{web, App, HttpServer, HttpResponse, Error};
use actix_web_httpauth::extractors::bearer::BearerAuth;
use jsonwebtoken::{decode, Validation, Algorithm, DecodingKey, errors::Error as JwtError};
use serde::{Deserialize, Serialize};
use std::env;

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    aud: String,
    iss: String,
    exp: usize,
    api_key_id: String,
}

async fn validate_secure_token(auth: BearerAuth) -> Result {
    let token = auth.token();
    let audience = env::var("AUDIENCE").unwrap_or_else(|_| "myapp".into());
    let issuer = env::var("ISSUER").unwrap_or_else(|_| "authservice".into());

    let validation = Validation {
        algorithms: vec![Algorithm::HS256],
        audience: audience.into(),
        iss: Some(issuer.into()),
        ..Validation::default()
    };

    let key = env::var("JWT_SECRET").expect("JWT_SECRET must be set");
    let token_data = decode::(
        token,
        &DecodingKey::from_secret(key.as_ref()),
        &validation,
    ).map_err(|err: JwtError| {
        // Avoid exposing token or key details in errors
        actix_web::error::ErrorUnauthorized("invalid credentials")
    })?;

    // Use structured logging without token or key material
    info!(user = %token_data.claims.sub, key_id = %token_data.claims.api_key_id, "token validated");

    Ok(HttpResponse::Ok().json(token_data.claims))
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    dotenv::dotenv().ok();
    std::env::set_var("RUST_LOG", "actix_web=info");
    env_logger::init();

    HttpServer::new(|| {
        App::new()
            .wrap(Logger::default())
            .service(web::resource("/api/secure").route(web::get().to(validate_secure_token)))
    })
    .bind(("0.0.0.0", 8443))?
    .run()
    .await
}

Complementary practices include storing secrets in environment variables or a secrets manager, enabling HTTP Strict Transport Security (HSTS), and setting the SameSite and Secure flags on cookies if tokens are stored client-side. middleBrick can help verify these controls by scanning endpoints and flagging missing transport protections or unsafe error handling that could aid exposure.