Pii Leakage in Axum

Detecting PII leakage in Axum applications requires examining both the code structure and runtime behavior. The primary detection method involves analyzing how data flows through extractors and response handlers. middleBrick's black-box scanning approach is particularly effective for Axum APIs since it tests the actual endpoints without requiring source code access.

Key detection patterns for Axum-specific PII leakage:

• Response serialization of structs with sensitive fields - middleBrick identifies endpoints that return entire structs without field filtering
• Query parameter extraction - scanning tests endpoints with PII-like values in query strings to see if they're reflected in responses
• JSON body extraction - testing POST endpoints with PII payloads to verify they're not logged or returned
• Path parameter usage - checking if user identifiers in paths lead to PII exposure

Using middleBrick's CLI to scan an Axum API:

npx middlebrick scan https://api.example.com/users

The scanner tests 12 security categories including Property Authorization (checking if authenticated users can access others' data) and Data Exposure (verifying PII isn't returned in responses). For Axum applications, middleBrick specifically looks for:

• Structs derived with Serialize that contain PII fields being returned directly
• Extractors that capture entire request bodies without validation
• Middleware that logs request data without filtering

middleBrick's OpenAPI analysis is particularly useful for Axum apps using tower-web or similar frameworks that generate OpenAPI specs. The scanner cross-references spec definitions with actual endpoint behavior to identify mismatches between documented and actual data exposure.

Manual code review detection for Axum PII leakage should focus on:

// Red flags in Axum code
#[derive(Serialize)] // Check if this struct contains PII fields
struct UserProfile {
    id: i32,
    email: String, // PII
    phone: String, // PII
    ssn: String,   // Highly sensitive PII
}

async fn get_profile(user_id: u32) -> Json {
    let profile = get_user_profile(user_id).await?;
    Json(profile) // Direct serialization exposes all fields
}

Remediating PII leakage in Axum requires a multi-layered approach using Axum's native features and Rust's type system. The most effective strategy is implementing explicit data filtering before serialization.

DTO (Data Transfer Object) pattern for Axum:

use axum::extract::Json;
use serde::Serialize;

#[derive(Serialize)]
struct UserProfileResponse {
    id: i32,
    name: String,
    // Explicitly exclude PII fields
}

#[derive(Deserialize)]
struct UserProfile {
    id: i32,
    name: String,
    email: String, // PII - not in response
    phone: String, // PII - not in response
    ssn: String,   // Highly sensitive PII - not in response
}

async fn get_user_profile(
    user_id: u32,
    Json(_): Json<()>, // For POST endpoints
) -> Json {
    let user = get_user_from_db(user_id).await?;
    let response = UserProfileResponse {
        id: user.id,
        name: user.name,
    };
    Json(response) // Only safe fields returned
}

Middleware filtering for PII in logs:

use axum::middleware::Next;
use axum::http::{Request, Response};
use axum::http::header::HeaderName;

async fn pii_filtering_middleware(mut req: Request, next: Next) -> Result {
    // Remove sensitive headers
    let sensitive_headers = [
        "authorization",
        "cookie",
        "x-api-key",
    ];
    
    for header in sensitive_headers {
        if let Ok(name) = HeaderName::from_bytes(header.as_bytes()) {
            req.headers_mut().remove(name);
        }
    }
    
    // Filter PII from request body (for JSON requests)
    let filtered_req = req.map_body(|_mime, body| {
        // In production, implement actual PII filtering logic
        // This is a placeholder for demonstration
        body
    });
    
    let res = next.run(filtered_req).await;
    res
}

use axum::{routing, Router};
use axum::http::StatusCode;
use axum::response::IntoResponse;
use axum::extract::Path;

async fn get_user_sensitive_data(
    Path(user_id): Path,
) -> impl IntoResponse {
    // Validate user has permission to access this data
    if !has_access_permission(user_id).await {
        return (StatusCode::FORBIDDEN, "Access denied");
    }
    
    let data = get_sensitive_data(user_id).await?;
    
    // Filter PII before returning
    let filtered_data = filter_pii(&data);
    
    axum::Json(filtered_data)
}

fn filter_pii(data: &UserData) -> FilteredData {
    FilteredData {
        id: data.id,
        name: data.name.clone(),
        // Explicitly exclude PII fields
    }
}

use axum::extract::Query;
use serde::Deserialize;

#[derive(Deserialize)]
struct SearchQuery {
    query: String,
    page: Option,
    // Avoid PII in query parameters when possible
}

async fn search_users(
    Query(params): Query,
) -> Json> {
    // Validate query doesn't contain PII
    if contains_pii(¶ms.query) {
        return Json(vec![]); // Or return error
    }
    
    let results = search_users_in_db(¶ms).await?;
    let filtered_results: Vec = results
        .into_iter()
        .map(|user| UserProfileResponse {
            id: user.id,
            name: user.name,
        })
        .collect();
    
    Json(filtered_results)
}