Reduce the risk by disabling external entity resolution in parsers, limiting expansion depth and size, and refusing untrusted serialised input. Use safe parser settings, cap resource consumption, and isolate parsing in constrained processes. Monitor for inputs that trigger excessive entity expansion or unexpected outbound fetches during deserialisation.
How parser settings reduce entity expansion blowups
The most effective mitigation is to stop the parser from resolving external entities at all, then constrain how much expansion the parser is allowed to perform if any entity processing remains enabled. That combination addresses the blowup mechanism directly: recursive expansion, oversized replacement text, and secondary fetches that turn a small input into a large memory or CPU event.
For web-delivered XML and related content, the safest posture is to treat entity resolution as unnecessary unless a specific business case proves otherwise. A hardened parser should reject external lookups, impose size and depth ceilings, and fail closed when the document exceeds safe parsing thresholds rather than trying to recover from it.
Why untrusted serialised input is the real hazard
This class of issue is not only about XML syntax. Any deserialisation path that accepts attacker-controlled structure can be abused when the runtime materialises nested entities, references, or container objects before validation. The practical mistake is trusting the format boundary instead of treating the payload as executable parsing work with resource cost and side effects.
Rejecting untrusted serialised input is often the strongest option when the source is not fully trusted, because it removes the parser from the critical path entirely. Where input must be accepted, the control goal is to make parsing deterministic, bounded, and non-interactive so that a crafted payload cannot amplify itself into a service disruption.
What to instrument and constrain during deserialisation
Defensive controls should focus on observable parser behaviour, not just the input label. Cap memory, CPU, recursion, entity nesting, and document size, and run parsing in a constrained process or sandbox so that a parser failure does not become a host-wide outage.
Unexpected outbound fetches are a strong warning sign because they show the parser is still allowed to dereference external references. That behaviour can create latency spikes, introduce dependency on remote content, and expose internal network paths or metadata if the parser can be induced to resolve attacker-chosen locations.
Risk and Threat Considerations
Entity expansion blowups create a denial-of-service path because the attacker supplies a compact payload that expands into disproportionate processing work. If external entity resolution is still enabled, the parser can also make unintended network requests, which adds exposure beyond resource exhaustion and can leak information through request patterns.
Failure mechanism: Recursive or repeated entity expansion multiplies document size and parser workload, while external references trigger outbound retrievals that the application did not expect or authorise.
Impact: The usual outcomes are memory pressure, CPU saturation, thread starvation, application latency, and in some environments, internal network exposure or service instability from parser-side fetches.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | Parser hardening depends on safe configuration of entity handling and input processing. |
| V5 — File Handling | Serialized payload handling and constrained processing align with safe content intake controls. | |
| Recommendation — Disable external entity resolution and enforce safe parser defaults for untrusted input. Treat deserialised content as untrusted data and constrain how it is processed. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Monitoring parser-triggered fetches and anomalous expansion supports detection of abuse. |
| Recommendation — Log and alert on parser errors, excessive expansion, and unexpected outbound retrievals. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Untrusted serialized input must be validated and constrained before parsing or deserialisation. |
| SC-39 — Process Isolation | Sandboxing the parser reduces the blast radius of malformed or malicious payloads. | |
| Recommendation — Validate and reject unsafe serialised input before the parser processes it. Isolate deserialisation in a constrained process with tight resource limits. | ||
Practitioner Guidance
What to verify: Confirm that the parser actually disables external entity resolution, not just that the application claims it does. Test with a payload that includes nested entities and another that references an external resource, then verify both are blocked or safely rejected.
Decision rule: If the input source is untrusted or mixed-trust, default to a parser profile with entity resolution off, strict size and depth limits, and no outbound fetch capability. If a business requirement forces entity handling, isolate the parser and apply explicit resource ceilings before allowing the path into production.
Common mistake: Teams often patch the application but leave a library default unchanged, or they add input size checks while forgetting that a small payload can still expand explosively during parsing.
Practitioner takeaway: The real control objective is not merely blocking one payload pattern, it is making deserialisation incapable of turning attacker-controlled structure into uncontrolled work or network activity.
Related resources from NHI Mgmt Group
- Guide: Web Application Attacks Guide
- How can security teams detect data serialisation external entities blowup?
- What mitigations reduce the risk of Serialized Data External Linking?
- How should security teams reduce external attack surface risk from exposed digital footprint data?
- How should organisations set Microsoft 365 external sharing to reduce the risk of accidental data exposure?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org