Excessive Data Exposure in Axum with Mutual Tls

Excessive Data Exposure occurs when an API returns more data than the client needs, often including sensitive fields that should remain internal. In Axum, combining Mutual Transport Layer Security (mTLS) with poorly scoped responses can still lead to exposure of unnecessary data fields, because mTLS primarily authenticates and encrypts the transport but does not limit what the application returns. An authenticated client with a valid client certificate may receive full database records, debug fields, or internal identifiers that should be filtered out before serialization.

Consider an Axum handler that retrieves a user profile and returns the entire domain model directly. Even with mTLS ensuring that only clients presenting a trusted certificate can connect, the response may include fields such as password_hash, internal_id, or audit_log. If the client application does not require these, exposing them increases the risk of data leakage if the response is intercepted elsewhere or mishandled by the client.

Real-world examples include APIs that return complete ORM entities (e.g., using serde to serialize a Diesel model) without selecting only required columns. For instance, a route like GET /api/users/{id} might serialize a User struct containing sensitive information. OWASP API Top 10 categorizes this as an API1:2023 — Broken Object Level Authorization when combined with IDOR-like exposure, and it maps to findings in the Property Authorization and Data Exposure checks run by middleBrick. The scanner tests whether authenticated endpoints (including those requiring mTLS client certificates) return only the minimal necessary data and flags responses containing credentials or internal references.

In practice, mTLS ensures that both client and server validate certificates before the HTTP request proceeds, which prevents unauthenticated access but does not automatically validate the content of the response. Therefore, developers must explicitly design response shapes, using dedicated serializable structs or selective serialization, to avoid leaking data. middleBrick’s OpenAPI/Swagger analysis cross-references spec definitions with runtime findings to highlight mismatches between declared responses and expected data exposure, helping teams identify endpoints where authentication (including mTLS) coexists with excessive data exposure.

To remediate excessive data exposure in Axum while using Mutual TLS, focus on minimizing the data returned to authenticated clients and ensuring that only necessary fields are serialized. Define separate response structs that exclude sensitive fields, and map domain models to these structs before serialization. This ensures that even when a client certificate proves identity, the payload remains minimal and safe.

Below are concrete Axum code examples demonstrating secure handling with mTLS context and selective serialization.

Minimal response struct with mTLS-aware handler

use axum::extract::State;
use serde::Serialize;
use std::sync::Arc;

// Minimal, client-facing response
#[derive(Serialize)]
struct UserProfileResponse {
    user_id: u64,
    username: String,
    email: String,
}

// Domain model (may contain sensitive fields)
struct User {
    id: u64,
    username: String,
    email: String,
    password_hash: String,
    internal_notes: String,
}

async fn get_user_profile(
    State(user_repo): State>,
    // mTLS identity available via extensions (populated by your TLS layer)
    Extension(certs): Extension>,
) -> Result, (StatusCode, String)> {
    let user_id = /* extracted from path or claims */;
    let user = user_repo.find_by_id(user_id).ok_or_else(|| (StatusCode::NOT_FOUND, "not found"))?;

    // Map to minimal response, excluding sensitive data
    let response = UserProfileResponse {
        user_id: user.id,
        username: user.username,
        email: user.email,
    };
    Ok(Json(response))
}

Selectively serialize with serde

use serde::{Serialize, Deserialize};

// Internal full model for server-side use
#[derive(Debug, Deserialize)]
struct InternalUser {
    id: u64,
    username: String,
    email: String,
    #[serde(skip_serializing)]
    password_hash: String,
    #[serde(skip_serializing)]
    api_key: String,
}

// Public model for responses
#[derive(Serialize)]
struct PublicUser {
    id: u64,
    username: String,
    email: String,
}

impl From for PublicUser {
    fn from(u: InternalUser) -> Self {
        PublicUser {
            id: u.id,
            username: u.username,
            email: u.email,
        }
    }
}

In these examples, mTLS is handled at the transport layer by your Axum server (e.g., via hyper with rustls), and the application layer focuses on data minimization. The server validates client certificates before processing the request, while the response struct ensures that fields like password_hash or api_key are never serialized. middleBrick’s CLI can be used to verify that endpoints using such patterns do not expose excessive data by running middlebrick scan <url> and reviewing the Data Exposure and Property Authorization findings.

Additionally, the GitHub Action can enforce that new endpoints adhere to this practice by failing builds if scans detect exposed sensitive fields in authenticated routes. For ongoing assurance, the Pro plan’s continuous monitoring can track changes in data exposure over time, and the MCP Server allows you to scan APIs directly from your AI coding assistant during development.