Disable XML External Entity Resolution Before Parsing Uploads

The upload that reads your server

Your application accepts an XML document from a user, passes it to a general-purpose XML parser, and extracts a few fields. That ordinary flow can disclose local files, contact internal services, or exhaust memory. The risk usually comes from a parser feature called external entity resolution, not from the XML document itself.

An XML external entity (XXE) is a reference in a document type definition (DTD) that points to a resource outside the document, such as a local file or an HTTP URL. When the parser resolves it, the content can be returned to the application or used in further processing. Many parsers enable this behavior by default or make it easy to turn on.

The useful takeaway is to disable external entity resolution at the parser factory or reader level, then verify the setting with a controlled document before deploying.

Parser-specific switches, not one XML setting

There is no universal XML switch for XXE protection. Each parser library exposes its own feature flags, and defaults differ by vendor and version.

Platform / parser	Hardening setting	What it blocks
Java DOM / SAX (DocumentBuilderFactory, SAXParserFactory)	external-general-entities and external-parameter-entities set to false; disallow-doctype-decl set to true	External DTD references and entity resolution
Java Xerces-based parsers	secure-processing set to true	Bundles entity limits, DTD restrictions, and entity expansion controls
.NET XmlReader	DtdProcessing.Prohibit on XmlReaderSettings	DTD processing and inline entity declarations

Schema validation does not replace this protection. An attacker-controlled entity can be expanded before validation runs, so the block must happen at parse time.

Worked example: harden a Java XML factory

Run this code in your application service. It requires read access to the XML input file and normal application permissions. The placeholder xmlFile is the document to parse. Feature URIs shown are common in Xerces-based JVM parsers; confirm them against your parser version.

import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.DocumentBuilder;
import org.w3c.dom.Document;
import java.io.File;

public final class HardenedXmlParser {

    private HardenedXmlParser() {
        // utility class
    }

    public static Document parse(File xmlFile) throws Exception {
        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

        // Standard SAX features: block external general and parameter entities
        factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
        factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

        // Disable validation unless your schema explicitly requires it
        factory.setFeature("http://xml.org/sax/features/validation", false);

        // Parser-specific restrictions; URIs differ by vendor
        try {
            factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
        } catch (Exception ignored) {
            // Not all parsers expose this feature
        }

        try {
            factory.setFeature("http://xml.apache.org/xerces/features/secure-processing", true);
        } catch (Exception ignored) {
            // Secure processing is optional and parser-dependent
        }

        DocumentBuilder builder = factory.newDocumentBuilder();
        return builder.parse(xmlFile);
    }
}

A .NET equivalent uses XmlReaderSettings:

var settings = new XmlReaderSettings { DtdProcessing = DtdProcessing.Prohibit };
using var reader = XmlReader.Create(stream, settings);

Expected check: the code compiles and runs against your representative XML files. If a document contains a SYSTEM entity pointing to file:///etc/passwd or an external HTTP URL, the parser should throw an exception or return without inserting the remote content. Do not use real production file paths in your test entity.

Risk: setting disallow-doctype-decl to true rejects any document with a DOCTYPE, which can break legitimate DTD-based workflows.

Verify before you deploy

Create a test document that declares an external entity and references it:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE test [
  <!ENTITY xxe SYSTEM "file:///nonexistent/test">
]>
<root>&xxe;</root>

Feed this document to the parser through your normal upload or API path. A hardened parser should fail to resolve the entity and either throw an exception or omit the entity content. If the parser returns file contents or makes an outbound request, the setting is not active.

You can also inspect the factory or reader after construction. In Java, query the feature values before parsing. In .NET, confirm DtdProcessing equals Prohibit. Check the parser dependency version and release notes, because XXE defaults and hardening APIs have changed across major releases.

Limitation: legitimate DTDs may break

Disabling external entities can stop valid document flows that rely on DTD entity references, XInclude, or schemaLocation resolution. Test representative documents from customers, partners, and internal systems after enabling the restriction. If a specific flow requires external entities, isolate that parser instance and treat its input as untrusted until you can replace the DTD dependency.

Closing checklist

• Identify every XML consumer in your application, including SOAP, SAML, RSS readers, and document uploads.
• Disable external general and parameter entities at the parser factory or reader level.
• Enable secure-processing mode where the parser supports it.
• Verify with an external-entity test document and programmatic feature inspection.
• Regression-test legitimate DTD and schema workflows before deploying.