Nosql Injection in Axum with Api Keys

Axum is a Rust web framework that encourages strongly typed extractors and composable routing. When API keys are handled as request parameters, headers, or query values and then passed into downstream logic without validation, they can become part of a data flow that reaches a NoSQL backend. If the key value is concatenated into a JSON or BSON query, used as a dynamic key in a document lookup, or interpolated into a MongoDB, CouchDB, or DynamoDB expression, an attacker can inject NoSQL-specific syntax that alters query semantics.

For example, consider an endpoint that retrieves user preferences using an API key extracted as a header. If the application builds a document filter by serializing the key into a JSON-like structure without sanitization, an attacker-supplied key such as {'$ne': null} can change the meaning of the query from equality to inequality, potentially returning records that should be hidden. In MongoDB, {'$where': 'this.password == \"" + userInput + "\"'} can lead to logic injection if the key is not validated. Similarly, in CouchDB, a key like {'$or': [{'_id': 'admin'}, {'_id': 'user'}]} can bypass intended access controls.

Because middleBrick scans unauthenticated attack surfaces, it can detect whether API key values are reflected in responses in a way that indicates they are being interpreted as query operators rather than opaque strings. Findings often highlight places where key-based routing or filtering passes untrusted input directly to the NoSQL driver. Remediation guidance typically centers on treating API keys as opaque identifiers, using parameterized queries or prepared statements where the driver supports them, and applying strict allowlist validation on key formats.

Secure handling of API keys in Axum requires treating them as untrusted input, avoiding string concatenation for NoSQL queries, and using framework features that encourage type-safe extraction. Below are concrete patterns that reduce the risk of NoSQL injection.

1. Use typed extractors and validate format

Define a wrapper type for the API key and validate it with a regex allowlist before using it in any backend call. This ensures the key cannot contain operators or nested documents.

use axum::{routing::get, Router, extract::State};
use serde::Deserialize;
use regex::Regex;
use std::net::SocketAddr;

#[derive(Clone)]
struct AppState {
    // Example NoSQL client, e.g., mongodb::Database
    db: String, // placeholder for actual client
}

#[derive(Debug, Deserialize)]
struct ApiKey(String);

impl ApiKey {
    fn from_str(s: &str) -> Option {
        let re = Regex::new(r"^[A-Za-z0-9\-_]{20,40}$").unwrap();
        if re.is_match(s) {
            Some(ApiKey(s.to_string()))
        } else {
            None
        }
    }
}

async fn handler(State(state): State, api_key: ApiKey) -> String {
    // Use the key as a parameter, not as part of a JSON structure
    format!("key validated: {}", api_key.0)
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/profile", get(handler))
        .with_state(AppState { db: "db_name".to_string() });

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

2. Avoid embedding keys in JSON/BSON structures used for queries

Instead of building a filter like { "$or": [ { "api_key": key } ] } via string interpolation, use a driver-supported parameter binding. If using MongoDB with the official Rust driver, prefer a filter constructed via the builder API, which treats values as data, not operators.

use mongodb::{bson::{doc, Document}, options::FindOptions};

async fn find_user(db: &mongodb::Database, user_key: &str) -> mongodb::error::Result> {
    // Correct: key is a value, not a query operator
    let filter = doc! { "api_key": user_key };
    let collection = db.collection("users");
    let opt = FindOptions::builder().limit(1).build();
    let mut cursor = collection.find(filter, opt).await?;
    cursor.next().await.transpose()
}

3. Reject suspicious patterns early

Add middleware that inspects the API key for common injection indicators such as $, . followed by operators, or bracket notation that maps to JSONPath-like expressions. Return a 400 before the key reaches the database layer.

use axum::{http::StatusCode, response::IntoResponse};

fn validate_key_no_injection(key: &str) -> Result<(), (StatusCode, String)> {
    let dangerous = ["$", ".", "[", "]"];
    for &d in &dangerous {
        if key.contains(d) {
            return Err((StatusCode::BAD_REQUEST, format!("Invalid key format")));
        }
    }
    Ok(())
}