Time Of Check Time Of Use in Actix with Bearer Tokens

Time Of Check Time Of Use (TOCTOU) occurs when the state used for a security decision changes between the check and the subsequent use. In Actix applications that rely on Bearer Tokens, TOCTOU can emerge when an authorization check validates a token or its claims (for example, scope or role) and later, within the same request, the handler uses a cached or previously retrieved resource without revalidating that the token still permits the action. Because Bearer Tokens are typically transmitted in the Authorization header and often cached in request extensions or application state for performance, an attacker who can influence the resource’s identity between check and use may exploit the gap.

Consider an endpoint that first verifies a token contains a specific scope, then retrieves an object ID from the URL and acts on it. If the authorization check does not re-assert that the token is bound to that specific object (for example, by validating ownership or tenant context at the moment of access), an attacker can modify the object ID between the scope check and the data operation. This is especially relevant in Actix when using extractor patterns that decouple validation from the handler. For example, a custom extractor may validate scopes and attach a user payload to the request, but the handler may trust the extracted user identifier without confirming that the token still maps to that identifier or that the target resource belongs to the same tenant. Because the check and the use are not atomic with respect to the token’s binding and the resource’s identity, the effective authorization decision can be stale.

In a black-box scan, middleBrick tests such patterns by submitting an OpenAPI/Swagger spec with $ref resolution and comparing runtime behavior against the declared security requirements. It checks whether authorization is performed immediately before the action and whether the token’s claims are re-evaluated against the resource being accessed. When Bearer Tokens are used, the scanner also verifies that sensitive endpoints do not rely on cached authorization decisions that can become inconsistent across concurrent requests or when parameters change. This helps surface TOCTOU-like conditions where a valid token at check time does not guarantee safe use at execution time, especially in cases involving per-request resource identifiers.

To mitigate TOCTOU in Actix with Bearer Tokens, ensure authorization checks are performed immediately before the operation on the exact resource, and avoid relying on cached decisions that can become stale. Prefer validating token claims against the resource in the same handler or within an atomic service call. Below are concrete code examples illustrating secure patterns.

Example 1: Direct validation in the handler

Validate the Bearer Token and resource ownership within the same async handler. This removes the gap between check and use by re-evaluating the token and resource identity atomically.

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

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    scope: String,
    // other claims
}

async fn get_item(
    req: HttpRequest,
    path: web::Path, // resource id, e.g., /items/{id}
) -> impl Responder {
    let token = match req.headers().get("authorization") {
        Some(h) => h.to_str().unwrap_or("").strip_prefix("Bearer ").unwrap_or(""),
        None => return HttpResponse::Unauthorized().finish(),
    };

    // Decode and validate token each time
    let decoded: TokenData = match decode::(
        token,
        &DecodingKey::from_secret("secret".as_ref()),
        &Validation::new(Algorithm::HS256),
    ) {
        Ok(t) => t,
        Err(_) => return HttpResponse::Unauthorized().finish(),
    };

    let item_id = path.into_inner();
    // Re-check that the token's subject or scope aligns with the requested resource
    if !is_authorized_for_item(&decoded.claims.sub, &item_id) {
        return HttpResponse::Forbidden().finish();
    }

    // Proceed with the operation using the validated token and resource id
    HttpResponse::Ok().body(format!("Accessing item {} for user {}", item_id, decoded.claims.sub))
}

fn is_authorized_for_item(user_id: &str, item_id: &str) -> bool {
    // Implement your data ownership check here, e.g., via a database lookup
    true
}

Example 2: Middleware with request-local revalidation

If you use a middleware or extractor to attach user info, ensure the handler revalidates critical decisions immediately before use, or avoid using the cached claim for sensitive operations. This pattern keeps checks close to the action.

use actix_web::{dev::ServiceRequest, Error, HttpResponse};
use actix_web_httpauth::extractors::bearer::BearerAuth;

async fn authorized_handler(bearer: BearerAuth) -> Result {
    // Do not rely on prior extraction for sensitive actions; re-extract or re-validate
    let token = bearer.token();
    // Perform per-request validation against your auth service or DB
    let is_valid = validate_token_for_current_request(token).await?;
    if !is_valid {
        return Err(actix_web::error::ErrorForbidden("invalid token binding"));
    }
    // Safe to proceed
    Ok(HttpResponse::Ok().body("Authorized"))
}

async fn validate_token_for_current_request(token: &str) -> Result {
    // Implement real validation logic, e.g., call auth service or verify scopes
    Ok(true)
}

General recommendations

• Always re-validate ownership or scope immediately before data access; avoid one-time checks stored in request extensions.
• Use short-lived Bearer Tokens and refresh strategies to reduce the window of inconsistency.
• When using middleware or extractors, ensure that any cached authorization data is either not used for critical decisions or is rechecked atomically with the operation.