Prototype Pollution in Axum

Prototype pollution in Axum applications occurs when untrusted data flows through query parameters, JSON bodies, or form data and gets merged into Rust objects without proper sanitization. Unlike JavaScript where prototype pollution directly affects Object.prototype, Rust's ownership model prevents direct prototype manipulation, but similar vulnerabilities emerge through unsafe deserialization and dynamic object construction.

The most common attack vector in Axum is through the extract API when handling JSON payloads. Consider this vulnerable pattern:

use axum::extract::Json;
use serde_json::Value;

async fn handle_request(Json(payload): Json<Value>) -> String {
    // payload can contain __proto__ keys or nested objects
    // that get merged into internal structures
    process_payload(payload);
    "OK".to_string()
}

async fn main() {
    axum::Server::bind(&([127, 0, 0, 1], 3000).into())
        .serve(app.into_make_service())
        .await
        .unwrap();
}

The vulnerability arises when serde_json::Value accepts objects with keys that, when deserialized, can influence internal state. Attackers can craft payloads like:

{
  "__proto__": {
    "isAdmin": true
  },
  "user": {
    "id": 1,
    "permissions": "all"
  }
}

While Rust doesn't have JavaScript's prototype chain, similar issues occur when using serde_json::Value with dynamic field access or when integrating with JavaScript-based systems through WebAssembly or Node.js bindings. The pollution manifests as unexpected field injection into structs that use #[serde(flatten)] or dynamic deserialization.

Another Axum-specific pattern involves query parameter extraction:

use axum::extract::Query;

async fn search(Query(params): Query<HashMap<String, String>>) -> String {
    // params can contain malicious keys that affect internal logic
    let search = params.get("search").unwrap_or("");
    let admin_override = params.get("admin_override").unwrap_or("false");
    
    if admin_override == "true" {
        // unintended admin access
    }
    
    format!("Searching for: {}", search)
}

The core issue is treating all incoming data as trusted without validation. Axum's flexibility in accepting various content types makes it particularly vulnerable when developers use generic deserialization without strict schemas.

Detecting prototype pollution in Axum requires examining both the code patterns and runtime behavior. The most effective approach combines static analysis of your Axum handlers with dynamic scanning of running endpoints.

Static detection focuses on identifying risky code patterns:

use axum::extract::{Json, Query};
use serde_json::Value;
use std::collections::HashMap;

// Risky patterns to flag:
// 1. Generic Json<Value> without validation
// 2. #[serde(flatten)] on external data
// 3. Dynamic field access on deserialized data
// 4. HashMap<String, String> for query params without validation

// Safer alternatives:
#[derive(Deserialize)]
struct SafePayload {
    // Explicit fields only
    user_id: i32,
    action: String,
    // No #[serde(flatten)] or generic Value
}

async fn secure_handler(Json(payload): Json<SafePayload>) -> String {
    // Type-safe, no prototype pollution possible
    format!("User {} performed {}", payload.user_id, payload.action)
}

Dynamic scanning with middleBrick specifically tests for prototype pollution vulnerabilities by sending crafted payloads that attempt to inject unexpected fields and observing the application's response. middleBrick's black-box scanning approach tests the actual running API without requiring source code access.

middleBrick's prototype pollution detection includes:

• Testing JSON payloads with nested __proto__-style keys
• Attempting to inject fields into struct-like responses
• Checking for unexpected field propagation in error messages
• Verifying that type validation properly rejects malformed input
• Testing query parameter handling for injection patterns

The scanning process takes 5-15 seconds and provides a security risk score with specific findings about prototype pollution vulnerabilities, if present. For Axum applications, middleBrick examines the JSON deserialization patterns and identifies where generic Value types are used without proper validation.

Running middleBrick against your Axum API:

npx middlebrick scan https://your-axum-api.com/api/endpoint

The scan tests unauthenticated endpoints and provides findings with severity levels, helping you prioritize which prototype pollution vulnerabilities to fix first.

Remediating prototype pollution in Axum requires a defense-in-depth approach that combines strict type validation, input sanitization, and secure deserialization practices. The key principle is never to trust incoming data and always use explicit schemas.

The most effective remediation is replacing generic deserialization with strict typed structs:

// Vulnerable pattern - avoid this
async fn vulnerable_handler(Json(payload): Json<serde_json::Value>) -> String {
    // Any field can be injected
    "Vulnerable".to_string()
}

// Secure pattern - use explicit types
#[derive(Deserialize)]
struct UserPayload {
    user_id: i32,
    email: String,
    role: Role,
}

#[derive(Deserialize)]
#[serde(rename_all = "lowercase")]
enum Role {
    User,
    Admin,
    Moderator,
}

async fn secure_handler(Json(payload): Json<UserPayload>) -> String {
    // Only valid fields can be present
    // Type system prevents unexpected injection
    format!("Processing user {} with role {:?}", 
            payload.user_id, payload.role)
}

For query parameters, avoid using generic HashMaps and instead define explicit structs:

// Vulnerable
async fn search(Query(params): Query<HashMap<String, String>>) -> String {
    // Any parameter can be injected
    "Vulnerable search".to_string()
}

// Secure
#[derive(Deserialize)]
struct SearchParams {
    query: String,
    page: Option<u32>,
    per_page: Option<u32>,
}

async fn secure_search(Query(params): Query<SearchParams>) -> String {
    // Only expected parameters are accepted
    format!("Searching for: {} (page {})", 
            params.query, params.page.unwrap_or(1))
}

When you must handle dynamic data, implement strict validation:

use serde_json::Value;
use serde::Deserialize;

async fn dynamic_handler(Json(payload): Json<Value>) -> String {
    // Validate structure before processing
    if let Ok(valid) = validate_payload(&payload) {
        process_valid_payload(valid);
        "OK".to_string()
    } else {
        // Reject invalid input
        axum::response::Response::builder()
            .status(400)
            .body("Invalid payload").unwrap()
    }
}

#[derive(Deserialize)]
struct ValidatedPayload {
    user_id: i32,
    action: String,
    metadata: HashMap<String, String>,
}

fn validate_payload(value: &Value) -> Result<ValidatedPayload, serde_json::Error> {
    // Only allow expected fields
    serde_json::from_value(value.clone())
}

Additional security measures include:

• Using #[serde(deny_unknown_fields)] to reject unexpected fields
• Implementing strict content-type validation
• Setting maximum payload sizes to prevent DoS
• Using Axum's built-in validation middleware for common patterns

These remediation strategies eliminate the attack surface for prototype pollution while maintaining Axum's flexibility for legitimate use cases.