Header Injection in Aspnet with Mongodb

Header injection in an ASP.NET context with MongoDB as the backend occurs when untrusted HTTP header values are used to influence database operations or the construction of responses without proper validation and encoding. This typically maps to the OWASP API Top 10 categories of BOLA/IDOR and Input Validation, and it can expose data or enable unauthorized operations in an otherwise authenticated flow.

In ASP.NET applications, headers such as X-User-Role, X-Tenant-ID, or custom routing headers may be read to make runtime decisions. If these header values are directly interpolated into MongoDB queries—such as filter definitions, sort specifications, or projection builders—they can alter the intended query scope. For example, an attacker-supplied header could change which documents are returned or modify update operations, effectively performing IDOR across tenants or privilege boundaries.

Another injection surface arises when headers control behavior in logging, auditing, or change streams. If header values are concatenated into filter definitions for change streams or used to construct dynamic collection names, an attacker may be able to observe or influence data flows that should be isolated. Because MongoDB operations in ASP.NET often rely on serialized objects and BSON documents, malformed or unexpected header content can bypass assumptions about data structure, leading to over-fetching or unintended mutations.

Additionally, response headers can be abused if the application reflects header values into client-facing responses without validation. While this does not directly alter the database, it can leak internal routing or feature flags that assist further attacks. The risk is compounded when combined with other checks in the scan, such as BOLA/IDOR and Property Authorization, because header-driven logic may skip proper ownership checks.

Real-world patterns include using Builders<MyEntity>.Filter with concatenated JSON from headers or passing header values into aggregation pipelines. Without strict schema validation and type checking, MongoDB may accept these modified filters and return documents the caller should not see or be allowed to modify.

To mitigate header injection when using MongoDB in ASP.NET, ensure header values are never directly used to construct queries, filters, or pipeline stages. Instead, treat headers as untrusted inputs and map them to a controlled set of options or identifiers. Validate and whitelist values before they influence database operations.

Below are concrete code examples demonstrating secure patterns in C# with the official MongoDB driver.

using MongoDB.Driver;
using System;

public class TenantService
{
    private readonly IMongoCollection<TenantDocument> _collection;

    public TenantService(IMongoDatabase database)
    {
        _collection = database.GetCollection<TenantDocument>("tenants");
    }

    // Safe: map header to a known tenant identifier, validate, then use
    public TenantDocument GetTenantForRequest(string rawTenantId)
    {
        if (!Guid.TryParse(rawTenantId, out var tenantId))
        {
            throw new ArgumentException("Invalid tenant identifier");
        }

        var filter = Builders<TenantDocument>.Filter.Eq(x =>x.Id, tenantId);
        return _collection.Find(filter).FirstOrDefault();
    }

    // Safe: header-controlled role must be checked against an allowlist
    public bool HasAllowedRole(string roleHeader)
    {
        var allowed = new[] { "admin", "user", "guest" };
        return !string.IsNullOrWhiteSpace(roleHeader) && allowed.Contains(roleHeader.Trim().ToLowerInvariant());
    }

    // Safe: build filters using expression trees, not string concatenation
    public FilterDefinition<TenantDocument> BuildStatusFilter(string statusHeader)
    {
        // Validate statusHeader against known states
        if (!Enum.TryParse<TenantStatus>(statusHeader, out var status))
        {
            status = TenantStatus.Active; // default safe value
        }

        return Builders<TenantDocument>.Filter.Eq(x =>Status, status);
    }
}

For aggregation pipelines that may incorporate header values, use explicit stage construction and avoid dynamic JSON concatenation:

using MongoDB.Driver;
using System.Collections.Generic;

public class AuditService
{
    private readonly IMongoCollection<AuditEvent> _collection;

    public AuditService(IMongoDatabase database)
    {
        _collection = database.GetCollection<AuditEvent>("audit");
    }

    public List<AuditEvent> GetEventsForUser(string userIdHeader)
    {
        if (!ObjectId.TryParse(userIdHeader, out var userId))
        {
            return new List<AuditEvent>();
        }

        var pipeline = PipelineDefinition<AuditEvent, AuditEvent>.Create(new[]
        {
            new BsonDocument("$match", new BsonDocument("UserId", userId))
        });

        return _collection.Aggregate(pipeline).ToList();
    }
}

In addition to query safety, protect response headers by avoiding reflection of untrusted values. If you must include custom headers in responses, validate and encode them:

using Microsoft.AspNetCore.Http;

public void ConfigureResponseHeaders(HttpResponse response, string customValue)
{
    // Do not directly assign raw header input
    if (!string.IsNullOrWhiteSpace(customValue) && customValue.Length <= 128)
    {
        // Use a whitelist or transformation instead of raw echo
        response.Headers["X-Custom-Info"] = "processed-" + customValue.Substring(0, Math.Min(8, customValue.Length));
    }
}

Finally, combine these practices with runtime security checks such as Property Authorization to ensure that even if a header is trusted, the requesting user still has the correct rights for the target document. Regularly review your schema definitions and ensure that indexes align with validated query patterns to reduce the risk of injection-driven performance or correctness issues.