CWE-611 in APIs

CWE-611: Improper Restriction of XML External Entity Reference describes a vulnerability where an application processes XML input containing external entity references without proper restrictions. This weakness allows attackers to include references to external entities, potentially leading to information disclosure, denial of service, or server-side request forgery (SSRF).

The vulnerability stems from XML parsers that process external entities by default. When an XML document contains a reference like <!ENTITY x SYSTEM "file:///etc/passwd">, a vulnerable parser will attempt to fetch and include the referenced content. This can expose sensitive files, internal network resources, or cause resource exhaustion through recursive entity expansion.

In API environments, CWE-611 commonly manifests when endpoints accept XML payloads for operations like configuration uploads, document processing, or data import/export. REST APIs that support XML content types (application/xml, text/xml) are particularly vulnerable if they don't configure their XML parsers securely.

Consider an API endpoint that accepts XML configuration files:

POST /api/upload-config HTTP/1.1
Content-Type: application/xml

<config>
  <database><connection>db.example.com</connection></database>
</config>

If this endpoint processes the XML without disabling external entity resolution, an attacker could submit:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE config [
  <!ENTITY x SYSTEM "file:///etc/passwd">
]>
<config>
  <database><connection>&x;</connection></database>
</config>

The API would return the contents of /etc/passwd in the response, exposing sensitive system information. APIs that process XML for report generation, data transformation, or integration with external services are especially at risk.

Detecting CWE-611 requires testing XML processing endpoints with crafted payloads that attempt external entity inclusion. Manual testing involves submitting XML documents with various external entity declarations and observing whether the parser resolves them.

Automated scanning with middleBrick provides comprehensive detection by testing the unauthenticated attack surface of your API endpoints. The scanner submits XML payloads containing external entity references to all endpoints that accept XML content types, checking whether the parser resolves these references or blocks them appropriately.

middleBrick's approach includes:

• Scanning all API endpoints that accept XML content types
• Submitting XML payloads with external entity declarations targeting local files, internal network resources, and external URLs
• Analyzing responses for evidence of entity resolution (file contents, network access patterns)
• Checking parser configuration by testing known bypass techniques
• Providing severity ratings based on the impact of successful exploitation

The scanner tests 12 security categories in parallel, including XML External Entity Reference detection as part of its comprehensive security assessment. This automated approach finds vulnerabilities that manual testing might miss, especially in complex API ecosystems.

The primary remediation for CWE-611 is configuring XML parsers to disable external entity resolution. Most modern XML libraries provide secure configuration options:

// Java - JAXP DocumentBuilderFactory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
DocumentBuilder db = dbf.newDocumentBuilder();

// Python - lxml
from lxml import etree
parser = etree.XMLParser(resolve_entities=False)
tree = etree.fromstring(xml_data, parser)

// Node.js - xml2js
const parseString = require('xml2js').parseString;
parseString(xmlData, { explicitArray: false, explicitRoot: false, mergeAttrs: true, validator: null }, callback);

For applications that legitimately need to process XML with external entities, implement a whitelist approach that only allows specific, trusted external resources. Consider using XML Catalogs to control external entity resolution.

Additional security measures include:

• Input validation to reject XML documents containing DOCTYPE declarations
• Network segmentation to limit the impact of SSRF attacks
• Resource limits on XML processing to prevent denial of service through entity expansion
• Using JSON instead of XML when possible, as JSON doesn't support external entity references

Regularly scan your APIs with middleBrick to verify that XML External Entity Reference vulnerabilities remain fixed, as configuration changes or library updates can reintroduce this weakness.