What is the difference between an internal XML entity and an external XML entity?

An internal entity already contains its content inside the XML document, so the parser expands it from local data only. An external entity points to content elsewhere, such as a URL, file, or network resource, and the parser may fetch that data during processing. External entities create the attack surface that XXE abuse depends on.

How internal and external XML entities differ

An internal XML entity is defined and resolved entirely inside the document, so the parser substitutes a local value during parsing. An external XML entity is only a reference, and the parser may dereference content from a file, URL, or other network location. That distinction matters because it changes whether XML processing stays self-contained or can reach beyond the document boundary.

Internals are usually used for repeated text, abbreviations, or document convenience. Externals are a parser feature with much wider trust implications because the XML processor must decide whether to fetch remote or local resources, and whether to allow that fetch at all. In secure parsing, that decision is often restricted or disabled by default.

The practical boundary is not just where the content lives, but what the parser is allowed to do. A document that expands only internal entities can be processed without outbound I/O, while a document that permits external entity resolution can trigger file reads, network lookups, or both, depending on parser behavior and configuration.

Why external entities change the attack surface

External entities are the reason XXE exists as a security issue. If a parser resolves an attacker-influenced external reference, the XML payload can be turned into a request for local files, internal services, or other resources that the parsing process can reach. The risk is driven by trust in parser expansion, not by XML syntax alone.

That is why many security controls focus on disabling external entity resolution, blocking DTD processing where it is unnecessary, and constraining parser access to local or approved sources only. Where XML is accepted from untrusted input, the safe default is to assume entity expansion can be abused unless explicitly hardened.

For practitioners, the key difference is operational: internal entities mainly affect document structure and readability, while external entities can become a data access mechanism. The second case creates exposure to file disclosure, SSRF-like behaviour, and sometimes denial of service when expansion cascades or parser calls stall on remote lookups.

What to verify in code, parsers, and reviews

Check whether the parser permits DTDs, external general entities, and external parameter entities, because those settings determine whether the difference is merely theoretical or security-relevant. Also verify that libraries used by frameworks or middleware are not re-enabling entity resolution behind a convenience wrapper.

If the XML format does not need external references, prefer the simplest safe configuration and reject documents that try to use them. If external resolution is genuinely required for a trusted workflow, constrain the allowed sources and treat that path as an explicit dependency with logging and review, not as a default parser feature.

When reviewing code, look for assumptions that XML is only “data.” The parser can perform work on behalf of the document author, so safe handling depends on configuration, input trust level, and whether the document is allowed to reference resources outside itself.

Risk and Threat Considerations

External entity processing is dangerous because it can turn a parsing step into a read or retrieval primitive. If an attacker can influence XML content and the parser resolves external references, the result can be local file disclosure, internal network probing, or unintended outbound requests.

Failure mechanism: The parser expands a reference to a resource outside the XML document, and that fetch happens with the privileges and network reach of the application processing the input.

Impact: Sensitive files, tokens, configuration values, or internal endpoints can be exposed, and the parser may also become a pivot point for SSRF-style interaction or service disruption.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-3 — Remote Access	External entity resolution can create unintended remote resource access paths.
Recommendation — Restrict XML parsers from reaching unapproved remote or local resources.
CIS Controls v8	CIS Control 16 — Application Software Security	XXE is an application parsing weakness that should be eliminated in code and libraries.
Recommendation — Harden XML parser settings and remove unsafe entity resolution in application code.
MITRE ATT&CK	T1106 — Native API	Attackers abuse parser behavior to force resource access through legitimate software functions.
Recommendation — Detect and block XML parsing paths that can be coerced into external resource access.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Exposure	External entity abuse can expose secrets and credentials through parser-fetched content.
	NHI-02 — Lifecycle and Rotation	External fetches can surface stale or mismanaged credentials embedded in reachable content.
	NHI-05 — Third-Party and Supply-Chain Risk	External entities can point to outside resources, creating dependency and trust-boundary risk.
Recommendation — Prevent XML parsers from dereferencing attacker-controlled external entities. Treat XML-referenced secrets as exposed material and rotate anything that may have leaked. Allow external XML references only from approved, controlled sources.

Practitioner Guidance

What to verify: Confirm that every XML parsing path uses a hardened configuration, not just the obvious application entry points. Libraries, XML utilities, and framework defaults can differ, so one permissive path is enough to preserve XXE exposure.

Decision rule: If the business case does not require external entities, disable them and reject documents that depend on DTD-based expansion. If they are required, allow only tightly scoped sources and log every resolution event for review.

Common mistake: Teams often focus on the XML schema or payload format and miss the parser’s network and file access behavior. The attack surface is defined by what the parser may resolve, not by whether the document looks harmless at a glance.

Practitioner takeaway: Treat internal entities as in-document text substitution and external entities as a resource access feature, then harden the parser accordingly before untrusted XML ever reaches production.