Last Updated: December 2025 | Version: 1.1.0

This page describes the security measures built into FreeXmlToolkit to protect you from XML-based attacks.

When working with XML files, there are several potential security risks - especially when processing untrusted documents or stylesheets. FreeXmlToolkit includes built-in protections against these common attack vectors:

These protections work automatically in the background - you do not need to configure them for normal use.

XXE is a type of attack where a malicious XML document tries to read files from your computer or access network resources. This happens through special "entity" declarations in the XML that reference external files.

This is what a dangerous XML file might look like (FreeXmlToolkit blocks this):

<?xml version="1.0"?>
<!DOCTYPE data [
  <!ENTITY steal SYSTEM "file:///etc/passwd">
]>
<data>&steal;</data>

If processed without protection, this could expose sensitive files from your computer.

All XML parsing in FreeXmlToolkit uses secure configurations that:

• Disable external general entities
• Disable external parameter entities
• Disable external DTD loading
• Limit entity expansion

Normal XML files work without issues. You can:

• Open and edit any XML file
• Validate against XSD schemas
• Transform with XSLT stylesheets
• Work with XML that contains internal (non-external) entities

DTDs with external references are not resolved. If you have an XML file that relies on an external DTD for entity definitions, those entities will appear as empty or cause parsing to fail. This is intentional for security.

XSLT 3.0 and XQuery can include "extension functions" that call Java code directly from your stylesheet. While this is powerful for advanced users, it can be dangerous if you process untrusted stylesheets.

This XSLT tries to execute system commands (FreeXmlToolkit blocks this by default):

<xsl:stylesheet version="2.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:rt="java:java.lang.Runtime">
    <xsl:template match="/">
        <xsl:variable name="runtime" select="rt:getRuntime()"/>
        <xsl:variable name="proc" select="rt:exec($runtime, 'whoami')"/>
    </xsl:template>
</xsl:stylesheet>

FreeXmlToolkit uses Saxon for XSLT/XQuery processing. By default, the ALLOW_EXTERNAL_FUNCTIONS feature is disabled, preventing stylesheets from executing arbitrary Java code.

If you need to use Java extensions in your XSLT transformations:

1. Open the application settings
2. Find the security section
3. Enable "Allow XSLT Extensions"

Warning: Only enable this if you trust all XSLT stylesheets you will process. Malicious stylesheets could:

• Read files from your computer
• Execute system commands
• Access network resources
• Modify or delete files

The setting is stored as:

security.xslt.allow.extensions=true

When extensions are enabled, you will see a warning message in the application log.

SSRF attacks trick an application into making requests to internal network resources. In XML processing, this can happen when schemas or stylesheets reference URLs.

When loading remote schemas (via xs:import or xs:include with HTTP URLs), FreeXmlToolkit blocks access to:

Public schemas work normally. You can reference standard schemas from W3C and other public sources.

Internal network schemas are blocked. If you need to load schemas from:

• Your company's internal server (e.g., http://192.168.1.100/schemas/)
• Localhost development servers (e.g., http://localhost:8080/)

You should:

1. Download the schema files to your local machine
2. Reference them using file paths or file:// URLs
3. Place them in the same directory as your XML files for relative references

Path traversal attacks use special characters like ../ to access files outside the intended directory. This could allow a malicious document to read or write to sensitive system locations.

Windows:

• C:\Windows\
• C:\Program Files\
• C:\ProgramData\

Linux/macOS:

• /etc/
• /bin/, /sbin/
• /usr/bin/, /usr/sbin/
• /var/
• /root/
• /boot/

Path validation applies to:

• Schema includes (xs:include, xs:import with relative paths)
• Linked file detection (auto-linking in the unified editor)
• Export paths (saving output files)
• Any relative file references in XML documents

Normal file operations work fine. You can:

• Open files anywhere on your computer
• Save files to your documents folder
• Use relative paths within your project directories

Suspicious paths are blocked. If you see a path traversal warning, check that your schema or stylesheet references do not contain unusual ../ sequences or try to access system directories.

XPath injection is similar to SQL injection - it happens when user input is inserted directly into XPath queries without proper escaping. This could allow malicious input to modify the query's behavior.

When you use the XPath/XQuery snippet system with parameters, all parameter values are automatically escaped before being inserted into queries.

If you have a snippet with parameter ${searchTerm} and the user enters:

O'Brien "Bob"

The system generates:

concat('O', "'", 'Brien "Bob"')

This prevents the user input from breaking out of the string literal and modifying the query structure.

This protection is automatic and transparent. You do not need to do anything special - just use the parameter syntax ${paramName} in your snippets, and values will be properly escaped.

1. Open FreeXmlToolkit
2. Go to Settings (or use the keyboard shortcut)
3. Look for the Security section

For advanced users, security settings are stored in the application properties file:

1. Keep extensions disabled unless you specifically need them
2. Only process trusted stylesheets if you enable extensions
3. Download remote schemas to local files when working with internal network resources
4. Review XML files before processing if they come from untrusted sources
5. Check validation errors - they may indicate blocked security threats

Cause: Your XML references an external DTD or entity that was blocked for security.

Solution: If you need the entity definitions, manually include them in your XML file or convert the external DTD to a local file.

Cause: You tried to load a schema from a localhost or private network address.

Solution: Download the schema file to your local machine and reference it as a local file.

Cause: Your stylesheet uses Java extension functions, which are disabled by default.

Solution: If you trust the stylesheet, enable XSLT extensions in settings. Otherwise, modify the stylesheet to not use extensions.

Cause: A file reference contains suspicious ../ sequences that would access files outside the expected directory.

Solution: Check your schema imports and includes for unusual paths. Use absolute paths or properly relative paths that stay within your project directory.

For developers and security professionals, here are the specific protections implemented:

All XML parsers use these security features:

• http://apache.org/xml/features/disallow-doctype-decl = false (DOCTYPE allowed, but entities disabled)
• http://xml.org/sax/features/external-general-entities = false
• http://xml.org/sax/features/external-parameter-entities = false
• http://apache.org/xml/features/nonvalidating/load-external-dtd = false
• javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING = true
• Entity reference expansion = disabled

• Feature.ALLOW_EXTERNAL_FUNCTIONS = false (by default)
• Configurable via application settings

Uses Java's InetAddress class to check:

• isLoopbackAddress() - blocks localhost
• isLinkLocalAddress() - blocks 169.254.x.x
• isSiteLocalAddress() - blocks private networks
• Special check for 169.254.169.254 (cloud metadata)

• Canonical path comparison for traversal detection
• Regex patterns for encoded sequences
• Blocklist of system directories
• Symbolic link resolution for escape detection

All Pages: XML Editor | XML Features | XSD Tools | XSD Validation | XSLT | XSLT Developer | FOP/PDF | Signatures | IntelliSense | Schematron | Favorites | Templates | Tech Stack | Security | Licenses