Organisations defend against a Billion Laughs attack by disabling unsafe XML entity expansion, limiting parser recursion and resource use, and rejecting untrusted XML where possible. Security teams should test parsers and gateways that handle external input, because the attack causes exponential expansion that can exhaust memory or CPU and trigger service failure.
Why Billion Laughs attacks succeed and where the control boundary sits
The attack works by abusing XML entity processing, so the core defence is to treat parser behaviour as a security boundary, not just a formatting detail. Systems that accept XML from users, partners, queues, or downstream services should assume parser defaults may be unsafe until proven otherwise.
Disabling external entity resolution is only part of the picture. The same input stream can still become dangerous if the parser expands nested entities without strict limits on depth, expansion count, or total resource consumption. In practice, teams need to know which components parse XML, not just which applications “handle XML” at a business level.
For broad application defence guidance, the Web Application Attacks Guide is the most direct internal reference because it covers XML entity expansion alongside adjacent parser abuse patterns such as XXE and other injection-style failures.
How to harden parsers, gateways, and upstream intake points
Defence starts with configuration, then moves to input handling. Use parser settings that disable unsafe entity expansion, cap recursive processing, and fail closed when limits are reached. Where the architecture allows it, reject untrusted XML entirely and replace it with a safer format or a constrained schema-driven intake path.
Security teams should test the full path, not just the application code. XML may be accepted by API gateways, middleware, message brokers, ETL jobs, SSO integrations, or file import services before it ever reaches the target application, and any of those layers can become the failure point if they parse or transform XML automatically.
Because parser abuse often appears in the same broader attack family as other web-layer input attacks, the same guide is also useful for mapping where XML handling sits in the larger request-processing chain and where validation should be enforced first.
What a resilient response looks like when XML cannot be eliminated
When XML is unavoidable, the goal is to contain blast radius rather than trust the parser blindly. Put explicit CPU, memory, timeout, and request-size limits around the component that parses the input, and monitor for sudden spikes in resource use that suggest expansion is already underway.
Resilience also depends on pre-production testing. Teams should include malicious XML payloads in parser and gateway test cases so they can verify that the component rejects the payload quickly instead of consuming resources until the service degrades or crashes.
If your environment uses XML in customer-facing workflows or partner integrations, it is worth using a broader attack-history lens as well. The State of NHI & AI Agent Breach Report 2026 is not about XML specifically, but it is useful for understanding how small input-handling weaknesses often sit inside larger compromise chains once attackers find a dependable entry point.
Risk and Threat Considerations
Billion Laughs is a denial-of-service pattern, so the main risk is not data theft but service exhaustion. If XML expansion is processed before request limits or isolation controls kick in, a small payload can consume disproportionate CPU and memory and make an otherwise healthy service unavailable.
Failure mechanism: Recursive entity expansion creates exponential growth in parser work and output size, which can overwhelm memory, starve CPU, and trigger application or gateway failure before normal security controls can react.
Impact: Availability loss can cascade into API timeouts, queue backlogs, failed integrations, and incident response pressure, especially where the same parser is reused across multiple services or trust zones.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while 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 | V15 — Secure Coding and Architecture | XML parser hardening is a secure design and implementation concern. |
| Recommendation — Configure XML handling to fail closed and avoid unsafe entity expansion. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The attack is an application-layer input-handling weakness in parser code and middleware. |
| Recommendation — Test XML-processing components for unsafe entity expansion and denial-of-service behavior. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Rejecting malformed or malicious XML relies on controlling unsafe input processing. |
| SC-5 — Denial of Service Protection | Billion Laughs is a resource-exhaustion denial-of-service attack. | |
| Recommendation — Validate and constrain XML input before parsers can expand attacker-controlled entities. Limit parser resource consumption and set fail-safe thresholds for XML processing. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Unsafe XML parser defaults are a configuration weakness attackers can exploit. |
| Recommendation — Disable risky XML parser features and enforce secure gateway defaults. | ||
Practitioner Guidance
What to verify: Confirm which parsers, libraries, and managed services expand XML entities by default, and test the exact parser version and configuration actually deployed. A secure coding rule is only useful if the runtime, middleware, and gateway layers all enforce it consistently.
Decision rule: If the XML source is not strictly trusted and business requirements do not demand XML, reject XML at the boundary and use a safer format. If XML must remain, apply parser hardening plus resource limits together, because either control alone can still leave a denial-of-service path open.
Practitioner takeaway: Billion Laughs is best treated as a parser safety problem with availability consequences, and the most effective defence is to remove unsafe expansion paths before the payload ever reaches a general-purpose XML processor.
Related resources from NHI Mgmt Group
- How should organisations defend against attack-as-a-service identity fraud?
- What should organisations do first when they are trying to defend against common attack paths instead of only headline-grabbing threats?
- How can organisations defend against the Kaseya VSA attack?
- How can organisations defend against a SolarWinds-style supply chain attack?