Graphql Batching in Aspnet (Csharp)

GraphQL batching in an ASP.NET context typically involves sending multiple GraphQL operations in a single HTTP request. When implemented without strict controls, this pattern can amplify common API risks such as injection, excessive data exposure, and inefficient resource consumption. In C#, developers often use libraries that allow parsing a batch payload, iterating over individual operations, and executing them sequentially or in parallel. This flow can unintentionally enlarge the attack surface if input validation is inconsistent across operations or if the server does not enforce per-operation limits.

Because GraphQL queries are expressed as strings and resolved dynamically, batching can interact poorly with schema design and authorization logic. For example, a batch may include operations that reference sensitive types or fields, and if the runtime does not apply the same authorization checks consistently, it can lead to IDOR-like access across unrelated resources. In C# services, reflection or dynamic object resolution used to map GraphQL types can also introduce unexpected behavior when processing untrusted input from a batch payload.

The combination of ASP.NET’s request processing pipeline and C#’s runtime type resolution can make it difficult to isolate failures in individual operations. A malformed or malicious query in one batch item may disrupt parsing, cause exceptions, or leak stack traces. If the server returns detailed errors for only some items, an attacker can probe for differences and infer schema details. Without structured error handling and consistent validation, batching becomes a vector for probing and data exposure rather than a convenience feature.

Middleware that inspects or logs raw batch payloads may inadvertently retain sensitive information if logging is not carefully controlled in C# applications. Additionally, if the batch resolver does not enforce timeouts or cancellation tokens uniformly, a single expensive operation can degrade overall responsiveness. These issues align with broader categories such as Input Validation, Property Authorization, and Data Exposure, which are part of standard API security checks and are relevant when evaluating an endpoint with tools such as middleBrick that scan for these classes of findings.

To reduce risk when supporting GraphQL batching in ASP.NET with C#, apply strict validation, consistent authorization, and structured error handling per operation. Avoid dynamic or unchecked resolution of types from batch input, and ensure each operation is treated as an independent request with its own safeguards.

1. Validate and sanitize each operation independently

Before executing an operation from the batch, validate the query string and variables. Use strongly typed models for variables and avoid passing raw JSON directly to the GraphQL execution engine.

using System.Text.Json;
using GraphQL;
using GraphQL.Types;

public class BatchOperation
{
    public string Query { get; set; } = string.Empty;
    public JsonElement? Variables { get; set; }
}

public static class ValidationHelper
{
    public static bool IsValidOperation(string query, out string error)
    {
        // Basic safety checks: reject queries containing introspection at the batch level
        if (query.Contains("__schema") || query.Contains("__type"))
        {
            error = "Introspection operations are not allowed in batch requests.";
            return false;
        }
        // Reject queries with excessive depth or complexity (implement a simple rule)
        if (query.Length > 2000)
        {
            error = "Query exceeds length limit.";
            return false;
        }
        error = string.Empty;
        return true;
    }
}

// Usage within a batch processor
public async Task<IEnumerable<ExecutionResult>> ProcessBatchAsync(IEnumerable<BatchOperation> operations)
{
    var results = new List<ExecutionResult>();
    foreach (var op in operations)
    {
        if (!ValidationHelper.IsValidOperation(op.Query, out var validationError))
        {
            results.Add(new ExecutionResult { Errors = new[] { new ExecutionError(validationError) } });
            continue;
        }

        // Use a fresh context and schema instance per operation
        var schema = MySchemaFactory.Build();
        var executor = new DocumentExecuter();
        var result = await executor.ExecuteAsync(_ =>
        {
            _.Schema = schema;
            _.Query = op.Query;
            if (op.Variables.HasValue)
            {
                var json = op.Variables.Value.GetRawText();
                _.Inputs = JsonConvert.DeserializeObject<Inputs>(json);
            }
        });
        results.Add(result);
    }
    return results;
}

2. Enforce consistent authorization and error handling

Ensure each operation undergoes the same authorization checks. Avoid returning detailed errors for some items while suppressing them for others, as this can leak information.

public class SecureBatchHandler
{
    private readonly IAuthorizationService _authService;

    public SecureBatchHandler(IAuthorizationService authService)
    {
        _authService = authService;
    }

    public async Task<ExecutionResult> ExecuteOperationWithAuthAsync(ExecutionContext context, string userId)
    {
        // Example: check a policy per operation
        var authResult = await _authService.CheckAccessAsync(context, userId);
        if (!authResult.IsSuccess)
        {
            return new ExecutionResult
            {
                Errors = new[] { new ExecutionError("Unauthorized") }
            };
        }

        // Execute with a uniform error format
        var executor = new DocumentExecuter();
        return await executor.ExecuteAsync(context);
    }
}

3. Limit batch size and resource usage

Control the number of operations per batch and apply timeouts to prevent resource exhaustion. Use cancellation tokens to ensure prompt termination of long-running operations.

public async Task<ExecutionResult> ExecuteBoundedBatchAsync(IList<BatchOperation> operations, int maxBatchSize, CancellationToken ct)
{
    if (operations.Count > maxBatchSize)
    {
        return new ExecutionResult
        {
            Errors = new[] { new ExecutionError("Batch size exceeds limit.") }
        };
    }

    using var timeoutCts = CancellationTokenSource.CreateLinkedTokenSource(ct);
    timeoutCts.CancelAfter(TimeSpan.FromSeconds(10));

    var results = new List<ExecutionResult>();
    foreach (var op in operations)
    {
        // Respect the shared timeout token
        var result = await ExecuteOperationWithTimeoutAsync(op, timeoutCts.Token);
        results.Add(result);
    }
    return new AggregatedExecutionResult(results);
}

4. Avoid logging sensitive batch content

When logging requests in C#, ensure batch payloads are redacted or omitted from structured logs to prevent accidental exposure of sensitive data patterns.

// Example: safe logging without raw query
logger.LogInformation("Batch processed. Operations: {Count}, Errors: {ErrorCount}",
    operations.Count,
    results.Count(r => r.Errors?.Any() == true));