Xml External Entities in Adonisjs with Mutual Tls

XML External Entity (XXE) injection occurs when an application processes XML input that references external entities, allowing an attacker to disclose local files, trigger SSRF, or cause denial of service. AdonisJS applications that parse XML—typically via libraries like libxmljs or xmldom—can be vulnerable if input validation is missing. When mutual TLS (mTLS) is used, the server authenticates the client via a client certificate before the application logic runs. This can create a false sense of security: operators may assume mTLS alone prevents abuse, but once the request reaches the application, untrusted XML payloads from authenticated clients are still processed by the framework or underlying libraries.

The combination of mTLS and XXE is risky because mTLS ensures the client is known and authorized at the transport layer, but does not sanitize the content of the XML body. An authenticated client (or a compromised certificate) can submit malicious XML that defines external entities pointing to sensitive files such as /etc/passwd or internal metadata services. For example, an attacker could provide an XML payload with a DOCTYPE that declares an external parameter entity referencing file:///etc/passwd. If the XML parser resolves the entity, the file contents may be exfiltrated through error messages or side channels.

In AdonisJS, this often manifests when developers use generic XML parsers without disabling external entity resolution. The parser’s default behavior may process DOCTYPE declarations and fetch external resources. Even with mTLS enforcing channel-level identity, the application must still treat authenticated input as untrusted. Common patterns that are vulnerable include using new DOMParser().parseFromString(xmlString) in Node.js environments or AdonisJS services that rely on libxml-based parsers without explicit entity disabling. Attack vectors also expand if the API accepts XML from multiple authenticated sources, increasing the likelihood that a vulnerable parser processes malicious payloads.

An illustrative scenario: an AdonisJS endpoint exposed via mTLS accepts an XML configuration upload. The endpoint passes the raw string to an XML parser that does not disable external entities. A client with a valid certificate sends an XML document containing a reference to file:///app/.env. The parser resolves the entity and returns the parsed configuration including secrets, which then appear in application logs or error responses. Because mTLS authenticated the request, developers may overlook the need to sanitize XML input, inadvertently enabling data exposure.

To detect such issues, scanning tools like middleBrick analyze the unauthenticated attack surface and can identify endpoints that accept XML and inspect whether external entity resolution is disabled. The LLM/AI security checks in middleBrick specifically probe for system prompt leakage and injection techniques, which helps uncover indirect risks when XML handling intersects with AI components. Findings include severity-ranked guidance to remediate XXE and verify mTLS scope, ensuring that authenticated channels do not bypass input validation.

Remediation focuses on two layers: ensuring mTLS is correctly configured and hardening XML parsing to prevent entity expansion. At the transport layer, AdonisJS can leverage the underlying Node.js TLS server options to require client certificates and validate them against a trusted CA. At the application layer, XML parsers must be configured to disable external entities and DTD processing.

Below are concrete code examples for an AdonisJS project using HTTPS with mTLS and secure XML parsing. The first snippet configures the HTTPS server with requestCert and rejectUnauthorized to enforce client certificates. The second shows a safe XML parsing utility that disables external entities using libxml features available in Node.js environments (via xmldom or similar parsers that allow entity expansion control).

Mutual TLS server setup in AdonisJS

const { Ignitor } = require('@adonisjs/ignitor')
const https = require('https')
const fs = require('fs')

const server = https.createServer({
  key: fs.readFileSync('path/to/server.key'),
  cert: fs.readFileSync('path/to/server.crt'),
  ca: fs.readFileSync('path/to/ca.crt'),
  requestCert: true,
  rejectUnauthorized: true
}, (req, res) => {
  // AdonisJS bootstrap
  new Ignitor(require('@adonisjs/fold')).appRoot(__dirname).fireHttpServer()
})

server.listen(443, () => {
  console.log('HTTPS server with mTLS running on port 443')
})

This ensures only clients presenting certificates signed by the trusted CA can establish a TLS connection. Note that mTLS happens at the transport layer; the application must still validate and sanitize data from authenticated clients.

Secure XML parsing to prevent XXE

Use a parser configuration that disables external entities and DTDs. For parsers based on xmldom, you can set features to prevent entity expansion:

const { DOMParser } = require('xmldom')
const parser = new DOMParser({
  // Disable external entity resolution
  externalEntityResolver: (publicId, systemId) => {
    throw new Error('External entities are not allowed')
  },
  // Explicitly disable DTD processing where supported
  disableXmlParser: false,
  // Ensure feature settings align with secure parsing
  features: {
    'http://apache.org/xml/features/disallow-doctype-decl': true,
    'http://xml.org/sax/features/external-general-entities': false,
    'http://xml.org/sax/features/external-parameter-entities': false,
    'http://apache.org/xml/features/nonvalidating/load-external-dtd': false,
    'http://xml.org/sax/features/validation': false
  }
})

const xmlString = req.body.toString()
try {
  const document = parser.parseFromString(xmlString)
  // Process document safely
  res.json({ success: true, data: document.toString() })
} catch (error) {
  res.status(500).json({ error: 'Invalid XML' })
}

These settings prevent the parser from fetching external resources and reject DOCTYPE declarations, mitigating XXE. In AdonisJS, encapsulate this logic in a service or validator so all XML-handling endpoints use the same secure parser. Combine this with input validation schemas to further reduce risk.

middleBrick’s CLI can be used to scan endpoints and verify that XXE-prone parsing patterns are not present in the runtime behavior. The GitHub Action can enforce that new commits do not introduce insecure XML handling, while the MCP Server allows developers to scan APIs directly from their IDE when refactoring parsing code. Continuous monitoring via the Pro plan helps detect regressions in XML handling across deployed versions.