Integrity Failures in Actix with Jwt Tokens

Integrity failures occur when an API fails to detect tampering with tokens or requests, enabling attackers to modify claims, keys, or signatures. In Actix applications that use JWT tokens, this often arises from improper validation of the token signature, algorithm confusion, or accepting unsigned tokens. When JWT tokens are processed without strict algorithm enforcement and without validating the issuer and audience, an attacker can substitute a signed token with a modified payload or change the signing algorithm to none.

For example, if an Actix service decodes a JWT without verifying the signature or accepts tokens with the none algorithm, an attacker can craft a token with elevated roles or impersonate another user. The token may be generated by an identity provider, but if Actix does not enforce strong signature verification, the integrity of the identity assertion is lost. This is particularly risky when the API also trusts tokens from multiple sources without validating the key material or the token structure.

Middleware or handlers that deserialize JWT tokens into data structures without verifying the digital signature can inadvertently trust attacker-controlled data. In Actix, this often manifests in route guards or extractor implementations that rely on a JWT claims structure without ensuring the token has not been altered. Since JWT tokens typically contain authorization information such as scopes or roles, integrity failures allow privilege escalation or unauthorized access across endpoints.

Actix web frameworks may also expose integrity issues through inconsistent token validation across services. If one service validates tokens strictly and another does not, an attacker can route requests through the weaker service to bypass intended controls. This inconsistency is common in microservice deployments where JWT tokens are shared across services but not uniformly validated for signature integrity and token binding.

Real-world attack patterns mirror findings from the OWASP API Security Top 10, specifically Broken Object Level Authorization (BOLA) and Signature Validation weaknesses. A scanner running the LLM/AI Security checks and 12 security checks in parallel can surface these integrity failures by testing unsigned tokens, algorithm substitution, and tampered claims against Actix endpoints. Findings include missing signature verification, lack of audience validation, and acceptance of tokens with insecure algorithms.

Remediation centers on strict JWT validation, including algorithm enforcement, issuer and audience checks, and signature verification. In Actix, use dedicated JWT libraries and avoid manual parsing. Always validate the token signature against a trusted key or certificate and specify the expected algorithms explicitly.

Below are concrete, working code examples for secure JWT handling in Actix.

Example 1: Validate JWT with HS256 and strict claims

use actix_web::{web, HttpResponse, Result};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation, TokenData};
use serde::{Deserialize, Serialize};

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

async fn validate_jwt(token: &str) -> Result> {
    let decoding_key = DecodingKey::from_secret("your-256-bit-secret".as_ref());
    let mut validation = Validation::new(Algorithm::HS256);
    validation.validate_exp = true;
    validation.set_issuer(&["https://your-auth-server.com"]);
    validation.set_audience(&["your-api-audience"]);
    validation.required_spec_claims.insert("iss".to_string());
    validation.required_spec_claims.insert("aud".to_string());

    let token_data = decode::(token, &decoding_key, &validation)?;
    Ok(token_data)
}

async fn protected_route(token: web::Header<actix_web_httpauth::headers::authorization::Bearer>) -> Result {
    match validate_jwt(token.token()).await {
        Ok(data) => Ok(HttpResponse::Ok().json(format!("User: {}, roles: {:?}", data.claims.sub, data.claims.roles))),
        Err(_) => Ok(HttpResponse::Unauthorized().body("Invalid token")),
    }
}

Example 2: Validate JWT with RS256 using public key

use actix_web::{web, HttpResponse, Result};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation, TokenData};
use std::fs;

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

async fn validate_jwt_rsa(token: &str) -> Result> {
    // Load public key from PEM file
    let public_key = fs::read("/path/to/public-key.pem").expect("unable to read public key");
    let decoding_key = DecodingKey::from_rsa_pem(&public_key).expect("invalid public key format");

    let mut validation = Validation::new(Algorithm::RS256);
    validation.validate_exp = true;
    validation.set_issuer(&["https://your-auth-server.com"]);
    validation.set_audience(&["your-api-audience"]);
    validation.required_spec_claims.insert("iss".to_string());
    validation.required_spec_claims.insert("aud".to_string());
    // Enforce algorithm to prevent algorithm confusion
    validation.alg = vec![Algorithm::RS256];

    let token_data = decode::(token, &decoding_key, &validation)?;
    Ok(token_data)
}

async fn admin_route(token: web::Header<actix_web_httpauth::headers::authorization::Bearer>) -> Result {
    match validate_jwt_rsa(token.token()).await {
        Ok(data) if data.claims.roles.contains(&"admin".to_string()) => {
            Ok(HttpResponse::Ok().json("Admin access granted"))
        }
        _ => Ok(HttpResponse::Forbidden().body("Insufficient permissions")),
    }
}

Best practices summary

• Always specify allowed algorithms and reject unsigned tokens (Algorithm::NONE).
• Validate issuer (iss), audience (aud), and expiration (exp) on every request.
• Use strong keys and rotate keys according to your security policy.
• Do not trust token headers that specify algorithms; enforce your own list.
• Leverage Actix extractors to centralize JWT validation and reuse across routes.

By combining strict JWT validation with continuous monitoring using tools that run the 12 security checks in parallel, you can detect integrity failures before they are exploited. The CLI tool can be integrated into development workflows to scan API endpoints and surface these issues early.