Race Condition in Axum with Mutual Tls

A race condition in an Axum application using Mutual TLS (mTLS) typically arises when server-side logic depends on the outcome of multiple, overlapping authorization checks or state updates that are not performed atomically. mTLS provides transport-layer identity verification by requiring clients to present a valid certificate. However, if the application performs certificate validation, retrieves identity information (such as subject or SANs), and then performs additional business logic checks in separate steps, an attacker can manipulate timing to bypass intended authorization.

Consider an endpoint that first verifies the client certificate, maps the certificate to an internal user or role, and then checks permissions against a database or cache. An attacker could cause the state used for permission checks to change between the certificate validation and the authorization lookup. For example, if certificate-to-user mapping relies on a cached or database lookup that can be modified concurrently (e.g., by an administrative API or a background process), a time-of-check-to-time-of-use (TOCTOU) scenario emerges. The race is not in the TLS handshake itself—mTLS ensures the client possesses a valid certificate—but in the application’s post-handshake authorization logic where identity-derived data is read and acted upon non-atomically.

In Axum, this can occur when handlers or extractors perform async operations such as fetching user permissions or refreshing cached roles after the TLS identity is established. If two requests interleave—where one updates the user’s role or permissions and the other proceeds to perform a sensitive operation based on stale data—the second request may execute with incorrect privileges. This is particularly relevant when mTLS is used to identify service accounts that have mutable permissions; the effective authorization decision becomes dependent on timing relative to updates elsewhere in the system.

Moreover, if Axum routes or middleware perform partial checks (e.g., verifying certificate presence and validity) and then later perform authorization via database queries, the window between these checks can be exploited. An attacker may trigger changes to the underlying authorization state (such as role revocation or permission updates) in a way that causes the in-flight request to be evaluated against an inconsistent state. Because mTLS binds identity to certificates rather than to mutable session data, developers might mistakenly assume authorization is stable, but without atomicity around identity-to-permission resolution, a race condition remains possible.

Real-world analogies include scenarios where service accounts are used: a certificate maps to a service identity, and permissions are stored in a configuration service or database. If the permissions are updated while a request is being processed, the outcome depends on timing. This maps to common OWASP API Top 10 categories such as Broken Object Level Authorization (BOLA) when object-level permissions are derived from mTLS identities and not validated atomically. Race conditions in this context do not break mTLS, but they undermine the authorization logic that relies on identity obtained through mTLS.

To mitigate race conditions in Axum with mTLS, ensure that identity extraction and authorization checks are performed atomically and that authorization data is not subject to concurrent modification during request processing. Prefer loading authorization data once per request and avoiding additional async state changes between identity validation and permission evaluation.

Below are concrete Axum code examples demonstrating a safe pattern.

1. Atomic identity extraction and authorization within a handler

In this approach, a custom extractor resolves the mTLS identity and immediately loads required authorization data in a single async block, ensuring no intervening state changes.

use axum::{routing::get, Router, async_trait};
use axum::extract::Extension;
use std::net::SocketAddr;
use tokio::sync::RwLock;
use std::sync::Arc;

// Mock authorization store protected by a lock for safe concurrent access.
#[derive(Clone)]
struct AuthStore(Arc

use axum::{routing::post, Router, Extension};
use std::sync::Arc;
use tokio::sync::RwLock;

async fn update_permissions(
    Extension(auth_store): Extension<Arc<RwLock<AuthState>>>,
    new_fingerprint: String,
    new_permissions: Vec<String>,
) -> 'static str {
    let mut state = auth_store.write().await;
    state.permissions.insert(new_fingerprint, new_permissions);
    "Updated"
}

// Reuse AuthState and AuthStore definitions from previous example.
// The protected handler remains unchanged and remains safe because it only reads.