XML External Entity injection is often treated as a legacy vulnerability because many modern web applications prefer JSON. XML has not disappeared. It still appears in SOAP services, SAML, SVG, office document formats, configuration imports, RSS and Atom feeds, mobile integrations, and enterprise APIs.
XXE occurs when an XML parser processes attacker-controlled XML and resolves external entities or related external resources in an unsafe way. OWASP notes that impact can include local file disclosure, server-side request forgery, and resource exhaustion. The safest general approach is to disable DTD processing and external entity resolution unless the application has a specific, reviewed requirement for them.
What an external entity is
XML can define entities inside a document type declaration. Some parsers can resolve an entity from an external location. In a vulnerable configuration, untrusted XML may cause the server to read a local file or request a network resource.
A defensive review should focus on parser behavior rather than collecting exploit payloads. Ask whether DTDs are enabled, whether external entities can be resolved, whether external schemas or stylesheets can fetch network resources, and whether XInclude is active.
SOAP services still matter
Enterprise systems often expose SOAP endpoints long after newer REST or GraphQL APIs have been added. They may be used by payment processors, logistics providers, identity systems, or back-office applications.
Because SOAP is XML-based, parser configuration is part of the security boundary. An old integration library can keep unsafe defaults even when the main application stack is modern.
SAML uses XML
SAML assertions and protocol messages are XML documents. Identity libraries normally handle parsing and signature verification, but unsafe XML parser configuration can still be relevant underneath the protocol layer. Do not write custom SAML parsing unless there is a strong reason. Use maintained libraries, follow provider guidance, and keep the underlying XML stack patched.
SVG is XML
An application that accepts SVG uploads is accepting XML. If the server parses or transforms the SVG, XML parser security matters. SVG can also contain active content and references that make it a special case for upload security.
If the product does not need user-supplied SVG, reject it. If it does, process it with a purpose-built sanitization and rendering approach rather than treating it as a harmless image file.
Office documents can contain XML
Modern office file formats are often ZIP containers containing XML documents. Applications that extract metadata, convert documents, or inspect embedded content may invoke XML parsers indirectly. This is a useful reminder that input format and parser behavior are not always obvious from the upload extension.
RSS, Atom, and feed importers
Feed readers and content importers frequently parse XML fetched from user-supplied URLs. That creates two boundaries at once: SSRF risk when the server fetches the feed and XXE risk when it parses the response.
Constrain both layers. Validate outbound destinations, restrict network access, and use a hardened parser.
Disable DTDs when possible
OWASP's strongest general recommendation is to disable document type definitions where the application does not need them. If the parser supports rejecting DOCTYPE declarations, use that setting for untrusted XML.
If DTDs are genuinely required, disable external entity resolution and external DTD loading, and limit entity expansion.
Do not forget XInclude, schemas, and stylesheets
External access can happen outside traditional entity expansion. XInclude can load external resources. XML schema validation may retrieve external schemas. XSLT processing can access network or file resources depending on the implementation.
Review the whole XML processing pipeline, not only one parser flag.
Fail closed when hardening is unavailable
OWASP advises treating unsupported security settings as a configuration failure. If a parser version cannot disable dangerous external resolution reliably, do not continue parsing untrusted XML with partial protection. Upgrade or replace the parser, or isolate the processing environment so it cannot reach sensitive files or networks.
Network isolation reduces impact
Even with parser hardening, defense in depth matters. A document conversion worker does not usually need access to cloud metadata services, internal databases, or arbitrary internet hosts.
Restrict egress from parsing and conversion services. Run them with minimal filesystem permissions. Use temporary storage and sandboxing where practical.
Content-Type does not prove parser safety
An endpoint advertised as JSON may still accept XML through content negotiation or a legacy compatibility path. File converters may inspect content regardless of the extension. Middleware may transform requests before your controller sees them.
Test what the server actually accepts. Inventory parsers by code path and dependency, not only by documented API format.
Third-party libraries can hide parser settings
A high-level library may create its own XML parser internally. Updating a global parser configuration may not affect it. SAML, SOAP, office conversion, and feed libraries should be reviewed against their own secure-configuration guidance.
Pin maintained versions and monitor security advisories. Remove parsing libraries that the application no longer uses.
Test your real input paths
Inventory every feature that accepts or generates XML:
- SOAP APIs;
- SAML integrations;
- SVG upload or conversion;
- office-document processing;
- RSS and Atom import;
- XML configuration import/export;
- legacy partner APIs;
- mobile or desktop synchronization formats.
For each, identify the library and parser configuration. Do not assume one framework-wide setting protects every dependency.
Lack of file output does not prove safety
Some unsafe XML behavior is visible only through network side effects, timing, or external callbacks. Security testing should be performed only on systems you own or are authorized to test, with controlled destinations and non-sensitive files.
The primary goal is to verify the parser cannot access external resources, not to demonstrate maximum impact against production.
How Vulnify relates to XXE
Vulnify's deeper scanner includes XML and XXE-related checks within its supported assessment scope. That can help identify externally testable XML behavior and related web risk. It does not know every private document-processing job, message queue, internal SOAP service, or offline import pipeline.
Use external scanning to assess reachable surfaces, then review parser configuration in the application and supporting services.
XXE prevention checklist
- Inventory features that parse XML directly or indirectly.
- Disable DTDs where they are not required.
- Disable external entity and external DTD resolution.
- Keep XInclude disabled unless explicitly needed.
- Restrict external access during schema and stylesheet processing.
- Use maintained XML and identity libraries.
- Restrict network egress from conversion and parsing workers.
- Run parsers with minimal filesystem permissions.
- Reject unsupported unsafe parser configurations.
- Test SOAP, SAML, SVG, office, and feed-processing paths separately.
XML limits matter even when external access is disabled
An XML document can be harmful through resource consumption even when it cannot fetch files or network resources. Entity expansion, deeply nested structures, huge attribute values, or extremely large documents can consume memory and CPU.
Set maximum document sizes, nesting limits, entity-expansion limits where relevant, and request timeouts. Parsing should happen in a bounded environment rather than with unlimited resources.
Schema validation can trigger external fetches
Teams sometimes disable external entities but leave schema resolution able to retrieve remote XSD files. That means a parser may still make outbound connections during validation. Configure schema factories and validators so external access is denied unless a specific trusted dependency requires it.
Prefer locally pinned schemas for stable protocols. This avoids availability and supply-chain dependencies on remote schema hosts during request processing.
Treat XSLT as code-like processing
XSLT processors can provide extension functions, file access, or network access depending on implementation and configuration. If users can supply XSLT or influence stylesheet selection, the risk extends beyond ordinary XML parsing.
Disable extension functions and external document access unless explicitly required. Consider a dedicated sandbox for document transformation workloads.
SAML security has more than XXE
Hardening the XML parser does not make a SAML implementation secure on its own. Signature validation, audience checks, issuer trust, replay handling, destination checks, and assertion conditions still matter. Use XXE prevention as one layer inside a maintained SAML library rather than building a custom parser around raw XML.
Isolate uploads before parsing
When XML-bearing files are uploaded, store them outside executable web paths, assign server-generated names, and process them with a low-privilege worker. If parsing fails, preserve only the diagnostic data necessary for investigation and do not echo raw XML into an administrative web page without output encoding.
For sensitive document workflows, scan or sanitize content before making it available to other users or downstream systems.
Make parser security part of automated tests
Parser hardening is easy to lose during a library upgrade. Add tests that submit XML containing a harmless DOCTYPE and confirm the application rejects it or processes it without external resolution according to the intended policy. Add separate tests for XInclude or external schema loading if those features are relevant to the stack.
The test should fail when a future dependency update silently re-enables unsafe behavior. That turns an obscure parser setting into an explicit application requirement.
Review XML behavior after runtime upgrades
Java, .NET, PHP, Python, and other ecosystems have changed parser defaults over time. Upgrading a runtime or switching XML libraries can therefore change behavior even when application code is untouched. Include parser-security checks in major framework and runtime upgrades.
Document the exact secure settings near the code that creates the parser. A generic security wiki page is less useful than a test and configuration that travel with the implementation.
XML is not gone, it is just less visible
The modern security mistake is not using XML. It is forgetting that a feature uses XML and leaving a parser at an unsafe default. Treat XML parsing as a privileged operation: disable features you do not need, prevent external resolution, and isolate the code that processes untrusted documents.