Cybersecurity glossary
What is XPath Injection?
Learn what XPath injection is, how attacker-controlled XPath expressions manipulate XML queries, how it differs from SQL and LDAP injection, and how to prevent it with parameterized XPath and input validation.
Definition
XPath Injection is an attack technique that manipulates XML Path Language (XPath) queries by injecting metacharacters or crafted fragments into application inputs, causing unauthorized data disclosure, authentication bypass, or unintended XML node selection.
Why XPath injection matters
Many applications still treat XML as a data store: user directories, product catalogs, configuration trees, and SOAP payloads. When those systems build XPath expressions from request parameters, XPath Injection lets attackers rewrite predicates the same way SQL injection rewrites WHERE clauses.
Impact ranges from dumping sensitive elements to bypassing authentication against an XML-backed login. The bug is easy to miss because teams often harden SQL paths while leaving XML query construction string-concatenated.
How XPath injection works
Find XPath-driven input
Login fields, search filters, or IDs that the server embeds into an XPath expression against XML.
Inject path or predicate syntax
Payloads use quotes, or/and, wildcards, or // to alter node selection and boolean logic.
Engine evaluates attacker logic
The XPath processor treats injected fragments as query syntax, not literal data values.
Observe unauthorized XML access
Broader result sets, login success without a valid password, or inferred node values confirm the flaw.
Common vulnerable patterns
String-built login queries
Username and password concatenated into //user[name=... and pass=...] predicates.
Dynamic node search
User-supplied tags, attributes, or keywords spliced into //*[...] filters.
XML as a mini-database
Configs and catalogs queried with XPath instead of a real DB and parameterized API.
Blind boolean probing
Error-quiet endpoints still leak data via true/false response differences.
Prevention that works
| Control | Notes |
|---|---|
| Parameterized XPath | Bind user values as variables; never concatenate into the expression string |
| Strict input allowlists | Accept only expected character sets, lengths, and formats for IDs and names |
| Escape metacharacters | If parameterization is unavailable, escape quotes and XPath specials per API guidance |
| Least-privilege XML views | Expose only needed nodes; keep secrets out of queryable documents |
| Prefer safer data stores | Move auth and high-value records off XML files into properly parameterized databases |
| Automated injection tests | Regression payloads for quotes, or '1'='1, and boolean blind probes on every XPath path |
- Inventory every place the app builds or evaluates XPath from request or file input.
- Replace string concatenation with parameterized XPath or typed query builders.
- Validate and allowlist fields used in predicates (username, id, category).
- Keep credentials and secrets out of XML documents that application code queries.
- Add unit and integration tests that attempt classic XPath login-bypass payloads.
- Review SOAP/XML gateways for user-influenced filter expressions.
- Log anomalous empty/full result swings that may indicate probing.
- Treat confirmed XPath injection as high severity until query construction is fixed.
The practical takeaway
XPath Injection turns untrusted strings into XML query logic. If your app still searches XML with hand-built expressions, treat those paths like SQL: parameterize, allowlist, and test.
If clients can close a quote inside your XPath, assume they can rewrite the entire predicate.
Related security terms
SQL Injection (SQLi)
The relational-query cousin that shares unsafe string concatenation as the root cause.
LDAP Injection
Injection into directory search filters—another structured-query interpreter abuse.
XML External Entity (XXE) Injection
A different XML attack class that abuses entity resolution rather than path queries.
NoSQL Injection
Operator and structure injection against document databases instead of XPath.
Frequently asked questions
What is XPath injection in simple terms?
The application builds an XPath query from user input. An attacker inserts XPath syntax so the query returns more nodes, skips password checks, or reveals data the user should not see.
How is XPath injection different from SQL injection?
Both abuse string-built queries, but XPath targets XML documents and uses path/predicate syntax (/, //, [], and, or) rather than SQL keywords. Fixes use parameterized XPath or safe builders instead of SQL prepared statements.
Where does XPath injection usually appear?
Login forms that authenticate against XML user stores, search features over XML feeds or configs, SOAP/XML gateways that filter nodes by user criteria, and legacy apps using XML as a lightweight database.
What does a classic XPath login bypass look like?
A query like //user[name/text()='USER' and pass/text()='PASS'] can be broken with a username such as ' or '1'='1 so the password predicate is never required for a match.
How do you prevent XPath injection?
Never concatenate untrusted strings into XPath. Use parameterized XPath APIs where available, escape or allowlist inputs strictly, validate types and length, and prefer non-XML stores for authentication data.
Is input HTML encoding enough?
No. HTML encoding addresses browser rendering (XSS). XPath injection requires safe query construction on the server before the XPath engine runs.
Can blind XPath injection still leak data?
Yes. When results are not shown directly, attackers can use boolean conditions and timing or differential responses to infer node values character by character.
References
Explore authoritative guidance and frameworks related to xpath injection.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.