Formula Injection in Actix with Jwt Tokens

Formula Injection in Actix applications using JWT tokens occurs when untrusted input is used to construct tokens or influence token handling without proper validation. This can lead to token manipulation, authentication bypass, or exposure of sensitive claims. In Actix, a Rust web framework, developers often parse and validate JWTs in request handlers or middleware. If user-controlled data—such as identifiers, roles, or session metadata—is incorporated into the token payload or used to dynamically select signing keys, an attacker may inject formulas that alter token behavior.

Consider an endpoint that builds a JWT based on user-supplied input, such as a tenant ID or user role. If the input is not strictly validated and is directly embedded into claims, an attacker might provide a crafted value like "role": "admin" or manipulate the token structure through unexpected characters. In Actix, this can arise when using handler parameters or path extractors to populate claims. For example, a developer might deserialize a JSON body and merge it into a claims struct without strict schema enforcement:

use actix_web::{web, HttpResponse};
use jsonwebtoken::{encode, Header, EncodingKey};

#[derive(serde::Deserialize)]
struct UserInput {
    sub: String,
    role: String,
}

async fn issue_token(form: web::Json<UserInput>) -> HttpResponse {
    let claims = Claims {
        sub: form.sub.clone(),
        role: form.role.clone(), // Unsafe: directly from user input
        exp: (chrono::Utc::now() + chrono::Duration::hours(1)).timestamp(),
    };
    let token = encode(&Header::default(), &claims, &EncodingKey::from_secret(&SECRET))
        .map_err(|_| HttpResponse::InternalServerError())?;
    HttpResponse::Ok().body(token)
}

While this snippet appears safe, the vulnerability emerges when the token is later used in a broader system context—such as being passed to another service or used to drive authorization decisions—where the injected role claim escalates privileges. Additionally, if the application uses dynamic key selection based on input (e.g., selecting a key by tenant ID), an attacker might supply a tenant identifier that maps to a weaker key or no key at all, effectively disabling signature verification.

Another vector involves parsing tokens where the header or payload is influenced by external data. Actix middleware might inspect incoming tokens and make routing or logging decisions based on claims. If an attacker can control part of the token—say, by leveraging insecure deserialization or by exploiting a trust boundary where a non-validated token is accepted—they can inject formulas that change the token’s interpretation. For example, supplying a malformed kid (key ID) might cause the application to fall back to a default key or skip validation entirely, a pattern seen in real-world vulnerabilities involving insecure JWK sets.

These issues map to the broader OWASP API Top 10 category of Broken Object Level Authorization (BOLA) and can be flagged during an unauthenticated scan by middleBrick. The scanner’s twelve parallel checks—including Input Validation, BOLA/IDOR, and Unsafe Consumption—can detect anomalous token behavior, such as unexpected claim escalation or missing validation on dynamic inputs. middleBrick’s LLM/AI Security checks further probe for prompt injection risks if token data is used to influence language model interactions, adding another layer of concern for AI-integrated APIs.

Remediation focuses on strict input validation, canonical token handling, and avoiding runtime formula construction. Developers should treat all external data as untrusted and never allow user input to directly dictate token structure or key selection. Using fixed claim schemas and static key references mitigates most risks. The following section outlines concrete code fixes for Actix applications.

To secure JWT usage in Actix, enforce strict input validation, avoid dynamic claim population, and use static, verified keys. Below are concrete, safe patterns that prevent formula injection by isolating user input from token logic.

1. Validate and sanitize all external data before use. Do not merge raw user input into claims. Instead, map input to a controlled set of values:

use actix_web::{web, HttpResponse};
use jsonwebtoken::{encode, Header, EncodingKey};
use serde::{Deserialize, Serialize};

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

#[derive(serde::Deserialize)]
struct CreateTokenInput {
    sub: String,
    role: String,
}

fn validate_role(input: &str) -> Option {
    match input {
        "user" | "admin" => Some(input.to_string()),
        _ => None,
    }
}

async fn safe_issue_token(form: web::Json<CreateTokenInput>) -> HttpResponse {
    let role = match validate_role(&form.role) {
        Some(r) => r,
        None => return HttpResponse::BadRequest().body("Invalid role"),
    };

    let claims = Claims {
        sub: form.sub.clone(),
        role,
        exp: (chrono::Utc::now() + chrono::Duration::hours(1)).timestamp(),
    };

    let token = encode(
        &Header::default(),
        &claims,
        &EncodingKey::from_secret(include_bytes!("secret.key")),
    )
    .unwrap_or_else(|_| {
        HttpResponse::InternalServerError().body("Token encoding failed")
    });

    HttpResponse::Ok().body(token)
}

This approach validates the role against a whitelist and uses a static secret key, eliminating formula-based manipulation.

2. Use fixed key references and avoid dynamic key selection. Do not derive keys from request data. Instead, load keys securely at startup:

use jsonwebtoken::{decode, Validation, DecodingKey};

const SECRET: &[u8] = include_bytes!("secret.key");

async fn verify_token(token: &str) -> bool {
    let validation = Validation::default();
    decode::

async fn protected_route(token: String) -> HttpResponse {
    match verify_token(&token) {
        true => HttpResponse::Ok().body("Access granted"),
        false => HttpResponse::Unauthorized()
            .json(	{ "error": "invalid_token" }), // Generic error
    }
}