Missing Authentication in Actix with Jwt Tokens

When JWT tokens are implemented inconsistently or are omitted from selected Actix endpoints, the API can expose functionality to unauthenticated actors. This specific combination—Actix web framework plus JWT-based authorization—creates risk when token validation is skipped, conditional, or bypassed for certain routes. For example, if an Actix service uses a guard or wrapper to verify JWTs on most handlers but fails to apply it to newly added or legacy paths, authentication is effectively missing for those paths even though tokens are required elsewhere.

In a black-box scan, middleBrick tests unauthenticated access to endpoints that should require a valid JWT. It attempts requests without tokens and with malformed tokens to determine whether the endpoint enforces verification. A common root cause is route-level omission: the developer applies middleware to the application or a scope, but a subset of routes are defined outside that scope or are added after the middleware configuration is established. Another cause is conditional logic that skips verification based on request attributes (e.g., header presence, path prefix), which can be exploited by an attacker who crafts a request that bypasses checks.

Consider an Actix service where JWT verification is applied to admin routes via a wrapper, but a public data endpoint is added without the wrapper. An attacker can call the public endpoint without credentials and obtain data that should be restricted. Even when tokens are present, missing validation steps—such as not verifying the signature, not checking the issuer (iss), or not validating expiration (exp)—can allow any string to act as a valid token. middleBrick’s authentication checks include submitting requests without credentials and with intentionally malformed JWTs to confirm that the server rejects unauthorized access consistently.

Developers sometimes rely on framework defaults or partial middleware setups, assuming that adding JWT support once secures the entire surface. In Actix, this is not sufficient; each route or scope must explicitly enforce verification. The framework provides mechanisms such as guards, middleware, and extractors, but it is the developer’s responsibility to ensure they are applied uniformly. A missing authentication finding in this context indicates that the unauthenticated attack surface is larger than intended and that tokens are not being enforced as the source of truth for access control.

To illustrate, an insecure Actix route might look like a standard handler with no guard, while a protected route uses a JWT extractor that returns a 401 on failure. If the insecure route is inadvertently exposed, the API grants access without validating the token. middleBrick correlates findings across the OpenAPI specification—resolving $ref definitions and comparing declared security requirements with runtime behavior—to highlight discrepancies between documented authentication expectations and actual implementation.

Remediation focuses on ensuring every route that handles sensitive operations enforces JWT validation before processing business logic. In Actix, this means consistently applying authentication guards or middleware to all relevant endpoints, verifying token signatures and claims, and returning appropriate HTTP status codes for missing or invalid tokens. Below are concrete code examples demonstrating secure patterns.

Enforce JWT verification on all sensitive routes

Define a guard or middleware that validates the Authorization header, extracts the token, verifies its signature using a trusted algorithm and key, and checks standard claims such as exp and iss. Apply this guard to every handler that requires authentication. Never define routes that bypass the guard.

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

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

async fn validate_jwt(auth: BearerAuth) -> Result, actix_web::Error> {
    let token = auth.token();
    let decoded = decode::(
        token,
        &DecodingKey::from_secret("YOUR_SECRET_KEY".as_ref()),
        &Validation::new(Algorithm::HS256),
    )
    .map_err(|_| actix_web::error::ErrorUnauthorized("Invalid token"))?;
    // Additional checks: verify issuer, expiration, and custom claims here if needed
    Ok(decoded)
}

async fn admin_handler(_claims: web::ReqData>) -> impl Responder {
    HttpResponse::Ok().body("Admin data")
}

async fn public_handler() -> impl Responder {
    HttpResponse::Ok().body("Public data")
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            // Apply JWT validation only where needed; do not define unprotected sensitive routes
            .service(
                web::resource("/admin")
                    .route(web::get().to(admin_handler))
                    .wrap_fn(|req, srv| {
                        let auth_result = validate_jwt(req.extract::().unwrap());
                        async move {
                            match auth_result.await {
                                Ok(token_data) => {
                                    req.extensions_mut().insert(token_data);
                                    srv.call(req).await
                                }
                                Err(e) => Err(e),
                            }
                        }
                    }),
            )
            .service(web::resource("/public").to(public_handler))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

Centralize authentication logic and validate claims

Use a centralized extractor or middleware to avoid duplicating validation logic. Ensure the validation includes signature verification and claim checks (exp, nbf, iss, aud). This reduces the risk of accidentally omitting checks on new routes.

use actix_web::{dev::ServiceRequest, dev::ServiceResponse, Error, HttpMessage};
use actix_web::middleware::Next;
use actix_web::http::header::HeaderValue;
use actix_web::body::BoxBody;
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation, TokenData};

async fn auth_middleware(
    req: ServiceRequest,
    next: Next,
) -> Result, Error> {
    let auth_header = req.headers().get("Authorization");
    match auth_header {
        Some(header_val) => {
            if let Ok(auth_str) = header_val.to_str() {
                if let Some(token) = auth_str.strip_prefix("Bearer ") {
                    let decoded = decode::(
                        token,
                        &DecodingKey::from_secret("YOUR_SECRET_KEY".as_ref()),
                        &Validation::new(Algorithm::HS256),
                    );
                    if decoded.is_ok() {
                        return next.call(req).await;
                    }
                }
            }
            Err(actix_web::error::ErrorUnauthorized("Missing or invalid token"))
        }
        None => Err(actix_web::error::ErrorUnauthorized("Authorization header missing")),
    }
}

// In your App configuration:
// .wrap_fn(|req, next| auth_middleware(req, next))

Return consistent error responses and avoid information leakage

Ensure that error responses for missing or invalid JWTs do not reveal internal details. Use a uniform 401 status code and avoid differentiating between "token missing" and "token invalid" in a way that leaks which part failed. This prevents attackers from inferring endpoint behavior based on error messages.

// Example: return a generic unauthorized response
async fn handle_unauthorized() -> actix_web::Result {
    Ok(HttpResponse::Unauthorized().json(serde_json::json!({
        "error": "Unauthorized"
    })))
}

When integrating with identity providers, verify tokens with the expected algorithm and key, and reject tokens that do not meet the expected claims. middleBrick can validate that your implementation consistently requires authentication and does not allow unauthenticated access to protected endpoints.