XML external entity (XXE) injection
XXE arises when an XML parser resolves external entities from untrusted documents.
What it means
XXE arises when an XML parser resolves external entities from untrusted documents. Depending on parser behavior and environment, processing may expose files, initiate network requests, or consume resources. Security depends on the actual parser and configuration, including what a framework enables by default.
A practical example
A document import service receives XML from a partner. The team disables unnecessary external entity and DTD processing and verifies that the import cannot cause outbound retrieval from internal services or local files.
What to check
Inventory parser implementations, configure safe entity handling, restrict unnecessary network access, and test the deployed parser. Prefer simpler data formats when XML features are not needed.
A common pitfall
Assuming a dependency's default configuration is safe can fail after upgrades or wrapper changes. Parser flags differ across languages and libraries; verify the specific implementation.
Think it through
Why examine outbound network access during an XML import review?
Answer: An unsafe parser may resolve external references and turn document processing into unintended server-side requests.
XML parsing may reach outside the submitted document
A fictional invoice importer receives XML containing supplier and line-item data. Depending on parser configuration and features, resolving an external entity can cause the parser to access resources beyond the submitted message. The security boundary is therefore not just whether the XML has the expected tags; it includes what the parser is permitted to fetch or expand.
Choose parser settings for the business requirement. Many ordinary data-exchange workflows do not need external entities or document type definitions. Disable unnecessary features through the supported API and verify the effective behavior for the exact library and version in use. Defaults vary, so a configuration copied from another language may not provide the same protection.
Parsing can also consume excessive resources through expansion or unusually complex content. Set appropriate size and processing constraints and avoid giving an importer broader filesystem or network access than required. Validation against an expected schema can help define the document contract, but schema validation itself must not introduce uncontrolled external resource access.
Review the parser, not only the endpoint
For a learning exercise, list every component that parses the fictional invoice: the API, a queue worker, a validation service, and an archival viewer if present. State which XML features each actually needs. A secure front-end parser does not cover a background worker that later reparses the original document with different settings.
Use a controlled local resource to verify expected restrictions in a training environment. Do not demonstrate the problem by reading real system files or contacting internal production services. The useful evidence is that prohibited resolution is rejected and ordinary invoices continue to work. Record the parser configuration and supported regression cases so future library upgrades preserve the intended boundary.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: XML External Entity Prevention