Missing XML Validation

Description

This vulnerability occurs when an application processes XML data from an untrusted source without first validating its structure and content against a defined schema.

Extended Description

When you accept XML without schema validation, you're trusting external data to match your code's expectations. Attackers exploit this gap by sending malformed, oversized, or maliciously crafted XML documents that can trigger parsing errors, consume excessive resources, or enable injection attacks. This fundamentally breaks the security assumption that input will be reasonable and well-formed. Consistently validating XML against a strict DTD or XML Schema is a critical first line of defense. While SAST tools can detect missing validation patterns, Plexicus uses AI to analyze your code flow and suggest precise fixes—like implementing schema validation libraries or hardening parser configurations—saving hours of manual security review and helping prevent this common oversight across your entire application portfolio.

Common Consequences 1

Scope: Integrity

Impact: Unexpected State

Detection Methods 1

Automated Static AnalysisHigh

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Potential Mitigations 1

Phase: Architecture and Design

Strategy: Input Validation

Always validate XML input against a known XML Schema or DTD. It is not possible for an XML parser to validate all aspects of a document's content because a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed.

Demonstrative Examples 2

The following code loads and parses an XML file.

Code Example:

Bad

Java

// Read DOM* try { ``` ... DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setValidating( false ); .... c_dom = factory.newDocumentBuilder().parse( xmlFile ); } catch(Exception ex) { ... }

The XML file is loaded without validating it against a known XML Schema or DTD.

The following code creates a DocumentBuilder object to be used in building an XML document.

Code Example:Bad
Java
java

The DocumentBuilder object does not validate an XML document against a schema, making it possible to create an invalid XML document.

References 1

Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors

Katrina Tsipenyuk, Brian Chess, and Gary McGraw

NIST Workshop on Software Security Assurance Tools Techniques and Metrics • NIST

07-11-2005

https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf

ID: REF-6

Applicable Platforms

Languages:

Not Language-Specific : Undetermined

Modes of Introduction

Implementation

Related Attack Patterns

Related Weaknesses

ChildOf:

Improper Validation of Syntactic Correctness of Input (CWE-1286)

ChildOf:

Improper Input Validation (CWE-20)

Taxonomy Mapping

7 Pernicious Kingdoms
Software Fault Patterns