Excessive Data Exposure in Axum with Cockroachdb

Excessive Data Exposure occurs when an API returns more data than necessary for a given operation. In Axum applications using Cockroachdb as the backend, this commonly manifests through endpoints that fetch full database rows and serialize them directly into JSON responses without field filtering. Because Axum does not enforce output schemas by default, developers may inadvertently expose sensitive columns such as internal identifiers, password hashes, audit timestamps, or tenant-specific fields when querying Cockroachdb tables that contain personally identifiable information (PII) or operational metadata.

When a GET handler deserializes a Cockroachdb row into a struct with broad field coverage, the serialization step will include every mapped column present in the query result. If the handler does not explicitly exclude sensitive fields using selective serialization or projection, the HTTP response body will contain those fields. This becomes a critical exposure when the endpoint lacks proper authorization checks, allowing one user to request another user's record by manipulating identifiers and receive data belonging to a different tenant or role. Axum’s extractor and guard mechanisms do not automatically enforce row-level permissions; developers must implement explicit checks and field selection to avoid leaking data across authorization boundaries.

The combination of Axum’s flexible routing and Cockroachdb’s schemaless JSON capabilities increases risk if developers rely on ORM-level automatic field inclusion. For example, a route that calls SELECT * FROM profiles and maps rows into a struct with exported fields will serialize all columns, including internal flags or session tokens, to the client. Without query-time column restriction or post-processing redaction, the API response may include sensitive attributes that should remain internal. This pattern is common during early development when data models are fluid and security reviews focus primarily on authentication rather than output validation.

middleBrick detects Excessive Data Exposure by comparing the OpenAPI schema’s defined response models with actual runtime outputs from Axum endpoints backed by Cockroachdb. It identifies responses that include fields not declared in the spec or that return entire table rows without projection. The scanner flags scenarios where sensitive fields such as password_hash, reset_token, or tenant_internal_id appear in serialized responses, especially when no authorization filter limits the returned rows. These findings align with OWASP API Top 10 A01:2023 broken object level authorization and data exposure risks, and they can map to compliance frameworks including PCI-DSS and GDPR where PII leakage is regulated.

Remediation focuses on explicit field selection, schema design, and runtime output validation. Developers should define focused response structs that include only necessary fields and apply database-level projections using Cockroachdb column selection. Axum handlers must enforce tenant-aware authorization before querying and ensure that serialized structures do not contain sensitive or internal attributes. Continuous scanning with tools that support OpenAPI spec analysis and runtime comparison, such as the middleBrick Pro plan with continuous monitoring, helps detect regressions and enforce that Axum routes backed by Cockroachdb adhere to least-privilege data exposure principles.

To remediate Excessive Data Exposure in Axum with Cockroachdb, replace generic row fetching with explicit column selection and strict response structs. This ensures only intended data fields are serialized and sent to the client. Below are concrete code examples that demonstrate secure patterns for querying Cockroachdb and mapping results in Axum handlers.

First, define a minimal response structure that includes only safe, public fields:

#[derive(serde::Serialize)]
struct PublicProfile {
    user_id: i64,
    display_name: String,
    email: String,
}

Next, construct SQL queries that select only the required columns rather than using SELECT *. Use Cockroachdb’s native column list to limit exposure:

async fn get_public_profile(
    conn: &cockroachdb_client::SimpleConnection,
    user_id: i64,
    requester_id: i64,
) -> Result<PublicProfile, ApiError> {
    // Ensure tenant and authorization checks before querying
    if !is_same_tenant_or_authorized(conn, user_id, requester_id).await? {
        return Err(ApiError::forbidden());
    }
    let row = conn
        .query_one(
            "SELECT user_id, display_name, email FROM profiles WHERE user_id = $1",
            &[&user_id],
        )
        .await
        .map_err(|e| ApiError::internal(e.to_string()))?;
    Ok(PublicProfile {
        user_id: row.get(0),
        display_name: row.get(1),
        email: row.get(2),
    })
}

This approach prevents sensitive columns such as password_hash or reset_token from being selected or serialized. In cases where a broader set of safe fields is needed, define a struct that omits internal columns and use Cockroachdb’s column aliasing to enforce naming consistency:

async fn list_user_sessions(
    conn: &cockroachdb_client::SimpleConnection,
    user_id: i64,
) -> Result<Vec<SessionInfo>, ApiError> {
    let rows = conn
        .query(
            "SELECT session_id, created_at, expires_at FROM user_sessions WHERE user_id = $1",
            &[&user_id],
        )
        .await
        .map_err(|e| ApiError::internal(e.to_string()))?;
    let sessions = rows
        .iter()
        .map(|row| SessionInfo {
            session_id: row.get(0),
            created_at: row.get(1),
            expires_at: row.get(2),
        })
        .collect();
    Ok(sessions)
}

#[derive(serde::Serialize)]
struct SessionInfo {
    session_id: String,
    created_at: chrono::DateTime<chrono::Utc>,
    expires_at: chrono::DateTime<chrono::Utc>,
}

Additionally, apply middleware or extractor-level checks in Axum to validate that the requesting user is authorized to access the targeted resource before the handler executes a Cockroachdb query. This reduces the likelihood of IDOR-related exposure even if a developer mistakenly broadens query columns. Combine these practices with schema reviews and automated scanning using middleBrick’s CLI tool to verify that Axum endpoints backed by Cockroachdb do not return excessive fields in production-like environments.