Header Injection in Aspnet with Mutual Tls

Header Injection occurs when an attacker can influence HTTP headers that are later reflected into responses or used to alter routing and policy enforcement. In ASP.NET applications using Mutual TLS (mTLS), the assumption is often made that strong transport-layer authentication removes the need for rigorous header validation. This assumption creates a dangerous blind spot. Even with client certificates verified by the server, untrusted input can still reach application code through headers that are forwarded or processed after the TLS handshake, such as custom routing headers, correlation IDs, or forwarded-by proxies.

With mTLS, the client presents a certificate and the server validates it before the application processes the request. However, once the request enters the ASP.NET pipeline, headers are still parsed and can be manipulated if the server acts as a proxy or includes untrusted data in headers it generates. For example, if the application copies values from custom headers like X-Forwarded-For or X-Request-ID into downstream requests or logs without validation, an attacker can inject crafted header values that propagate beyond the mTLS boundary. This can lead to request smuggling, cache poisoning, or unauthorized routing changes, because mTLS does not sanitize or validate the content of HTTP headers.

In an ASP.NET setup, this often manifests when developers use server-side code to read headers such as Authorization, X-API-Key, or custom headers and then pass them to other services. Even with mTLS ensuring the identity of the connecting client, the content of those headers remains untrusted. Real-world attack patterns like header-based SSRF or injection into logging systems can occur here. The interplay between mTLS and header processing can inadvertently expose internal endpoints or override security decisions if header values are trusted simply because the connection is authenticated at the transport layer.

middleBrick detects scenarios where header-driven logic exists alongside mTLS by analyzing OpenAPI specs and runtime behavior. It flags endpoints that read and forward headers without canonicalization or strict allowlists, even when mTLS is in place. This is important because mTLS protects the channel, not the semantics of the messages passing through it.

Remediation focuses on treating all headers as untrusted, regardless of mTLS status. Validate, sanitize, and explicitly allowlist headers before they are used or forwarded. In ASP.NET, this means inspecting incoming headers in middleware or within controllers and rejecting or transforming unexpected values.

Below are concrete code examples for an ASP.NET Core application using Mutual TLS. The first example shows how to inspect and restrict headers in middleware, ensuring only known-safe headers are forwarded or processed. The second demonstrates a controller that safely reads a custom header with strict validation.

// Middleware to validate and sanitize headers in ASP.NET Core with mTLS
app.Use(async (context, next) =>
{
    var allowedHeaders = new HashSet(StringComparer.OrdinalIgnoreCase)
    {
        "Content-Type",
        "Authorization",
        "X-Request-ID",
        "X-Correlation-ID"
    };

    var headersToRemove = context.Request.Headers
        .Where(h => !allowedHeaders.Contains(h.Key))
        .Select(h => h.Key)
        .ToList();

    foreach (var key in headersToRemove)
    {
        context.Request.Headers.Remove(key);
    }

    await next();
});

// Controller safely reading a custom header with strict validation in ASP.NET Core
[ApiController]
[Route("api/[controller]")]
public class ProxyController : ControllerBase
{
    private static readonly HashSet<string> AllowedRequestIds = new(StringComparer.OrdinalIgnoreCase)
    {
        "trace-001",
        "trace-002"
    };

    [HttpGet("/api/value")]
    public IActionResult GetWithHeader()
    {
        if (!Request.Headers.TryGetValue("X-Request-ID", out var requestIdValues))
        {
            return BadRequest("Missing X-Request-ID");
        }

        var requestId = requestIdValues.FirstOrDefault();
        if (string.IsNullOrEmpty(requestId) || !AllowedRequestIds.Contains(requestId))
        {
            return BadRequest("Invalid X-Request-ID");
        }

        // Safe to use requestId
        return Ok(new { RequestId = requestId });
    }
}

Additionally, ensure that any outgoing requests initiated by the ASP.NET service do not forward untrusted headers. Use explicit header sets instead of copying all incoming headers. For environments where mTLS is enforced at the load balancer or sidecar, continue to validate headers at the application layer to prevent injection through application-managed forwarding or logging.

middleBrick can help identify header processing logic in your API surface by scanning your OpenAPI specification and runtime endpoints. It flags endpoints that read and propagate headers without strict allowlists, even when mTLS is enforced, supporting compliance mappings to frameworks such as OWASP API Top 10 and SOC2.