What are common mistakes when preventing XPath injection?

How XPath injection usually happens in real code

xpath injection starts when application logic builds a query by joining raw user input into the XPath string. The risk is often hidden in login, search, filtering and access-check code because the XPath expression looks “internal” and safe. Once attacker-controlled text changes the query structure, the application can return data the developer never intended to expose.

The most common failure mode is treating XPath like a formatting problem instead of a query-construction problem. If the code interpolates usernames, roles, document names, or path fragments directly into the expression, the attacker can alter predicates, bypass checks, or broaden the result set. That is why prevention has to begin at the query boundary, not after the result is returned.

Why validation and encoding are often not enough

Input validation helps, but it is easy to overestimate what it can do. XML schema validation, length limits, or “clean” looking fields do not remove injection risk if the value still reaches XPath construction unchanged. The dangerous part is not malformed XML, it is attacker influence over the expression logic.

Encoding untrusted text can help when the library lacks parameter binding, but it has to be context-aware and complete. Escaping only quote characters, for example, is not sufficient if the developer later concatenates the same input into another XPath fragment. A safer pattern is to avoid hand-built expressions wherever the platform supports prepared or parameterised evaluation, then treat any remaining dynamic fragment as data, not syntax.

For teams that want a broader view of related web injection patterns, NHIMG’s Web Application Attacks Guide is a useful parent reference because XPath injection sits in the same family of input-to-query flaws as other injection issues.

What else to review beyond the XPath string itself

Prevention is incomplete if the application still uses XPath results to drive access control, record selection, or downstream authorization decisions without checking whether the result set can be manipulated. A query that is safe on paper can still become a privilege bypass if its output is trusted too broadly or used as the only decision point.

It is also worth reviewing where the XPath query is assembled in the codebase. High-risk locations include authentication handlers, XML-backed configuration readers, workflow engines, and any middleware that translates request fields into XML predicates. If those paths are shared across multiple features, one injection bug can affect more than one security control.

Risk and Threat Considerations

XPath injection is dangerous because it can turn ordinary XML lookup logic into an access-control bypass or data disclosure path. The issue is especially serious when the query result determines whether a user is authenticated, authorised, or allowed to see a record.

Failure mechanism: Attacker-controlled input changes the meaning of the XPath expression, allowing the query to return broader, different, or privileged nodes than the developer intended. If the application then trusts that output for a security decision, the flaw can become a direct control bypass.

Impact: The usual outcomes are unauthorised data exposure, account or session-related logic bypass, and unreliable authorisation decisions. In some applications the flaw can also support enumeration of sensitive XML content or indirect privilege escalation through manipulated query results.

Practitioner Guidance

What to verify: Confirm whether every XPath expression that incorporates request data uses a library feature intended for safe parameterisation, or whether the code still relies on string concatenation. Pay special attention to code paths that look like harmless filters but actually gate access or identity lookups.

Common mistake: Do not treat XML validation as a substitute for query safety. Validation can reject malformed documents, but it does not stop a valid attacker-controlled value from changing the query logic if that value is inserted into XPath syntax.

Decision rule: If the library cannot bind XPath parameters safely, minimise dynamic XPath use, whitelist expected values, and encode untrusted text for the specific XPath context before it reaches the query layer. If the result influences access control, review the entire decision path, not just the query statement.

Practitioner takeaway: The safest XPath code is the code that keeps user input out of query syntax altogether, because once input can reshape the expression, validation alone is no longer a meaningful defence.

Related resources from NHI Mgmt Group

• What are common mistakes with LLM Prompt Injection Prevention?
• What are common mistakes with injection prevention?
• What are common mistakes with injection prevention in Java?
• What are common mistakes with OS command injection defence?