Xml External Entities in Aspnet with Mutual Tls

XML External Entity (XXE) injection in ASP.NET applications occurs when an application processes XML input that contains references to external entities, such as file paths, URLs, or internal system resources. When combined with mutual TLS (mTLS), where both client and server present certificates during the handshake, the interaction can inadvertently expose or amplify XXE risks. mTLS ensures strong identity verification and encrypted transport, but it does not sanitize or validate the XML content itself. If an endpoint accepts XML payloads—such as SOAP messages or uploaded configuration files—and parses them with insecure XML readers, an authenticated client (holding a valid certificate) can inject malicious external entity definitions.

Consider an ASP.NET Core API that uses XmlDocument without secure settings. An attacker with a valid client certificate (as verified by mTLS) can send a crafted XML body like:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

If the server deserializes this without disabling external entities, the parser reads /etc/passwd and may return its contents in error responses or logs. Even with mTLS ensuring the request comes from a trusted client, the application logic remains vulnerable because mTLS operates at the transport layer and does not restrict what the XML parser does. This combination creates a scenario where authenticated clients can probe internal systems, potentially leading to data exposure, SSRF via internal URLs, or further pivoting. The risk is especially relevant when the ASP.NET app runs in environments with access to metadata services or internal network endpoints.

Another scenario involves WSDL-based SOAP services that fetch external schemas or DTDs. With mTLS, an attacker can position themselves as a legitimate client and request a WSDL that includes external entity references, prompting the server to make unintended outbound requests. Because mTLS only authenticates the client, it does not prevent the server from resolving these entities. The vulnerability is not in mTLS itself but in how the application handles XML when mTLS is present, underscoring the need to treat authenticated inputs as untrusted.

To mitigate XXE in ASP.NET when using mutual TLS, focus on secure XML parsing and strict input handling. Do not rely on mTLS to validate content. Use XmlReader with secure settings that explicitly disable external entities and DTD processing. Below is a concrete example of safe XML parsing in an ASP.NET Core controller:

using System.Xml;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/secure")]
public class SecureController : ControllerBase
{
    [HttpPost("parse")]
    public IActionResult ParseXml()
    {
        using var reader = XmlReader.Create(Request.Body, new XmlReaderSettings
        {
            DtdProcessing = DtdProcessing.Prohibit,
            XmlResolver = null,
            MaxCharactersFromEntities = 1024
        });
        try
        {
            var doc = new XmlDocument();
            doc.Load(reader);
            // Process doc safely
            return Ok(new { message = "XML processed securely" });
        }
        catch (XmlException)
        {
            return BadRequest("Invalid XML");
        }
    }
}

This configuration disables DTDs and external resource resolution, preventing the parser from fetching external entities. The same principles apply when using XDocument or XPathNavigator; avoid default constructors that enable legacy behavior.

For applications that must accept WSDL or schema imports, explicitly configure the web service client to avoid fetching external resources. When using System.Web.Services or ChannelFactory, ensure that the binding and resolver settings do not automatically retrieve remote documents. Here is an example using XmlSerializer with restricted settings:

using System.IO;
using System.Xml;
using System.Xml.Serialization;

var serializer = new XmlSerializer(typeof(MyData));
var settings = new XmlReaderSettings
{
    DtdProcessing = DtdProcessing.Prohibit,
    XmlResolver = null
};
using var reader = XmlReader.Create("input.xml", settings);
var data = (MyData)serializer.Deserialize(reader);

Additionally, enforce strict content-type validation and avoid accepting XML from untrusted sources even when mTLS client certificates are present. Combine these coding practices with runtime scanning using middleBrick to detect XXE indicators in your API surface. The CLI can be run as part of development workflows: middlebrick scan <url>, while the GitHub Action can fail builds if risky XML handling patterns are detected in committed code. Continuous monitoring via the Pro plan helps track changes that might reintroduce insecure parsing.