Time Of Check Time Of Use in Actix with Basic Auth

Time Of Check Time Of Use (TOCTOU) occurs when the outcome of a security decision depends on the timing between a check and the subsequent use of a resource. In Actix web applications using HTTP Basic Auth, TOCTOU can manifest when authorization checks are performed separately from the actual resource access, creating a window where state can change in an uncontrolled way.

Consider an endpoint that first validates credentials and then determines what resource to act upon based on request parameters. With Basic Auth, the server validates the Authorization header and identifies a user, but if the handler uses unchecked parameters (e.g., a path variable or query parameter) to locate a resource, an attacker can manipulate the authorization boundary between the check and the use. Because Basic Auth is stateless and often cached per request, the credentials remain valid across the request lifecycle, but the resource identifier may be mutable. An attacker who can control the resource identifier might switch the target from one user’s data to another after the authentication check, effectively accessing data they should not see.

For example, an endpoint like /users/{user_id}/profile might authenticate the user via Basic Auth and then load the profile for user_id. If the handler does not re-assert that the authenticated user matches the user_id and instead trusts a client-supplied value, an attacker can change user_id to another user’s ID while still providing their own credentials. The authentication check passes, but the authorization binding between credentials and resource is not enforced at the moment of use, creating a privilege escalation or information disclosure path.

OpenAPI specifications that define Basic Auth security schemes can inadvertently encourage this pattern if they describe authentication separately from authorization rules tied to resource identifiers. When combined with dynamic route parameters, the unchecked use of user-controlled identifiers after a successful authentication check becomes a TOCTOU vector. This is especially relevant when the API design assumes that authentication alone is sufficient to enforce scope, rather than tying permissions directly to the resource at the moment of access.

In a black-box scan, middleBrick tests such flows by probing endpoints with different user credentials and manipulated resource identifiers to detect whether the authorization context remains consistent between authentication and resource use. This helps identify endpoints where TOCTOU-like behavior may expose data or enable horizontal privilege escalation without requiring authentication bypass.

To mitigate TOCTOU risks with Basic Auth in Actix, bind authentication and authorization tightly to the resource at the moment of use. Avoid separating credential validation from resource ownership checks, and ensure that every access decision re-evaluates the relationship between the authenticated identity and the target resource.

Instead of extracting a user identifier from the request and trusting it after authentication, derive the allowed resource scope directly from the authenticated identity. Use extractor state to carry the authenticated principal and enforce that any resource access matches that principal before performing operations.

The following example shows a secure Actix handler that avoids TOCTOU by ensuring the authenticated user matches the requested profile ID on every request. It uses web::Path to capture the identifier and compares it with the identity derived from Basic Auth before loading any data.

use actix_web::{web, HttpResponse, Error};
use actix_web::http::header::HeaderValue;
use actix_web::dev::ServiceRequest;
use actix_web_httpauth::extractors::basic::BasicAuth;

async fn get_profile(
    auth: BasicAuth,
    path: web::Path, // user_id from route
) -> Result {
    let authenticated_user = auth.user_id();
    let requested_user = path.into_inner();

    // Enforce that the authenticated user matches the requested resource
    if authenticated_user != requested_user {
        return Ok(HttpResponse::Forbidden().finish());
    }

    // Proceed with loading the profile for the authenticated user only
    // load_profile returns a Result
    match load_profile(&requested_user) {
        Ok(profile) => Ok(HttpResponse::Ok().json(profile)),
        Err(_) => Ok(HttpResponse::NotFound().finish()),
    }
}

In this pattern, the authentication extractor provides the identity, and the route parameter is validated against it before any data access. This eliminates the window where a stale check could be used to access a different resource.

For APIs that use path-based scoping, prefer embedding the authenticated identity into the route construction on the client side and verifying it server side without additional mutable identifiers. When using middleBrick’s CLI to scan Actix services with Basic Auth, it can highlight endpoints where authentication and resource identifiers are not consistently bound, pointing out potential TOCTOU conditions in the findings.

Additionally, leverage middleware or request guard patterns to attach the authenticated principal to the request extensions once, and then reuse that verified identity across all downstream handlers. This keeps the authorization context explicit and reduces the chance of inadvertently trusting unchecked input after the initial authentication check.