External Entity

An external entity is an XML entity whose value points to content outside the document, such as a file, URL, or other resource. If a parser resolves it, the application may disclose information or reach systems the user should never access. Properly configured parsers should not follow these references in untrusted XML.

What External Entities Do in XML

External entities let an XML document reference content that lives outside the document itself. That reference can point to a local file, a network location, or another retrievable resource, which means parsing behavior can extend well beyond the XML payload you can see on the page.

The key security property is trust. If the parser is allowed to resolve external references from untrusted input, the XML document can become a request launcher or file reader. That is why secure XML handling is usually framed around disabling resolution by default and allowing it only when the source is trusted and the access path is tightly controlled.

Why External Entities Become a Security Problem

External entities matter because they can turn a formatting feature into an access path. When a parser expands them, it may expose local files, disclose environment details, or reach internal services that were never meant to be reachable from the user-supplied document.

That behavior is especially dangerous when XML is accepted from users, partners, or upstream systems. A parser that follows external references can unintentionally bridge trust boundaries, and the resulting data exposure may be subtle because the XML itself can look harmless until expansion happens.

For a useful reference point on the broader class of identity and secret exposure problems that often accompany parser abuse, NHIMG’s The State of Non-Human Identity Security captures how exposed credentials and weak visibility amplify downstream compromise.

How Parsers Should Handle Untrusted XML

Secure XML parsing is not about banning XML entirely. It is about controlling which document features are allowed to trigger external access, and making sure default parser settings do not silently grant that capability. In practice, the safest posture is to reject or neutralize external entity resolution unless there is a documented business need for it.

Common defenses include turning off DTD processing where possible, disabling external general and parameter entities, constraining resolver behavior, and isolating parsing in a context that cannot reach sensitive local paths or internal endpoints. The exact knobs vary by parser and language, but the security goal is consistent: untrusted XML should not be able to cause unintended reads or outbound requests.

For workload and service contexts where XML processing is part of a larger trust boundary, Guide to SPIFFE and SPIRE is useful background on workload identity and trust boundaries.

Practical Signs You Have an External Entity Exposure

External entity issues often surface as unexpected file reads, internal HTTP requests, parser errors that mention entity expansion, or logs that show the application reaching destinations it should never contact during normal XML handling. If a parser accepts arbitrary XML and the application has access to files or internal services, the exposure deserves attention even before an exploit is proven.

These flaws are usually more dangerous in applications that process uploads, SOAP payloads, integrations, or document interchange formats at scale. The risk rises further when the parser runs with broad file-system access or network reach, because the same parsing bug can produce both local disclosure and internal reconnaissance effects.

For a concrete security-control lens on the issue, OWASP API Security Top 10 remains a helpful companion for understanding how unsafe input handling and broken trust boundaries create exploitable access paths.

Risk and Threat Considerations

External entities are a classic example of a parser feature that can become a data exposure and internal reachability problem when untrusted XML is accepted. The main risk is not the XML syntax itself, but the parser’s ability to follow references into places the attacker should not be able to read or query.

Failure mechanism: The application resolves an external reference during parsing, then leaks file contents, metadata, or internal service responses through the XML processing path.

Impact: An attacker can exfiltrate sensitive data, map internal resources, or combine the disclosure with later-stage compromise depending on what the parser can reach.

Related resources from NHI Mgmt Group

• How should security teams contain XML external entity risk in document processing pipelines that accept untrusted files?
• External Entity Resolution
• XML External Entity Injection
• Should organisations prioritise external exposure or internal credential governance first?