XPath injection
XPath injection changes a query against XML data by introducing attacker-controlled query syntax.
What it means
XPath injection changes a query against XML data by introducing attacker-controlled query syntax. Systems that build expressions through string concatenation may expose records or bypass intended selection rules. Bind supported variables where possible or use a fixed query with strict handling of supplied values.
A practical example
A legacy document portal looks up an account in an XML store. The redesign uses a fixed expression with externally bound values rather than embedding the submitted account name into the XPath text.
What to check
Locate dynamic XPath construction, verify the library's variable-binding behavior, and constrain application permissions. Test quote handling and unexpected expressions without exposing real customer data.
A common pitfall
XML being a data format does not mean every XML-related operation is inert. XPath expressions are executable selection logic and require a separate code-versus-data boundary.
Think it through
What is safer than building an XPath expression from a submitted name?
Answer: A fixed expression with supported variable binding, combined with the appropriate authorization checks.
Query structure can be changed outside a database
A fictional training application keeps a small catalogue in XML and searches it with XPath. The user should supply a category value, while the application owns the path and predicate structure. Concatenating the category into an expression can let the input affect what the XPath engine selects. The same data-versus-instructions distinction applies even though no SQL database is involved.
Use supported variable binding where the XPath library offers it, or redesign the lookup through a safer data interface. Confirm the exact API behavior rather than assuming a string-building helper provides parameterization. Input validation can constrain supported categories, but it should not be mistaken for a universal escaping rule for every XPath context.
Authorization still governs the returned information. A perfectly constructed query may expose private records if the application searches a broader document than the caller may access. Limit the data available to the operation and make the record policy explicit. Avoid relying on the XML file being hidden from direct download as the only protection.
Draw a simple selection operation
For a local exercise, create dummy catalogue entries with public and staff-only categories. Describe the intended XPath structure separately from the supplied category. Explain how a supported binding mechanism keeps that value from selecting a different part of the document. Then identify the independent rule that prevents a learner from retrieving staff-only content.
A useful assessment report names the expression-building path, the XML data involved, and the unauthorized selection that becomes possible. Demonstrate only enough with synthetic records to establish the issue. Retest helper functions and background jobs that use the same selection code, because a fix in one visible search page may leave the underlying query-construction problem elsewhere.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: XPath Injection Prevention