What should teams do when a parser accepts untrusted XML at all?

What changes once untrusted XML is accepted at the parser boundary?

At that point, XML parsing is no longer a convenience feature, it is a security boundary. The parser’s default behaviour determines whether the application only reads structured input or also follows references, loads external DTDs, and expands entities that can reach local files or remote hosts. Treat the parser as part of the trust boundary, not a neutral utility.

That distinction matters because XML features were designed for document flexibility, not hostile-input handling. A parser that accepts untrusted XML without hardening can convert a simple request into data disclosure, unexpected outbound network access, or resource consumption problems. The safe assumption is that the input is adversarial until proven otherwise.

In practice, the question is not whether the XML is valid, but whether the parser can be forced to resolve anything beyond the submitted payload. If the answer is yes, the application has an exposure path that should be removed or tightly constrained before the parser is trusted in production.

Which parser behaviours should be disabled by default?

The first control is to block DOCTYPE declarations whenever the business case does not require them. DOCTYPE is the usual entry point for entity expansion and external reference handling, so allowing it without a strong reason creates unnecessary attack surface. If the application truly needs a document type, that exception should be deliberate and narrowly tested.

Next, disable external entity resolution and external DTD loading. These two settings are the difference between parsing local text and letting the parser make trust decisions on behalf of the application. When they are enabled, a hostile document can try to pull in remote resources or local files that were never intended to be readable from the request path.

Parser hardening should also be paired with the smallest possible XML feature set. If the application only needs a subset of XML, prefer a parser mode or library configuration that omits validation, expansion, and any network retrieval behaviour. The more functionality the parser is allowed to perform, the more careful the review must be before that parser sees untrusted input.

What does a safe review look like before the parser is exposed?

A safe review starts with configuration, not with incident response after the fact. Teams should verify the exact parser, version, and runtime defaults, because the risk often comes from inherited settings rather than explicit code. The review should confirm that the chosen library cannot resolve external references and cannot read from unintended locations when handed hostile input.

This is also where adjacent control disciplines matter. The issue is partly about application parsing, but it is also about boundary control, network egress, and file access assumptions. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames access enforcement, system integrity, and configuration management as operational controls rather than one-time coding advice. For the same reason, OWASP API Security Top 10 helps teams think about parser-driven trust breaks as input handling and boundary enforcement problems, not just XML quirks.

Validation should include a simple negative test set: a payload with DOCTYPE, a payload that tries to resolve an external entity, and a payload that attempts an external DTD reference. If any of those succeed, the parser still has behaviours that are unsafe for untrusted input and should not be released as-is.

Risk and Threat Considerations

Untrusted XML becomes dangerous when parser features create implicit trust in references the application never intended to follow. The main risks are local file disclosure, server-side request forgery, and amplification of resource use through entity processing or repeated external lookups. Those risks are especially serious because they often appear as ordinary parsing operations rather than obvious security events.

Failure mechanism: A hostile document uses DOCTYPE, external entities, or external DTD references to make the parser fetch data, expand entities, or touch local resources outside the intended request boundary.

Impact: The application may leak files, disclose internal services through SSRF, or become unstable under parsing load. In some environments the same weakness can also provide a foothold for broader trust abuse if parser output is reused elsewhere.

Practitioner Guidance

What to verify: Confirm the parser configuration in the deployed runtime, not just in source code review. Teams should be able to show that DOCTYPE is rejected or tightly controlled, external entity resolution is off, and external DTD loading is disabled in the effective production settings.

Decision rule: If untrusted XML is accepted at all, treat any parser option that can reach outside the submitted payload as a blocking concern until proven unnecessary. If the application needs a richer XML feature set, isolate that use case and test it separately rather than assuming a general-purpose parser is safe by default.

Practitioner takeaway: The key judgement is to distinguish “can parse XML” from “can safely parse hostile XML”; only the second should be allowed to cross a trust boundary.

Related resources from NHI Mgmt Group

• What breaks when an API parser accepts untrusted XML inside a JSON workflow?
• What do teams get wrong about XML parser security?
• How should security teams contain XML external entity risk in document processing pipelines that accept untrusted files?
• How should security teams implement safe XML parsing in Java across different parser types?