Graphql Batching in Actix (Rust)

GraphQL batching allows clients to send multiple operations in a single request. In Actix with Rust, this is typically implemented by accepting a JSON array of GraphQL request objects and processing them sequentially or in parallel. Because each operation may perform database lookups, authorization checks, or external calls, batching can amplify impact in two ways:

• Amplified attack surface per request: A single batch can trigger many operations, increasing the potential for excessive data exposure, unauthorized reads/writes, or resource exhaustion. If batching is implemented without strict per-operation limits, an attacker can issue many queries or mutations in one round-trip.
• Complexity in authorization and input validation: Each item in the batch must be validated and authorized independently. Missing or inconsistent checks across items can lead to BOLA/IDOR or privilege escalation within the batch, especially when items reference different resources or the same resource with different parameters.

In an unauthenticated or partially authenticated Actix GraphQL endpoint, batching can worsen an insecure default posture. For example, if the server resolves each operation with the same per-request context (e.g., one shared DataLoader or a single parent guard), it may inadvertently allow one malicious operation to affect others. Additionally, batching can interact poorly with rate limiting: a single batch may bypass per-request thresholds if limits are applied only at the HTTP request level rather than per GraphQL operation within the batch.

Real-world patterns that increase risk include:

• Allowing arbitrary queries in batch without cost or depth checks, enabling cost exploitation or denial-of-service via complex nested resolvers.
• Using a single DataLoader key across batch items without proper scoping, which can cause data leaks between operations (a BOLA/IDOR vector).
• Insufficient input validation on batch-level fields (e.g., missing operation name or variable sanitization), which may enable SSRF or injection when variables are merged or reused across items.

Because GraphQL batching is not part of the core specification, implementations vary. Actix services that accept POST bodies with an array of request objects must treat each element as an independent operation and enforce the same security checks applied to single queries/mutations. This includes per-operation authentication, strict input validation, scoped DataLoader usage, and operation-level limits to prevent abuse.

To secure GraphQL batching in Actix with Rust, enforce per-operation validation, scoped data loading, and explicit limits. Below are concrete, idiomatic patterns you can apply.

1. Validate and authorize each operation independently

Do not reuse a single authorization decision across batch items. Parse and validate each operation separately, and apply authentication and per-operation checks before execution.

use actix_web::{post, web, HttpRequest, HttpResponse, Responder};
use async_graphql::{Request, Schema};
use serde::{Deserialize, Serialize};

#[derive(Deserialize, Serialize)]
struct BatchItem {
    query: String,
    operation_name: Option,
    variables: Option,
}

async fn validate_and_run_item(
    req: &HttpRequest,
    item: &BatchItem,
    schema: &Schema,
) -> Result {
    // Example: require authentication token for every item
    let token = req.headers().get("Authorization")
        .and_tap(|v| v.to_str().ok())
        .ok_or("Missing Authorization header")?;
    // Perform per-item authz checks here (e.g., scope validation)
    let request = Request::new(item.query.clone()).variables(item.variables.clone().unwrap_or_default());
    let res = schema.execute(request).await;
    if res.errors.is_empty() {
        Ok(res.data)
    } else {
        Err(format!("GraphQL errors: {:?}", res.errors))
    }
}

#[post("/graphql/batch")]
async fn graphql_batch(
    req: HttpRequest,
    body: web::Json>,
    schema: web::Data,
) -> impl Responder {
    // Enforce a reasonable batch size limit to prevent resource exhaustion
    const MAX_BATCH_SIZE: usize = 10;
    if body.len() > MAX_BATCH_SIZE {
        return HttpResponse::BadRequest().json(serde_json::json!({"error": "Batch size exceeds limit"}));
    }

    let mut results = Vec::with_capacity(body.len());
    for item in body.iter() {
        match validate_and_run_item(&req, item, &schema).await {
            Ok(data) => results.push(serde_json::to_value(data).unwrap_or_default()),
            Err(e) => results.push(serde_json::json!({ "error": e })),
        }
    }
    HttpResponse::Ok().json(serde_json::json!({ "results": results }))
}

2. Scope DataLoader instances per operation

When using DataLoader for batching database lookups, ensure each operation gets its own scoped DataLoader or a key that includes the operation context (e.g., tenant ID or user ID) to prevent cross-item data leakage.

use async_graphql::{dataloader::DataLoader, EmptyMutation, EmptySubscription, Object, Schema};
use std::collections::HashSet;

struct UserLoader { /* ... */ }
impl UserLoader {
    async fn load(&self, user_ids: HashSet) -> Vec<(i32, String)> {
        // Simulated DB lookup
        user_ids.into_iter().map(|id| (id, format!("user_{}", id))).collect()
    }
}

struct QueryRoot;
#[Object]
impl QueryRoot {
    async fn user(&self, ctx: &Context<'_>, id: i32) -> String {
        let loader = ctx.data::>().unwrap();
        let users = loader.load_one(id).await.unwrap_or_default();
        users.1
    }
}

// In your Actix handler, create a fresh DataLoader per request to ensure scoping
async fn scoped_graphql_batch(
    req: HttpRequest,
    body: web::Json>,
    schema: web::Data>,
) -> impl Responder {
    for item in body.iter() {
        let loader = DataLoader::::new(/* context with request-scoped config */);
        let ctx = /* build context containing loader */;
        let request = Request::new(item.query.clone()).variables(item.variables.clone().unwrap_or_default());
        let _ = schema.execute_with_context(request, ctx).await;
    }
    HttpResponse::Ok().finish()
}

3. Apply operation-level limits and input sanitization

Limit query depth, complexity, and execution time per operation within the batch. Validate and sanitize variables to prevent SSRF or injection when variables are reused across items.

use async_graphql::{extensions::Tracing, Request};

fn build_request(item: &BatchItem) -> Result {
    let mut req = Request::new(item.query.clone());
    if let Some(vars) = &item.variables {
        // Example: ensure variables do not contain unexpected keys
        if vars.as_object().map_or(false, |o| o.contains_key("malicious")) {
            return Err("Invalid variable keys".into());
        }
        req = req.variables(vars.clone());
    }
    // Enforce depth/complexity limits via extensions or custom validation before execution
    req = req.extension(Tracing);
    Ok(req)
}

By treating each batch item as an independent operation and scoping data loading, you reduce the risk of BOLA/IDOR, privilege escalation via batch abuse, and unintended data exposure across items in Actix with Rust.