Beast Attack in Actix with Jwt Tokens

A Beast Attack (short for Bypassing Enforcements via Algorithmic Substitution) can occur in Actix when JWT token validation logic does not enforce a strict expected algorithm. If an application parses JWTs and allows the algorithm to be chosen by the token header without forcing a specific, expected value, an attacker can substitute a weaker algorithm such as none or swap a symmetric algorithm (e.g., HS256) for an asymmetric one (e.g., RS256). In Actix, this typically manifests when the JWT extraction and verification code reads the header’s alg field and uses it to select a key or verification method, rather than requiring a predefined algorithm.

When using JWT tokens in Actix, a common vulnerable pattern is to deserialize the token header to determine the algorithm and then conditionally verify using that algorithm or a key derived from it. For example, if a developer uses a library that defaults to verifying HS256 when the algorithm is missing or unsupported, an attacker can provide an unsigned token with {"alg":"none","typ":"JWT"} and a valid-looking payload. Because the server may treat missing signature validation as acceptable in this configuration, the token is accepted as authenticated, leading to authentication bypass or privilege escalation.

This risk is compounded in Actix when JWT validation is implemented as middleware or via extractor logic that does not explicitly reject unexpected algorithms. If the application trusts the header’s algorithm and uses different keys based on algorithm type (e.g., an RSA public key for RS256 and a shared secret for HS256), an attacker may supply an RS256-typed header with a symmetric key as the public key material, causing the server to interpret the public key as an HMAC key and accept a forged signature. This class of issue maps to authentication weaknesses in the OWASP API Security Top 10 and can be surfaced by middleBrick’s Authentication and BOLA/IDOR checks when JWT tokens are involved.

Real-world exploit patterns resemble CVE-2020-15167-like scenarios where algorithm confusion leads to unsigned tokens being accepted. In an Actix service that exposes unauthenticated endpoints or uses optional JWT validation for certain routes, an attacker can probe endpoints to discover whether the service will accept a JWT with the none algorithm. middleBrick’s unauthenticated scan can detect such misconfigurations by inspecting the API specification and, where possible, testing authentication bypass paths without credentials.

To understand the impact within the context of an Actix service, consider that JWT tokens are often passed in the Authorization header as a Bearer token. If the server code does not enforce a single algorithm and does not validate the issuer, audience, or expiration rigorously, the token’s claims may be trusted even when the signature is missing or invalid. This creates a path for identity spoofing, and in systems where authorization decisions depend on token roles or scopes, it can lead to BOLA/IDOR-like access to other users’ resources.

Remediation centers on enforcing a single, expected algorithm for all JWT tokens and avoiding any runtime algorithm selection from the token header. In Actix, this means configuring your JWT validation layer to require a specific algorithm (e.g., HS256 or RS256) and rejecting tokens that do not match. Below are concrete, realistic code examples that demonstrate secure handling of JWT tokens in Actix using the jsonwebtoken crate.

use actix_web::{web, HttpRequest, Error};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation, TokenData};
use serde::Deserialize;

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

async fn validate_token(headers: &HttpRequest) -> Result, Error> {
    let auth_header = headers.headers().get("Authorization")
        .ok_or(actix_web::error::ErrorUnauthorized("Missing authorization header"))?;
    let auth_str = auth_header.to_str().map_err(|_| actix_web::error::ErrorUnauthorized("Invalid auth string"))?;
    let token = auth_str.strip_prefix("Bearer ").ok_or(actix_web::error::ErrorUnauthorized("Invalid bearer format"))?;

    // Enforce a single expected algorithm; do not read `alg` from the token header.
    let mut validation = Validation::new(Algorithm::HS256);
    validation.validate_exp = true;
    validation.set_audience(&["my-api-audience"]);
    validation.set_issuer(&["trusted-issuer"]);

    let token_data = decode::<Claims>(
        token,
        &DecodingKey::from_secret("YOUR_STRONG_SECRET_KEY".as_ref()),
        &validation,
    )?;
    Ok(token_data)
}

Key points in this example:

• Validation::new(Algorithm::HS256) explicitly sets the expected algorithm instead of deriving it from the token header.
• validate_exp and audience/issuer checks are enabled to enforce standard claims validation.
• The decoding key is constructed from a secret, which matches the chosen symmetric algorithm; if using RS256, you would use DecodingKey::from_rsa_pem with a trusted public certificate.

If your service must support multiple algorithms for a migration period, do not select the algorithm from the token header. Instead, implement a router-like approach where the API knows which algorithm to expect per endpoint or per key ID (kid), and validate accordingly while still rejecting unexpected algorithms. Never fall back to none or allow the header to dictate verification logic.

use actix_web::web::Json;
use serde::Serialize;

#[derive(Serialize)]
struct HealthResponse {
    status: &'static str,
}

async fn public_health() -> Json<HealthResponse> {
    // Public endpoints do not require JWT validation; no bearer extraction.
    Json(HealthResponse { status: "ok" })
}

For endpoints that do require tokens, ensure that the validation function is called consistently and that errors result in 401 responses without leaking details. middleBrick’s scans, including its JWT-related checks under Authentication and LLM/AI Security, can help identify whether an API’s specification and runtime behavior allow algorithm substitution or accept unsigned tokens.