Graphql Batching in Axum (Rust)

GraphQL batching allows a client to send multiple queries or mutations in a single HTTP request. In Axum with Rust, this typically means accepting a JSON payload containing an array of operations and executing them sequentially or in parallel within an async runtime. While convenient, batching can amplify injection and authorization risks.

Each operation in the batch is parsed and planned independently. If authorization checks are performed only at the handler level rather than per-operation, a malicious batch can include operations that reference other users' resources. Because batching defers individual operation validation until execution, a BOLA/IDOR flaw in one operation can be masked by benign-looking requests in the same batch. Input validation issues in one query can also affect subsequent operations if error handling is inconsistent.

Rate limiting becomes more complex because a single request can consume significant server time and database connections. Without per-operation rate controls, a batched payload with many expensive queries can degrade service or bypass limits intended for single operations. Data exposure risks increase when responses for different operations are combined; sensitive fields might be included in one operation’s response and inadvertently returned alongside other operations, violating the principle of least privilege.

In an unauthenticated context, if batching is allowed without proper guardrails, it can expose endpoints that should require authentication. A batch containing both authenticated and unauthenticated operations may be processed depending on server configuration, leading to inconsistent enforcement. Additionally, complex batching logic can introduce parsing ambiguities or deep nesting that may be exploited for SSRF or excessive agency when the server attempts to resolve references across operations.

Because middleBrick tests unauthenticated attack surfaces, a batched endpoint that does not enforce authentication on every operation could receive a low score. The scanner’s checks for Input Validation, BOLA/IDOR, Rate Limiting, and Data Exposure will flag inconsistencies in how each operation within a batch is handled, highlighting where per-operation controls are missing.

To secure GraphQL batching in Axum, enforce authorization and validation at the operation level, not the batch level. Use strong typing for operations, avoid dynamic field selection where possible, and ensure each operation is validated before execution.

Below are concrete Rust examples using Axum and async_graphql.

1. Define operation-specific authorization and input validation

Create a struct for each operation type and validate inputs before passing to resolvers. This ensures that every operation in a batch is checked independently.

use async_graphql::{Context, Object, Result, SimpleObject};
use serde::{Deserialize, Serialize};
use axum::{routing::post, Json, Router};
use std::sync::Arc;

#[derive(SimpleObject)]
struct User {
    id: String,
    name: String,
    // Sensitive fields should be omitted unless explicitly permitted
}

#[derive(Deserialize)]
struct GetUserInput {
    user_id: String,
}

struct Query;

#[Object]
impl Query {
    async fn get_user(&self, ctx: &Context<'_>, user_id: String) -> Result {
        let auth_user_id = ctx.data::()?; // authenticated user ID from request extensions
        if auth_user_id != user_id {
            return Err(async_graphql::Error::new("Unauthorized"));
        }
        // fetch user safely
        Ok(User { id: user_id, name: "Alice".to_string() })
    }
}

async fn graphql_handler(
    Json(payload): Json,
    ctx: axum::extract::Extension>>>,
) -> Json {
    let schema = ctx.lock().unwrap();
    let mut response = GraphQlResponse::default();
    for op in payload.operations {
        let result = schema.execute(op.query).await;
        response.results.push(result);
    }
    Json(response)
}

#[derive(Deserialize)]
struct GraphQlRequest {
    operations: Vec,
}

struct GraphQlOperation {
    query: String,
    variables: Option,
}

#[derive(Serialize)]
struct GraphQlResponse {
    results: Vec,
}

2. Enforce per-operation authentication and authorization

Use Axum extractors to attach the authenticated user to the request extensions, and ensure each GraphQL resolver validates access rights. For batch operations, iterate and check individually.

use axum::extract::Extension;
use std::sync::Arc;

async fn batch_handler_with_auth(
    Extension(tenant_id): Extension,
    Json(payload): Json,
) -> Json {
    let mut results = Vec::new();
    for op in payload.operations {
        // Validate tenant scope per operation
        let validated_id = validate_tenant(&op, &tenant_id)?;
        let ctx = Context::new().data(tenant_id.clone());
        let result = execute_single_operation(&ctx, &validated_id, op).await;
        results.push(result);
    }
    Json(GraphQlResponse { results })
}

fn validate_tenant(op: &GraphQlOperation, tenant_id: &str) -> Result {
    // Ensure operation references only tenant-owned resources
    if op.query.contains("other_tenant") {
        return Err(GraphQlError::Forbidden);
    }
    Ok(tenant_id.to_string())
}

3. Apply rate limiting and size controls at the HTTP layer

Use Axum middleware or a reverse proxy to limit request size and number of operations per batch. This prevents resource exhaustion from large batched payloads.

// Example using tower-http for size and rate limiting
use tower_http::limits::{RequestBodyLimitLayer, ResponseSizeLimitLayer};
use tower_http::ratelimit::{RateLimitLayer, MemoryStore};

let app = Router::new()
    .route("/graphql", post(graphql_handler))
    .layer(RequestBodyLimitLayer::new(1024 * 64)) // 64 KB max body
    .layer(ResponseSizeLimitLayer::new(1024 * 1024)) // 1 MB max response
    .layer(RateLimitLayer::new(MemoryStore::new(), 10, 1)); // 10 requests per window

These steps ensure that batching does not weaken authorization, validation, or rate controls. Security findings from middleBrick will highlight where per-operation checks are missing or inconsistent, guiding focused fixes.