New CS proposal: XPath Injection Prevention Cheat Sheet

What is the proposed Cheat Sheet about?

The proposed XPath Injection Prevention Cheat Sheet would provide developer-focused guidance for preventing injection when applications evaluate XPath expressions over XML data.

The repository currently identifies XPath as a form of injection, but the XPath Injection section of Injection_Prevention_Cheat_Sheet.md contains only TODO, and there is no dedicated XPath injection prevention cheat sheet. The new cheat sheet would fill that gap with concise, language-agnostic guidance. After the new cheat sheet is accepted, the existing TODO can be replaced with a link to it in a separate, focused update.

What security issues are commonly encountered related to this area?

XPath injection occurs when external input is concatenated into an XPath expression and can change the structure or logic of the query. CWE-643 identifies consequences including authentication bypass, application-flow manipulation, and unauthorized access to XML data.

The cheat sheet would address:

• Direct construction of XPath expressions from untrusted input.
• Authentication and authorization bypass through injected predicates.
• Unauthorized XML data access and blind XPath data extraction.
• Leakage of expression or XML structure through detailed errors and observable responses.
• Confusion between validating data values and allowing users to control path, operator, function, or predicate syntax.
• Unsafe reliance on ad hoc quote escaping as the primary defense.

What is the objective of the Cheat Sheet?

The objective is to give developers practical prevention guidance organized around separation of data from XPath expression structure. The proposed content would:

• Prefer fixed or precompiled XPath expressions over runtime string construction.
• Recommend variable binding or a parameterized API when the XPath implementation supports it. XPath defines variable references, and platform APIs such as Java XPathVariableResolver provide a mechanism for supplying variable values without concatenating them into the expression.
• Recommend mapping user-controlled choices to fixed, developer-defined expressions when the path or query structure must vary.
• Define strict allowlist validation for the limited cases where a structural component cannot be bound as data.
• Explain why input validation and escaping are secondary controls rather than substitutes for separating data from expression syntax.
• Cover safe error handling, least-privilege data exposure, code-review sinks, and focused testing guidance.
• Include only short, verified examples where they add practical value, following the project preference for architectural guidance over large language-specific samples.

The cheat sheet would remain focused on prevention. Detailed exploitation steps and payload catalogs would be left to the Web Security Testing Guide.

What other resources exist in this area?

• CWE-643: Improper Neutralization of Data within XPath Expressions defines the weakness, its consequences, and parameterized-query mitigation.
• OWASP WSTG v4.2: Testing for XPath Injection documents how testers identify and assess XPath injection. It is complementary rather than duplicative because the proposed cheat sheet would focus on secure design and prevention.
• W3C XPath 3.1 defines XPath variable references and expression semantics.
• Java XPathVariableResolver is one official example of a platform API that supplies values for XPath variables.
• The existing Injection Prevention Cheat Sheet currently contains the unimplemented XPath Injection section.

AI Tool Usage Disclosure

OpenAI Codex (GPT-5) assisted with repository analysis and drafting this proposal. The prompt requested a substantial, maintainable OWASP contribution that follows the project workflow and has a strong chance of acceptance. I independently searched the repository and its open and closed issues and pull requests for overlapping work, reviewed each source linked above, and verified the current TODO section before submitting this proposal.