Xml External Entities in Adonisjs with Dynamodb

XML External Entity (XXE) injection occurs when an application processes untrusted XML input and the XML parser resolves external entity references. In AdonisJS, this risk arises when XML parsing is used—for example, to process uploaded configuration files, webhook payloads, or legacy API integrations—without disabling external entity resolution. If the parsed data is later used to interact with AWS services, a DynamoDB client in AdonisJS can inadvertently become an attacker-controlled channel.

Consider an endpoint that accepts an XML file describing data-mapping rules and uses those rules to write items to a DynamoDB table. If the XML parser is configured to resolve external entities, an attacker can supply an XML document that references a malicious external entity (e.g., file:///etc/passwd or a remote attacker-controlled URL). The parser resolves these references and injects the content into the application logic. When the application builds a DynamoDB request, attacker-controlled content can be embedded in item attributes, potentially exposing sensitive data if the request is logged or reflected, or causing unexpected behavior in downstream systems.

The combination of AdonisJS and DynamoDB becomes vulnerable when developers use XML-based formats (such as SOAP envelopes or custom metadata formats) and inadvertently allow entity expansion. For example, an XML payload with a DOCTYPE declaration defining an external entity can lead to sensitive data exposure if the parser resolves the entity and passes the result to DynamoDB attribute values. Even if the DynamoDB client itself does not parse XML, the surrounding AdonisJS request-handling code may process XML before constructing parameters for DynamoDB operations such as PutItem or UpdateItem. Without proper parser hardening, the attack surface extends to the data layer accessed via DynamoDB.

Real-world attack patterns include probing for file:// paths, http:// or https:// remote hosts to trigger SSRF via the parser, or attempting to exfiltrate data through entity expansions that reach external endpoints. While the DynamoDB service does not parse XML, the risk lies in how AdonisJS handles and forwards XML-derived data to AWS SDK calls. An attacker might not directly exploit DynamoDB through XXE, but they can use it to manipulate what is stored or retrieved, especially if item attributes include parsed XML text that is later used in conditional expressions or logging.

To detect such issues, scans like those performed by middleBrick analyze the unauthenticated attack surface of AdonisJS endpoints that accept XML input and inspect how data flows into AWS SDK clients. The scanner checks whether external entity resolution is disabled and whether user-controlled data is validated before being used in DynamoDB operations. This helps identify insecure configurations where XML parsing could affect DynamoDB interactions, aligning with checks such as Input Validation and Data Exposure in the 12 security checks.

Remediation focuses on two areas: securing XML parsing and ensuring DynamoDB interactions treat all input as safe data. For XML processing, disable external entity resolution entirely. If your AdonisJS application does not require XML, remove XML parsing dependencies. If you must parse XML, use a parser that supports secure options and configure it to reject external entities.

Example: Using the xmldom library securely in AdonisJS by disabling external entities:

const { DOMParser } = require('@xmldom/xmldom');
const parser = new DOMParser({
  ignoreWhitespace: true,
  // Ensure no external subset or entity resolution is enabled
  // xmldom does not resolve external entities by default when not explicitly configured
});

function parseUserXml(xmlString) {
  const doc = parser.parseFromString(xmlString, 'text/xml');
  // Validate and extract data without relying on external entities
  const title = doc.getElementsByTagName('title')[0]?.textContent || '';
  return { title };
}

For DynamoDB operations, always construct request parameters from validated and sanitized data, never directly from parsed XML text. Use the official AWS SDK for JavaScript with AdonisJS to put items safely:

const { DynamoDBClient, PutItemCommand } = require('@aws-sdk/client-dynamodb');
const client = new DynamoDBClient({ region: 'us-east-1' });

async function storeItem(params) {
  // params should be built from validated input, not raw XML content
  const command = new PutItemCommand({
    TableName: process.env.DYNAMODB_TABLE,
    Item: {
      id: { S: params.id },
      content: { S: params.content },
      createdAt: { S: new Date().toISOString() }
    }
  });
  const response = await client.send(command);
  return response;
}

Apply strict validation on any data extracted from XML before it reaches DynamoDB. For example, validate string length, allowed characters, and data types. If you accept file uploads in XML format, inspect the structure with a schema (XSD or RelaxNG) and reject documents that declare external entities or references:
function validateXmlStructure(xmlObj) {
  // Ensure no DOCTYPE or entity declarations are present
  if (xmlObj.doctype || (xmlObj.internalSubset && xmlObj.internalSubset.length)) {
    throw new Error('Invalid XML: external entities are not allowed');
  }
  // Further schema-like checks on expected elements and attributes
  return true;
}

In an AdonisJS controller, combine these practices:
const { parseUserXml } = require('./xmlParser');
const { storeItem } = require('./dynamodbClient');

async function handleUpload({ request }) {
  const xml = request.input('xml');
  const parsed = parseUserXml(xml);
  validateXmlStructure(parsed);
  await storeItem(parsed);
  return { status: 'ok' };
}

By disabling external entity resolution at the parser level and treating all XML-derived data as untrusted input, you reduce the risk that XXE can affect DynamoDB operations. middleBrick can highlight whether your endpoints accept XML and whether entity resolution is disabled as part of its security checks.