Documentation Contents

# Java API for XML Processing (JAXP) Security Guide

The JDK and Java XML APIs have been improved over the years with various measures and tools that can help prevent applications from being exploited by XML-related attacks. This guide shows you how to use the secure processing features of Java API for XML Processing (JAXP) to safeguard your applications and systems.

## Topics

- Potential Attacks During XML Processing
  - XML External Entity Injection Attack
    - External Resources Supported by XML, Schema, and XSLT Standards
  - Exponential Entity Expansion Attack
- Configuring JAXP for Secure XML Processing
  - Secure XML Processing Best Practices
  - JAXP APIs
  - Factories and Processors
  - Configuring with JAXP Properties
    - Setting JAXP Properties Through JAXP Factories
    - Setting JAXP Properties as System Properties
    - Setting JAXP Properties in a JAXP Configuration File
    - Scope and Order of Setting JAXP Properties
  - Security-Related Properties
    - API-Defined Properties
      - The FEATURE_SECURE_PROCESSING Security Directive
        - JAXP Property Precedence and FEATURE_SECURE_PROCESSING
      - External Access Properties
        - When to Use External Access Properties
        - JAXP Property Precedence and External Access Properties
    - JDK-Specific Properties
      - JAXP Properties for Processing Limits
        - Legacy System Properties
        - FEATURE_SECURE_PROCESSING Default Limitations
        - Limiting Entity Expansion
        - Limiting the Number of Element Attributes
        - Limiting the Number of Nodes Created by Constructs That Contain maxOccurs
        - When to Use Processing Limits
          - Memory Setting and Limits
          - Estimating the Limits Using the getEntityCountInfo Property
      - Extension Functions
      - Third-Party Parsers
      - Disabling DTD Processing
  - Composite Processors
  - Using Java XML Resolvers
    - Entity Resolvers for SAX and DOM
    - XMLResolver for StAX
    - URIResolver for javax.xml.transform
    - LSResourceResolver for javax.xml.validation
- Relationship with Security Manager
- Handling Errors from JAXP Properties
- Streaming API for XML and JAXP Properties
  - StAX and Processing Limits
  - StAX and External Access Properties
- General Recommendations for JAXP Security
- Appendix A: Glossary of Java API for XML Processing Terms and Definitions
- Appendix B: Java and JDK XML Features and Properties Naming Convention

## Potential Attacks During XML Processing

XML processing can expose applications to certain vulnerabilities. Among the most prominent and well-known attacks are the XML External Entity (XXE) injection attack and the exponential entity expansion attack, also know as the XML bomb or billion laughs attack. These attacks can potentially cause serious damage to a system by denying its services or worse, lead to the loss of sensitive data.

You should evaluate your applications' requirements and operating environment to assess the level of potential threat, for example, whether or to what extent the applications are exposed to untrusted XML sources.

### XML External Entity Injection Attack

The XML, XML Schema, and XSLT standards define a number of structures that enable the embedding of external content in XML documents through system identifiers that reference external resources. In general, XML processors resolve and retrieve almost all of these external resources; see External Resources Supported by XML, Schema, and XSLT Standards for a list of constructs that support the inclusion of external resources. In addition, some constructs enable the execution of applications through external functions. XML External Entity (XXE) injection attacks exploit XML processors that have not been secured by restricting the external resources that it may resolve, retrieve, or execute. This can result in disclosing sensitive data such as passwords or enabling arbitrary execution of code.

#### External Resources Supported by XML, Schema, and XSLT Standards

XML, Schema, and XSLT standards support the following constructs that require external resources. The default behavior of the JDK XML processors is to make a connection and fetch the external resources as specified.

- External DTD: references an external Document Type Definition (DTD), for example:

      <!DOCTYPE root_element SYSTEM "url">

- External Entity Reference: Refers to external data, the following is the syntax:

      <!ENTITY name SYSTEM "url">

- General entity reference, for example:

      <?xml version="1.0" standalone="no" ?>
      <!DOCTYPE doc [<!ENTITY otherFile SYSTEM "otherFile.xml">]>
      <doc>
          <a>
              <b>&otherFile;</b>
          </a>
      </doc>

- External Parameter Entities: The following is the syntax:

      <!ENTITY % name SYSTEM uri>

  The following is an example:

      <?xml version="1.0" standalone="no"?>
          <!DOCTYPE doc [
            <!ENTITY % ent1 SYSTEM "http://www.example.com/student.dtd">
            %ent1;
          ]>

- XInclude: Includes an external infoset in an XML document, for example:

      <Book xmlns:xi="http://www.w3.org/2001/XInclude">
          <xi:include href=toc.xml"/>
          <xi:include href=part1.xml"/>
          <xi:include href=part2.xml"/>
          <xi:include href=index.xml"/>
      </Book>

- References to XML Schema components using the `schemaLocation` attribute and `import` and `include` elements, for example:

      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
          <xs:include schemaLocation="http://www.example.com/schema/schema1.xsd"/>
          <!-- ... -->
      </xs:schema>

- Combining style sheets using import or include elements, the following is the syntax:

      <xsl:include href="include.xsl"/>

- `xml-stylesheet` processing instruction: Used to include a stylesheet in an XML document, for example:

      <?xml-stylesheet href="include.xsl" type="text/xsl"?>

- XSLT `document()` function: Used to access nodes in an external XML document, for example:

      <xsl:variable select="document('DocumentFunc2.xml')"/>

### Exponential Entity Expansion Attack

The exponential entity expansion attack, also know as the XML bomb or billion laughs attack, is a denial-of-service attack that involves XML parsers. The basic exploit is to have several layers of nested entities, each referring to a number of entities of the next layer. The following is a sample SOAP document that contains deeply nested entity references:

    <?xml version="1.0" encoding ="UTF-8"?>
    <!DOCTYPE bbb[
        <!ENTITY x100 "bbb">
        <!ENTITY  x99 "&x100;&x100;">
        <!ENTITY  x98 "&x99;&x99;">
        ...
        <!ENTITY   x2 "&x3;&x3;">
        <!ENTITY   x1 "&x2;&x2;">
    ]>
    <SOAP-ENV:Envelope xmlns:SOAP-ENV=...>
        <SOAP-ENV:Body>
            <ns1:aaa xmlns:ns1="urn:aaa" SOAP-ENV:encodingStyle="...">
                <foobar xsi:type="xsd:string">&x1;</foobar>
            </ns1:aaa>
        </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>

When an XML parser encounters such a document, it will attempt to resolve the entity declaration by expanding the references. Because the references are nested, the expansion becomes exponential by the number of entities each refers to. Such a process can lead the XML parser to consume 100% of CPU time and a large amount of memory, and eventually the system runs out of memory.

## Configuring JAXP for Secure XML Processing

JAXP consists of a set of APIs for parsing, serializing, transforming, querying, and traversing XML documents. See JAXP APIs.

JAXP adds a layer of security through factories and processors. You access APIs from JAXP through factories, which ensure that they are configured according to JAXP properties that you've set based on your security requirements. You configure and instantiate factories with their respective processors. See Factories and Processors.

You configure JAXP processors through JAXP properties. You can set JAXP properties through JAXP factories, as System properties, or in a JAXP configuration file. See Configuring with JAXP Properties.

The section Security-Related Properties describes properties you can set to configure JAXP for secure XML processing.

The section Composite Processors describes how enabling `FEATURE_SECURE_PROCESSING` (FSP) for a composite processor such as a validator or transformer also enables FSP for any internal parser that the composite processor uses.

In addition, JAXP enables you to register custom resolvers, which intercept references to external resources and resolve them with local ones. This eliminates the need to read and access external resources, which helps remove a source of potential risk. See Using Java XML Resolvers.

### Secure XML Processing Best Practices

The JDK supports JAXP `FEATURE_SECURE_PROCESSING` (FSP) (see The FEATURE_SECURE_PROCESSING Security Directive), which enables a baseline of secure XML processing by imposing key restrictions through various features and properties (see Configuring with JAXP Properties). When FSP is enabled on XML factories by default or by explicit settings, the JDK applies restrictive values to relevant security properties. You can also directly set these properties through API calls or system properties. You can also centrally manage them in the JAXP Configuration File (JCF) (see Setting JAXP Properties in a JAXP Configuration File).

#### Key Security Configurations

- FEATURE_SECURE_PROCESSING (FSP)

  Securing your XML applications starts with enabling the FSP directive on XML factories (such as DOM, SAX, validation, transformation, and XPath). See The FEATURE_SECURE_PROCESSING Security Directive. While the JDK applies most secure defaults, it does not restrict external connections by default, so explicit configuration is necessary. The following code, for example, sets FSP on a DOM factory:

      DocumentBuilderFactory factory = DocumentBuilderFactory.newDefaultNSInstance();
      factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

  The explicit FSP setting enforces resource limits (see JAXP Properties for Processing Limits), disables external entity resolution (see External Access Properties), prevents use of third-party parser overrides (see Third-Party Parsers), and restricts XSLT extension functions (see Extension Functions).

- JAXP Configuration File (JCF)

  You can set security-related JAXP properties (see Configuring with JAXP Properties) programmatically, through system properties, or by using the JAXP Configuration File (JCF) (see Setting JAXP Properties in a JAXP Configuration File). Using the JCF provides a convenient, code-free means of managing security settings across all XML processor instances in the JVM.

- External Access Restrictions

  Preventing arbitrary external access is essential for XML security. This can be achieved by setting FSP on XML factories or, where more granular control is necessary, by configuring External Access Properties (EAP) (see External Access Properties). Note that for the StAX processor (see the `javax.xml.stream` package), FSP is not supported, so EAPs must be used.

- Resolvers

  Restricting all external access may be too limiting for some applications. To safely handle external resources, implement resolvers (see Using Java XML Resolvers). These mechanisms allow fine-grained control over how external references are resolved while blocking unwanted connections.

Note: While FSP is enabled by default in the JDK, the default configuration does not restrict external entity resolution. For comprehensive security, explicitly set FSP through the API and configure external access restrictions as needed.

### JAXP APIs

JAXP consists of a set of APIs built XML technologies and standards that are essential for XML processing. These include APIs for the following:

- Parsing: JAXP Parsing API (`javax.xml.parsers` package, which is based on the Document Object Model (DOM) (`org.w3c.dom` package) and Simple API for XML Parsing (SAX) (`org.xml.sax` package)
- Streaming API for XML (StAX) (`javax.xml.stream` package)
- Serializing: StAX and Extensible Stylesheet Language Transformations (XSLT) (`javax.xml.transform` package)
- Transformation: JAXP Transformation API (`javax.xml.transform` package) and XSLT (Extensible Stylesheet Language Transformations)
- Querying and traversing XML documents: XML Path Language (XPath) API (`javax.xml.xpath` package)

### Factories and Processors

Factories are the entry points of each JAXP API. They provide methods that enable applications to set JAXP properties programmatically before creating processors. Factories also support the JAXP lookup mechanism, which enable you to deploy applications with third-party implementations instead of JDK implementations.

Processors are aggregates of parsers (or readers), serializers (or writers), validators, and transformers that control and perform the processing in their respective areas. Factories configure and instantiate their corresponding factories. For example, you configure and instantiate the `DocumentBuilder` and `SAXParser` processors with the `DocumentBuilderFactory` and `SAXParserFactory` factories, respectively.

### Configuring with JAXP Properties

You configure JAXP processors through JAXP properties. The following lists the ways you can set JAXP properties in order of precedence from highest to lowest. For example, if you set a JAXP property's value through a factory, then it will override any other value set in a different way.

- Setting JAXP Properties Through JAXP Factories: You can set a JAXP property through a JAXP factory in your code.

- Setting JAXP Properties as System Properties: You can set a JAXP property like a System property by setting its value on the command line with the following syntax:

      -D<property name>=<property value>

  You can also set a System property's value with the method `System.setProperty(String key, String name)` or `System.setProperties(Properties)`.

- Setting JAXP Properties in a JAXP Configuration File: You can set a JAXP property in a user-defined JAXP configuration file named `<java-home>/lib/jaxp.properties`.

Note: Not all JAXP properties can be set by all of these ways.

#### Setting JAXP Properties Through JAXP Factories

If you can modify your application's code, or you're creating a new application, then setting JAXP properties through JAXP factories or a parser is the preferred method. Set these properties through the following interfaces:

    DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
    dbf.setAttribute(name, value);

    SAXParserFactory spf = SAXParserFactory.newInstance();
    SAXParser parser = spf.newSAXParser();
    parser.setProperty(name, value);

    SchemaFactory schemaFactory = SchemaFactory.newInstance(schemaLanguage);
    schemaFactory.setProperty(name, value);

    TransformerFactory factory = TransformerFactory.newInstance();
    factory.setAttribute(name, value);

    XMLInputFactory xif = XMLInputFactory.newInstance();
    xif.setProperty(name, value);

    XPathFactory xf = XPathFactory.newInstance();
    xf.setProperty(name, value);

The following is an example of setting processing limits:

    dbf.setAttribute("http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit", "2000");

    dbf.setAttribute("http://www.oracle.com/xml/jaxp/properties/maxGeneralEntitySizeLimit", "100000");

    dbf.setAttribute("http://www.oracle.com/xml/jaxp/properties/maxParameterEntitySizeLimit", "10000");

    dbf.setAttribute("http://www.oracle.com/xml/jaxp/properties/maxElementDepth", "100");

    factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");
    xf.setProperty("jdk.xml.xpathExprGrpLimit", "20");

The following is an example of limiting a DOM parser to only local connections for external DTDs:

    dbf.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "file, jar:file");

If a parser module within the application handles untrusted sources, it may further restrict access. The following code overrides those in the `jaxp.properties` file and those specified by System properties and enables the XML processor to read local files only:

    DocumentBuilderFactory dbf =
    DocumentBuilderFactory.newInstance();
    dbf.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "file");

    // ...

    SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
    schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "file");
    schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "file");

As described in Scope and Order of Setting JAXP Properties, JAXP properties specified through JAXP factories have the narrowest scope, affecting only the processors created by the factories, and therefore override any default settings, System properties, and those in the `jaxp.properties` file. By setting JAXP properties through JAXP factories, you can ensure that your applications behave the same way regardless of which JDK release you're using or whether JAXP properties are set through other means.

#### Setting JAXP Properties as System Properties

System properties may be useful if you can't modify your application's code.

To set JAXP properties for an entire JDK invocation, set their corresponding System properties on the command line.

To set JAXP properties for only a portion of the application, set their corresponding System properties before the portion, and then clear them afterward. For example, if your application requires access to external DTDs and schemas, then add these lines to your application's initialization code block:

    System.setProperty("javax.xml.accessExternalDTD", "file, http");
    System.setProperty("javax.xml.accessExternalSchema", "file, http");

Then, once your application is done processing XML documents or before it exits, clear out the properties as follows:

    System.clearProperty("javax.xml.accessExternalDTD");
    System.clearProperty("javax.xml.accessExternalSchema");

The following code, from Processing Limit Samples in The Java Tutorials, is another example that shows how to do this for the processing limit `maxGeneralEntitySizeLimit`:

    public static final String SP_GENERAL_ENTITY_SIZE_LIMIT =
        "jdk.xml.maxGeneralEntitySizeLimit";

    // Set limits using System property;
    // this setting will affect all processing after it's set
    System.setProperty(SP_GENERAL_ENTITY_SIZE_LIMIT, "2000");

    // Perform some processing here

    // After it is done, clear the property
    System.clearProperty(SP_GENERAL_ENTITY_SIZE_LIMIT);

Note: Processing limit values are integers. A `NumberFormatException` is thrown if a processing limit's value is not a parsable integer; see the method `java.lang.Integer.parseInt(String)`.

The following example allows the resolution of external schemas for a portion of an application:

    // Allow resolution of external schemas
    // This setting will affect all processing after it's set
    System.setProperty("javax.xml.accessExternalSchema", "file, http");

    // Perform some processing here

    // After it's done, clear the property
    System.clearProperty("javax.xml.accessExternalSchema");

#### Setting JAXP Properties in a JAXP Configuration File

If you want to specify a JAXP property that affects every JDK invocation, then create a configuration file named `<java-home>/lib/jaxp.properties` and specify names and values of JAXP properties in it, one name-value pair on each line. For example, the following `jaxp.properties` file sets the `maxGeneralEntitySizeLimit` processing limit property to 2000 and restricts access to the file and HTTP protocols for external references set by the `stylesheet` processing instruction, `document` function, and the `import` and `include` elements.

    jdk.xml.maxGeneralEntitySizeLimit=2000
    javax.xml.accessExternalStylesheet=file, http

If you don't want to allow any external connection by XML processors, you can set all access external restrictions to `file` only:

    javax.xml.accessExternalDTD=file
    javax.xml.accessExternalSchema=file
    javax.xml.accessExternalStylesheet=file

If you want to prevent applications from accidentally reading external files through an XML processor, set the external access restrictions as follows in the `jaxp.properties` file as follows:

    javax.xml.accessExternalDTD=""
    javax.xml.accessExternalSchema=""
    javax.xml.accessExternalStylesheet=""

Note:

- Use the corresponding System property in the `jaxp.properties` file. Processing limit System properties have the prefix `jdk.xml`. External access restriction System properties have the prefix `javax.xml`.
- Processing limit values are integers. A `NumberFormatException` is thrown if a processing limit's value is not a parsable integer; see the method `java.lang.Integer.parseInt(String)`.

#### Scope and Order of Setting JAXP Properties

JAXP properties can be set in multiple ways, including through API methods, in system properties, and in the JAXP configuration file. When not explicitly set, they will be initialized with default values or more restrictive values when `FEATURE_SECURE_PROCESSING` (FSP) is enabled. The order of precedence for properties is as follows, from highest to lowest:

- The APIs for factories or processors
- System properties
- The JAXP configuration file, `<java-home>/lib/jaxp.properties`
- The default values for JAXP properties; if FSP is true, then the default values will be set to process XML securely

Using the `jdk.xml.entityExpansionLimit` property as an example, the following illustrates how these rules are applied:

- Properties specified through factory or processor APIs have the highest precedence. The following code effectively sets the `jdk.xml.entityExpansionLimit` property to 2000 regardless of settings in any other configuration sources.

      DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
      dbf.setAttribute("http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit", "2000");

- If the property is not set by the factory as in the previous example, a system property setting will be in effect. The following command-line example sets the `jdk.xml.entityExpansionLimit` property to 2000 for the application `myApp`:

      java -Djdk.xml.entityExpansionLimit=2000 myApp

- If the property is not set by the factory or in a system property, the setting in the JAXP configuration file, `<java-home>/lib/jaxp.properties`, will take effect. The following entry sets the `jdk.xml.entityExpansionLimit` property to 2000.

      jdk.xml.entityExpansionLimit=2000

- If the value of the `jdk.xml.entityExpansionLimit` property is not set anywhere, it will be resolved to its default value, 64000.

### Security-Related Properties

The following sections describe the properties you can set to configure JAXP for secure XML processing. There are two kinds of JAXP security-related properties:

- API-Defined Properties: These are constant field values that are part of the Java SE API whose values you set through a factory's or parser's `setAttribute(String, Object)` or `setProperty(String, Object)` method. Some of these fields have corresponding system properties you can set on the command line or in a JAXP configuration file:
  - The FEATURE_SECURE_PROCESSING Security Directive
  - External Access Properties
- JDK-Specific Properties: These are system properties you set through JAXP parsers or factories, on the command line, or in a JAXP configuration file. Some of these aren't system properties, which means you can't set their values on the command line:
  - JAXP Properties for Processing Limits
  - Extension Functions
  - Third-Party Parsers
  - Disabling DTD Processing

#### API-Defined Properties

##### The FEATURE_SECURE_PROCESSING Security Directive

The `FEATURE_SECURE_PROCESSING` (FSP) directive, defined by the JAXP API, signals the intent to enforce security restrictions during XML document processing. When set to true using a JAXP factory as follows, it instructs the JAXP processor (for example, a parser or validator) to apply security controls based on the processor's security model:

    factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

By default, the JDK turns FSP on for SAX, DOM, and validation factories. However, external connections (such as external entity resolution or resource access) are not disabled by default. To ensure external access is properly restricted, FSP needs to be explicitly set as shown previously.

Note: When a Security Manager is present, JAXP security processing is turned on automatically.

###### JAXP Property Precedence and FEATURE_SECURE_PROCESSING

FSP is required for XML processors including DOM, SAX, schema validation, XSLT, and XPath.

When FSP is turned on, then default processing limits (see JAXP Properties for Processing Limits) are enforced. Turning off FSP does not change the limits.

When FSP is "explicitly" turned on through the API, for example, `factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true)`, then External Access Properties (EAPs) are set to the empty string, which means that no permission is granted to any protocol. Although FSP is turned on by default for DOM, SAX and schema validation, it is not treated as if "explicitly" turned on; therefore, the default value for EAPs is `all`, which means that permission is granted to all protocols.

When a Java Security Manager is present, FSP is turned on and cannot be turned off.

##### External Access Properties

External Access Properties (EAPs), along with their corresponding System properties, enable you to regulate external connections.

EAPs enable you to specify the type of external connections that can or cannot be permitted. The property values are a list of protocols. The JAXP processors check if a given external connection is permitted by matching the protocol with those in the list. Processors will attempt to establish the connection if it is on the list, or reject it if not. Use EAPs along with custom resolvers (see Using Java XML Resolvers) to reduce the risk of external connections by rejecting and resolving them with local resources.

Note: External connections are allowed even when FSP is on by default. Explicitly turning on FSP through the API, for example, `factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true)`, is necessary to disable all external connections.

EAPs are defined in `javax.xml.XMLConstants` as follows:

- `javax.xml.XMLConstants.ACCESS_EXTERNAL_DTD`
- `javax.xml.XMLConstants.ACCESS_EXTERNAL_SCHEMA`
- `javax.xml.XMLConstants.ACCESS_EXTERNAL_STYLESHEET`

###### ACCESS_EXTERNAL_DTD

Attribute | Description
--- | ---
Name | `http://javax.xml.XMLConstants/property/accessExternalDTD`
Definition | Restricts access to external DTDs and external entity references to the protocols specified.
Value | See Values of External Access Properties
Default value | all, connection permitted to all protocols
System property | `javax.xml.accessExternalDTD`

###### ACCESS_EXTERNAL_SCHEMA

Attribute | Description
--- | ---
Name | `http://javax.xml.XMLConstants/property/accessExternalSchema`
Definition | Restricts access to the protocols specified for external references set by the `schemaLocation` attribute, `import` element, and `include` element.
Value | See Values of External Access Properties
Default value | all, connection permitted to all protocols.
System property | `javax.xml.accessExternalSchema`

###### ACCESS_EXTERNAL_STYLESHEET

Attribute | Description
--- | ---
Name | `http://javax.xml.XMLConstants/property/accessExternalStylesheet`
Definition | Restricts access to the protocols specified for external references set by the `stylesheet` processing instruction, `document` function, and `import` and `include` elements.
Value | See Values of External Access Properties
Default value | all, connection permitted to all protocols.
System property | `javax.xml.accessExternalStylesheet`

###### Values of External Access Properties

All EAPs have values of the same format:

- Value: A list of protocols separated by comma. A protocol is the scheme portion of an URI, or in the case of the JAR protocol, `jar` plus the scheme portion separated by colon. A scheme is defined as:

  `scheme = alpha *( alpha | digit | "+" | "-" | "." )`

  where `alpha` = `a-z` and `A-Z`.

  The JAR protocol is defined as: `jar[:scheme]`

  Protocols are case-insensitive. Any whitespace characters as defined by `Character.isSpaceChar` in the value are ignored. Examples of protocols are `file`, `http`, and `jar:file`.

- Default value: The default value is implementation specific. For the JDK, the default value is `all`, which grants permissions to all protocols.

- Granting all access: The keyword `all` grants permission to all protocols. For example, specifying `javax.xml.accessExternalDTD=all` in the `jaxp.properties` file enables a system to work as before with no restrictions on accessing external DTDs and entity references.

- Denying any access: An empty string (`""`) means that no permission is granted to any protocol. For example, specifying `javax.xml.accessExternalDTD=""` in the `jaxp.properties` file instructs JAXP processors to deny any external connections.

##### When to Use External Access Restrictions

The XML processors, by default, attempt to connect and read external resources that are referenced in XML sources.

Note: This may potentially expose applications and systems to risks posed by external connections. It's therefore recommended that applications consider limiting external connections with EAPs.

Internal applications and systems that handle only trusted XML documents may not need these restrictions. Applications and systems that rely on the Java Security Manager to regulate external connections may also have no need for them. However, keep in mind that EAPs are specific to the XML processors and at the top layer of the process, which means that the processors check these EAPs before any connections are made. They may therefore serve as an additional and more direct protection against external connection risks.

You can use EAPs along with custom resolvers (see Using Java XML Resolvers) to effectively manage external connections and reduce risks.

Even in a trusted environment with trusted sources, it's recommended that you use both EAPs and resolvers to minimize dependencies on external sources.

##### JAXP Property Precedence and External Access Properties

EAPs have no effect on the relevant constructs that they attempt to restrict in the following situations:

- When there is a resolver and the source returned by the resolver is not null: This applies to entity resolvers that may be set on SAX and DOM parsers, XML resolvers on StAX parsers, `LSResourceResolver` on `SchemaFactory`, a `Validator` or `ValidatorHandler`, or `URIResolver` on a transformer.

- When a schema is created explicitly by calling the `newSchema` method from `SchemaFactory`.

- When external resources are not required: For example, the following features and properties are supported by the JDK and may be used to instruct the processor to not load the external DTD or resolve external entities:

      http://apache.org/xml/features/disallow-doctype-decl true
      http://apache.org/xml/features/nonvalidating/load-external-dtd false
      http://xml.org/sax/features/external-general-entities false
      http://xml.org/sax/features/external-parameter-entities false

#### JDK-Specific Properties

##### JAXP Properties for Processing Limits

XML processing can sometimes be a memory intensive operation. Applications, especially those that accept XML, XSD and XSL from untrusted sources, should take steps to guard against excessive memory consumption by using JAXP properties for processing limits.

Evaluate your application's requirements and operating environment to determine the acceptable processing limits for your system configurations and set these limits accordingly. For example, use size-related limits to prevent malformed XML sources from consuming large amounts of memory. Use `EntityExpansionLimit` to enable an application to control memory consumption under an acceptable level.

The JDK XML parsers observe processing limits by default. Both DOM and SAX parsers have Feature for Secure Processing (FSP) turned on by default and therefore turn on the limits. The StAX parser also observes processing limits by default even though it doesn't support FSP.

The JDK XML processors enable you to adjust processing limits individually in three ways:

- Through standard XML APIs
- By using System properties
- In the `jaxp.properties` file

See Configuring with JAXP Properties and Scope and Order of Setting JAXP Properties.

The following table describes the JAXP properties for processing limits supported in the JDK.

Property Name | System Property | Description | Default Value
--- | --- | --- | ---
`http://www.oracle.com/xml/jaxp/properties/elementAttributeLimit` | `jdk.xml.elementAttributeLimit` | Limits the number of attributes an element can have. | 10000
`http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit` | `jdk.xml.entityExpansionLimit` | Limits the number of entity expansions. | 64000
`http://www.oracle.com/xml/jaxp/properties/entityReplacementLimit` | `jdk.xml.entityReplacementLimit` | Limits the total number of nodes in all entity references. | 3000000
`http://www.oracle.com/xml/jaxp/properties/maxElementDepth` | `jdk.xml.maxElementDepth` | Limits the maximum element depth. | 0
`http://www.oracle.com/xml/jaxp/properties/maxGeneralEntitySizeLimit` | `jdk.xml.maxGeneralEntitySizeLimit` | Limits the maximum size of any general entities. | 0
`http://www.oracle.com/xml/jaxp/properties/maxOccurLimit` | `jdk.xml.maxOccurLimit` | Limits the number of content model nodes that may be created when building a grammar for a W3C XML Schema that contains `maxOccurs` attributes with values other than "unbounded". | 5000
`http://www.oracle.com/xml/jaxp/properties/maxParameterEntitySizeLimit` | `jdk.xml.maxParameterEntitySizeLimit` | Limits the maximum size of any parameter entities, including the result of nesting multiple parameter entities. | 1000000
`http://www.oracle.com/xml/jaxp/properties/maxXMLNameLimit` | `jdk.xml.maxXMLNameLimit` | Limits the maximum size of XML names, including element name, attribute name and namespace prefix and URI. | 1000
`http://www.oracle.com/xml/jaxp/properties/totalEntitySizeLimit` | `jdk.xml.totalEntitySizeLimit` | Limits the total size of all entities that include general and parameter entities. The size is calculated as an aggregation of all entities. | 5x10^7
`jdk.xml.xpathExprGrpLimit` | `jdk.xml.xpathExprGrpLimit` | Limits the number of groups an XPath expression can contain. | 10
`jdk.xml.xpathExprOpLimit` | `jdk.xml.xpathExprOpLimit` | Limits the number of operators an XPath expression can contain. | 100
`jdk.xml.xpathTotalOpLimit` | `jdk.xml.xpathTotalOpLimit` | Limits the total number of XPath operators in an XSL Stylesheet. | 100000

###### Legacy System Properties

These properties, which were introduced in JDK 5.0 and 6, continue to be supported for backward compatibility.

System Property | Since | New System Property
--- | --- | ---
`entityExpansionLimit` | 1.5 | `jdk.xml.entityExpansionLimit`
`elementAttributeLimit` | 1.5 | `jdk.xml.elementAttributeLimit`
`maxOccurLimit` | 1.6 | `jdk.xml.maxOccur`

###### FEATURE_SECURE_PROCESSING Default Limitations

The following table describes which XML-related factory classes are disabled and which processing limits are set if `FEATURE_SECURE_PROCESSING` (FSP) is enabled.

XML-Related Factory Class | Enabled? | Processing Limits
--- | --- | ---
`DocumentBuilderFactory` | true | `jdk.xml.entityExpansionLimit = 64000` `jdk.xml.elementAttributeLimit = 1000` `jdk.xml.maxOccurLimit = 5000`
`SAXParserFactory` | true | `jdk.xml.entityExpansionLimit = 64000` `jdk.xml.elementAttributeLimit = 10000` `jdk.xml.maxOccurLimit = 5000`
`SchemaFactory` | true | `jdk.xml.maxOccurLimit = 5000`
`TransformerFactory` | false | Extension functions disabled
`XPathFactory` | false | Extension functions disabled

###### Limiting Entity Expansion

Limit the number of entity expansions by either setting the system property `jdk.xml.entityExpansionLimit` or the parser property `http://apache.org/xml/properties/entity-expansion-limit`. Both properties accept `java.lang.Integer` values. The parser throws a fatal error once it has reached the entity expansion limit. By default, `entityExpansionLimit` is set to 64,000.

The following command-line example sets the entity expansion limit to 10,000:

    java -DentityExpansionLimit=10000 MyApp

The following code example sets the entity expansion limit to 10,000:

    System.setProperty("jdk.xml.entityExpansionLimit","10000");

The following code example sets the parser property `http://apache.org/xml/properties/entity-expansion-limit`to 10,000:

    DocumentBuilderFactory dfactory = DocumentBuilderFactory.newInstance();
    dfactory.setAttribute(
            "http://apache.org/xml/properties/entity-expansion-limit",
            new Integer("10000"));
    DocumentBuilder docBuilder = dbFactory.newDocumentBuilder();

###### Limiting the Number of Element Attributes

Limit the number of attributes in an element by either setting the system property `jdk.xml.elementAttributeLimit` or by setting the parser property `http://apache.org/xml/properties/elementAttributeLimit`. Both properties accept `Integer` values. By default, `jdk.xml.elementAttributeLimit` is set to 10,000. When the parser property `http://apache.org/xml/properties/elementAttributeLimit` is set, it overrides the system property. The parser throws a fatal error if the number of attributes in a element exceeds the limit.

The following command-line example sets the element attribute limit to 20:

    java -Djdk.xml.elementAttributeLimit=20 MyApp

The following code example sets the element attribute limit to 20:

    System.setProperty("jdk.xml.elementAttributeLimit","20");

The following code example sets the parser property `http://apache.org/xml/properties/entity-expansion-limit` to 20:

    DocumentBuilderFactory dfactory = DocumentBuilderFactory.newInstance();
    dfactory.setAttribute(
        "http://apache.org/xml/properties/elementAttributeLimit",
        new Integer(20));
    DocumentBuilder docBuilder = dbFactory.newDocumentBuilder();

###### Limiting the Number of Nodes Created by Constructs That Contain maxOccurs

In constructs like `xsd:sequence`, the validating parser may use space (memory) proportional to the value of the `maxOccurs` occurrence indicator. This may cause the VM to run out of memory, or simply run for a very long time. To prevent potential attacks that exploit this behavior, enable secure processing on a factory as follows:

    factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, Boolean.TRUE);

Note: that for `xsd:element` and `xsd:any`, the validating parser uses a constant amount of space, which is independent of the value of the `maxOccurs` occurrence indicator.

The default value of `jdk.xml.maxOccurLimit` is 5000. This system property limits the number of content model nodes that may be created when building a grammar for a W3C XML Schema that contains maxOccurs occurrence indicators with values other than "unbounded".

###### When to Use Processing Limits

When determining which processing limits to apply and what values to use, at the system level, consider the amount of memory available for applications and whether XML, XSD, or XSL sources from untrusted sources are accepted and processed. At the application level, consider whether certain constructs such as DTDs are used.

Memory Setting and Limits

XML processing can be very memory intensive. The amount of memory that should be allowed to be consumed depends on the requirements of the applications in a specific environment. Processing of malformed XML data must be prevented from consuming excessive memory.

The default limits are generally set to allow legitimate XML inputs for most applications with memory usage allowed for a small hardware system, such as a PC. It is recommended that the limits are set to the smallest possible values, so that any malformed input can be caught before it consumes large amounts of memory.

The limits are correlated, but not entirely redundant. You should set appropriate values for all of the limits: usually the limits should be set to a much smaller value than the default.

For example, `ENTITY_EXPANSION_LIMIT` and `GENERAL_ENTITY_SIZE_LIMIT` can be set to prevent excessive entity references. But when the exact combination of the expansion and entity sizes are unknown, `TOTAL_ENTITY_SIZE_LIMIT` can serve as a overall control. Similarly, while `TOTAL_ENTITY_SIZE_LIMIT` controls the total size of a replacement text, if the text is a very large chunk of XML, `ENTITY_REPLACEMENT_LIMIT` sets a restriction on the total number of nodes that can appear in the text and prevents overloading the system.

Estimating the Limits Using the getEntityCountInfo Property

To help you analyze what values you should set for the limits, a special property called `http://www.oracle.com/xml/jaxp/properties/getEntityCountInfo` is available. The following code snippet, from Processing Limit Samples in The Java Tutorials, shows an example of using the property:

    public static final String ORACLE_JAXP_PROPERTY_PREFIX =
        "http://www.oracle.com/xml/jaxp/properties/";
    // ...
    public static final String JDK_ENTITY_COUNT_INFO =
        ORACLE_JAXP_PROPERTY_PREFIX + "getEntityCountInfo";
    // ...
    parser.setProperty(JDK_ENTITY_COUNT_INFO, "yes");

When you run the processing limit sample with the DTD in W3C MathML 3.0, it prints out the following table:

Property | Limit | Total Size | Size | Entity Name
--- | --- | --- | --- | ---
`ENTITY_EXPANSION_LIMIT` | 64000 | 1417 | 0 | null
`MAX_OCCUR_NODE_LIMIT` | 5000 | 0 | 0 | null
`ELEMENT_ATTRIBUTE_LIMIT` | 10000 | 0 | 0 | null
`TOTAL_ENTITY_SIZE_LIMIT` | 50000000 | 55425 | 0 | null
`GENERAL_ENTITY_SIZE_LIMIT` | 0 | 0 | 0 | null
`PARAMETER_ENTITY_SIZE_LIMIT` | 1000000 | 0 | 7303 | `%MultiScriptExpression`
`MAX_ELEMENT_DEPTH_LIMIT` | 0 | 2 | 0 | null
`MAX_NAME_LIMIT` | 1000 | 13 | 13 | null
`ENTITY_REPLACEMENT_LIMIT` | 3000000 | 0 | 0 | null

In this example, the total number of entity references, or the entity expansion, is 1417; the default limit is 64000. The total size of all entities is 55425; the default limit is 50000000. The biggest parameter entity is `%MultiScriptExpression` with a length of 7303 after all references are resolved; the default limit is 1000000.

If this is the largest file that the application is expected to process, it is recommended that the limits be set to smaller numbers. For example, 2000 for `ENTITY_EXPANSION_LIMIT`, 100000 for `TOTAL_ENTITY_SIZE_LIMIT`, and 10000 for `PARAMETER_ENTITY_SIZE_LIMIT`.

##### Extension Functions

Because FSP is off by default for `Transformer` and `XPath`, extension functions are allowed. For applications processing documents from untrusted sources, it is recommended to turn off the extension functions feature. There are two ways to do so:

- By setting FSP to true, for example:

      TransformerFactory tf = TransformerFactory.newInstance();
      tf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

- By setting the `enableExtensionFunctions` property to false:

      final static String ENABLE_EXTENSION_FUNCTIONS =
          "http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions";
      // ...
      TransformerFactory tf = TransformerFactory.newInstance();
      tf.setFeature(ENABLE_EXTENSION_FUNCTIONS, false);

In cases where extension functions are disabled as a result of installing a Java Security Manager, applications may also choose to re-enable the extension functions feature by setting the property `enableExtensionFunctions` to true. The following table defines this property:

###### enableExtensionFunctions

Attribute | Description
--- | ---
Name | `http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions`
Definition | Determines whether XSLT and XPath extension functions are allowed.
Value | A boolean. True indicates that extension functions are allowed; False otherwise.
Default value | true
System property | `jdk.xml.enableExtensionFunctions`
Since | 7u60

##### Third-Party Parsers

The JDK will always use its system-default parser even when there's a third-party parser on the classpath. To override the JDK system-default parser, set the `jdk.xml.overrideDefaultParser` property to true.

###### overrideDefaultParser

Attribute | Description
--- | ---
Name | `jdk.xml.overrideDefaultParser`
Definition | Enables the use of a third-party's parser implementation to override the system-default parser for the JDK's `Transformer`, `Validator`, and `XPath` implementations. The property can be set through JAXP factories, System properties, or the `jaxp.properties` file.
Value | A boolean. Setting it to true enables third-party parser implementations to override the system-default implementation during XML transformation, XML validation, or XPath operations. Setting it to false disables the use of third-party parser implementations. When the value is specified as a String, the returning value will be that of `Boolean.parseBoolean`.
Default value | false
System property | `jdk.xml.overrideDefaultParser`
Since | 6u181, 7u171, 8u161, 9.0.4

###### Example of Using a Third-Party Parser

The following code snippets instruct the factories to use a third-party parser, if found on the classpath, by setting the `jdk.xml.overrideDefaultParser` property with the `setFeature` method:

    static final String JDK_OVERRIDE_PARSER = "jdk.xml.overrideDefaultParser";
    // ...
    TransformerFactory tFactory = TransformerFactory.newInstance();
    tFactory.setFeature(JDK_OVERRIDE_PARSER, true);
    // ...
    XPathFactory xf = XPathFactory.newInstance();
    xf.setFeature(JDK_OVERRIDE_PARSER, true);
    // ...
    SchemaFactory schemaFactory =
        SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
    schemaFactory.setFeature(JDK_OVERRIDE_PARSER, true);
    // ...
    Schema schema = schemaFactory.newSchema(new File("mySchema.xsd"));
    Validator validator = schema.newValidator();
    validator.setFeature(JDK_OVERRIDE_PARSER, true);

The following code snippet sets `jdk.xml.overrideDefaultParser` as a System property:

    System.setProperty("jdk.xml.overrideDefaultParser", "true"));

You can add the following line to the `jaxp.properties` file to enable third-party parsers:

    jdk.xml.overrideDefaultParser=true

##### Disabling DTD Processing

If your applications don't require DTDs, then consider disabling DTD processing to safeguard against many common DTD-related attacks, including denial-of-service, XML external entity (XXE), and server-side request forgery (SSRF).

###### Disabling DTD Processing for SAX and DOM Parsers

To disable DTD processing for SAX and DOM parsers, set the feature `http://apache.org/xml/features/disallow-doctype-decl` to true through a factory. The following code snippet disables DTDs for SAX parsers. A fatal error is thrown if the incoming XML document contains a DOCTYPE declaration.

    final static String DISALLOW_DTD =
        "http://apache.org/xml/features/disallow-doctype-decl";
    // ...
    SAXParserFactory spf = SAXParserFactory.newInstance();
    spf.setFeature(DISALLOW_DTD, true);

###### Disabling DTD Processing for StAX Parsers

To disable DTD processing for StAX parsers, set the property `SupportDTD` with the `XMLInputFactory.setProperty` method:

    XMLInputFactory xif = XMLInputFactory.newInstance();
    xif.setProperty(XMLInputFactory.SUPPORT_DTD, Boolean.FALSE);

### Composite Processors

Composite processors such as the validator, transformer, and XPath processor use internally created parsers to read the source when it's not a `DOMSource` or `Document`. When `FEATURE_SECURE_PROCESSING` (FSP) is turned on through factories such as `SchemeFactory`, `TransformerFactory`, and `XPathFactory`, it's also on for any internal parser instance. This means the internal parser will behave the same as a parser created through `SAXParserFactory` or `DocumentBuilderFactory`.

For example, the following code creates an instance of `XPathFactory` with FSP:

    XPathFactory xf = XPathFactory.newInstance();
    xf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

This process ensures FSP is also on for any internal parser required by the XPath processor, such as when it's used to evaluate raw XML source. Consequently, any restrictions defined by the parser are applied. For instance, if the XML source contains external references not resolved by a resolver, it will be rejected as described in External Access Properties because FSP is turned on explicitly.

### Using Java XML Resolvers

You can register custom resolvers on a JDK XML processor to intercept any references to external resources and resolve them with local ones. This feature eliminates the need to read and access external resources, thus helping to remove a source of potential risk.

The Java XML API supports various resolvers that you can register on JDK XML processors to resolve external resources. These resolvers includes entity resolvers for SAX and DOM parsers, XML resolvers for StAX parsers, `LSResourceResolver` for validation, and `URIResolver` for transformation.

#### Entity Resolvers for SAX and DOM

SAX defines an interface that DOM also supports, `org.xml.sax.EntityResolver`. It enables applications to step into the entity resolution process and perform entity resolution on their own terms. The following is the interface's definition:

    package org.xml.sax;

    public interface EntityResolver {
        public InputSource resolveEntity(String publicID, String systemID)
            throws SAXException;
    }

You can then register an implementation of the interface on a SAX driver:

    EntityResolver resolver = ...;
    SAXParserFactory factory = SAXParserFactory.newInstance();
    factory.setNamespaceAware(true);
    XMLReader reader = factory.newSAXParser().getXMLReader();
    reader.setEntityResolver(resolver);

Alternatively, you can register it on a DOM builder:

    DocumentBuilder builder =
        DocumentBuilderFactory.newInstance().newDocumentBuilder();
    docBuilder.setEntityResolver(resolver);

#### XMLResolver for StAX

StAX defines a `javax.xml.stream.XMLResolver` interface:

    package javax.xml.stream;

    public interface XMLResolver {
        public Object resolveEntity(
            String publicID, String systemID,
            String baseURI, String namespace)
            throws XMLStreamException;
    }

You can register it on a StAX factory:

    XMLResolver resolver = ...;
    XMLInputFactory xif = XMLInputFactory.newInstance();
    xif.setProperty(XMLInputFactory.RESOLVER, resolver);

#### URIResolver for javax.xml.transform

The `javax.xml.transform` API supports custom resolution of external resources through the `URIResolver` interface:

    package javax.xml.transform;

    public interface URIResolver {
        public Source resolve(String href, String base)
            throws TransformerException;
    }

You can register an implementation of `URIResolver` on a `Transformer` as follows:

    URIResolver resolver = ...;
    TransformerFactory tf = TransformerFactory.newInstance();
    Transformer t = tf.newTransformer(
        new StreamSource(new StringReader("xsl source")));
    t.setURIResolver(resolver);

#### LSResourceResolver for javax.xml.validation

The `javax.xml.validation` API supports Document Object Model Level 3 Load and Save (DOM LS) DOM through the `LSResourceResolver` interface:

    package org.w3c.dom.ls;

    public interface LSResourceResolver {
        public LSInput resolveResource(
            String type, String namespaceURI, String publicId,
            String systemId, String baseURI);
    }

You can register an implementation of `LSResourceResolver` on a `SchemaFactory` as follows:

    SchemaFactory schemaFactory =
        SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
    LSResourceResolver resolver = ...;
    schemaFactory.setResourceResolver(resolver);

## Relationship with Security Manager

JAXP properties are checked first before a connection is attempted, whether or not a `SecurityManager` is present. This means that a connection may be blocked even if it is granted permission by the `SecurityManager`. For example, if the JAXP properties are set to disallow the HTTP protocol, then they will effectively block any connection attempt even when an application has a `SocketPermission`.

For the purpose of restricting connections, the `SecurityManager` can be viewed as being at a lower level. Permissions are checked after JAXP properties are evaluated. For example, if an application does not have a `SocketPermission`, then a `SecurityException` will be thrown even if JAXP properties are set to allow HTTP connections.

When a `SecurityManager` is present, Feature for Secure Processing (FSP) is set to true. This behavior does not turn on any external access restrictions.

## Handling Errors from JAXP Properties

It is recommended that applications catch `org.xml.sax.SAXNotRecognizedException` when setting JAXP properties so that the applications will work properly on older releases that don't support them.

For example, the following method, `isNewPropertySupported`, from Processing Limit Samples in The Java Tutorials, detects if the sample is run with a version of the JDK that supports the `JDK_GENERAL_ENTITY_SIZE_LIMIT` property:

    public boolean isNewPropertySupported() {
        try {
            SAXParser parser = getSAXParser(false, false, false);
            parser.setProperty(JDK_GENERAL_ENTITY_SIZE_LIMIT, "10000");
        } catch (ParserConfigurationException ex) {
            fail(ex.getMessage());
        } catch (SAXException ex) {
            String err = ex.getMessage();
            if (err.indexOf("Property '" + JDK_GENERAL_ENTITY_SIZE_LIMIT +
                                           "' is not recognized.") > -1) {
                // expected before this patch
                debugPrint("New limit properties not supported. Samples not run.");
                return false;
            }
        }
        return true;
    }

When input files contain constructs that cause an over-the-limit exception, applications may check the error code to determine the nature of the failure. The following error codes are defined for processing limits:

- `EntityExpansionLimit`: JAXP00010001
- `ElementAttributeLimit`: JAXP00010002
- `MaxEntitySizeLimit`: JAXP00010003
- `TotalEntitySizeLimit`: JAXP00010004
- `MaxXMLNameLimit`: JAXP00010005
- `maxElementDepth`: JAXP00010006
- `EntityReplacementLimit`: JAXP00010007

The error code has the following format:

    "JAXP" + components (two digits) + error category (two digits) + sequence number

The code JAXP00010001, therefore, represents the JAXP base parser security limit `EntityExpansionLimit`.

If access to external resources is denied due to the restrictions set by external access restrictions, then an exception will be thrown with an error in the following format:

    [type of construct]: Failed to read [type of construct]
        "[name of the external resource]", because "[type of restriction]"
        access is not allowed due to restriction set by the
        [property name] property.

For example, suppose the following:

- The `ACCESS_EXTERNAL_DTD` JAXP property is set as follows:

      parser.setProperty(
          "http://javax.xml.XMLConstants/property/accessExternalDTD", "file");

- Your application tries to fetch an external DTD with the HTTP protocol.

- The parser parsed an XML file that contains an external reference to `http://www.example.com/dtd/properties.dtd`.

The error message would look like the following:

    External DTD: Failed to read external DTD
        "http://www.example.com/dtd/properties.dtd", because "http"
        access is not allowed due to restriction set by the
        accessExternalDTD property.

## Streaming API for XML and JAXP Properties

Streaming API for XML (StAX), JSR 173, does not support FSP nor does it support EAPs. However, JDK's StAX implementation supports processing limits, and StAX in the context of JAXP supports EAPs.

### StAX and Processing Limits

JDK's StAX implementation supports processing limits and their corresponding System properties. However, because FSP is not supported, you can't turn on or off processing limits for StAX by turning on or off FSP. Processing limits continue to behave as described in JAXP Properties for Processing Limits.

### StAX and External Access Properties

JDK's StAX implementation supports the JAXP properties related to External Access Properties (EAPs). Setting them is similar to SAX or DOM, but through the `XMLInputFactory` class, for example:

    XMLInputFactory xif = XMLInputFactory.newInstance();
    xif.setProperty(
        "http://javax.xml.XMLConstants/property/accessExternalDTD",
        "file");

For compatibility, StAX properties and features take precedence over the processing limit and external access restriction properties. For example, the `SupportDTD` property, when set to `false`, causes a program to throw an exception when an input file contains a DTD before it can be parsed. Therefore, processing limits and external access restrictions on DTDs will have no effect on applications that have disabled DTDs by setting the `SupportDTD` property to `false`.

## General Recommendations for JAXP Security

The following are general recommendations for configuring JAXP properties and features to help secure your applications and systems:

- Turn on `FEATURE_SECURE_PROCESSING` (FSP), then adjust individual features and properties in accordance with your specific requirements.
- For processing limits, adjust them so that they are just large enough to accommodate the maximum amount your applications require.
- For External Access Restrictions (EAPs), reduce or eliminate your applications' reliance on external resources, including the use of resolvers, then tighten these restrictions.

## Appendix A: Glossary of Java API for XML Processing Terms and Definitions

Term | Definition
--- | ---
JAXP | Java API for XML Processing
Java SE XML API | APIs defined in the JAXP JSR and integrated into Java SE
Java XML API | Equivalent term for Java SE XML API
Java XML Features and Properties | XML-related features and properties defined by the Java SE specification
JDK XML | The JDK implementation of the Java XML API
JDK XML Parsers | The JDK implementation of the XML parsers
JDK XML Properties | The JDK Implementation-only properties
EAPs | External Access Properties
FSP | The FEATURE_SECURE_PROCESSING Security Directive

## Appendix B: Java and JDK XML Features and Properties Naming Convention

Java and JDK XML features and properties are defined in the `javax.xml.XMLConstants` class. The features have a prefix `http://javax.xml.XMLConstants/feature`, the properties `http://javax.xml.XMLConstants/property`. If there is a corresponding System property, its prefix is `javax.xml`.

The JDK XML properties are JDK implementation-only properties. Their prefixes vary depending on the JDK version. The following table summarizes this naming convention:

Scope | API Property Prefix | System Property Prefix | Java SE and JDK Version
--- | --- | --- | ---
Java SE | `http://javax.xml.XMLConstants/feature` `http://javax.xml.XMLConstants/property` | `javax.xml` | Since 1.4
JDK | `http://www.oracle.com/xml/jaxp/properties` | `jdk.xml` | Since 7

Copyright © 1993, 2026, Oracle and/or its affiliates. All rights reserved.
Contact Us