XPath injection

What it means

XPath is a language for picking items out of an XML document, for example the user whose name and password match what was typed. XPath injection happens when that typed text is pasted into the query string, so the text can change the query instead of just filling a gap in it.

It follows the same pattern as SQL injection. The attacker adds quotes and conditions that make the query true for every record, or that reveal information one character at a time. The application is the one that runs the altered query.

Why it matters

XPath has no built-in permission layer. A query that runs against a document can usually read any part of it, so one injected condition may expose data well outside the intended record. Sign-in checks that use XPath can be bypassed, and stored configuration or user lists can leak.

Because XML documents often hold credentials, settings or customer records in older systems, the exposure can be wide. MITRE tracks the weakness as CWE-643, and OWASP lists it among injection attacks. A flaw like this is also easy to overlook, because it hides in the parts of a system that nobody has reviewed for years.

How it shows up

You meet it in older enterprise software, SOAP services, applications that keep users or settings in XML files, and any feature that searches XML supplied by customers. The standard mistake is building the query by joining strings, such as //user[name='INPUT' and pass='INPUT'].

Use parameterised XPath where your library supports variables, so values travel separately from the query. Otherwise escape quotes properly and validate input against an allowlist. Keep sensitive data out of documents that every query can read. Test with quote characters and always-true conditions. See injection and SQL injection.