Proposal: Enhancements and Clarifications for ASVS V1.2 Injection Prevention Guidance

[ajayojha]

From an architectural standpoint, the following areas represent significant risks in modern enterprise applications but are not explicitly addressed in the current ASVS section:

GrapQL Injection

Modern APIs increasingly rely on GraphQL, yet the ASVS lacks specific guidance for securing them.
Recommendation: Verify that GraphQL resolvers implement strict input validation, enforce field-level authorization, and disable introspection queries in production to minimize the attack surface.

Server-Side Template Injection

No mention of SSTI (Server-Side Template Injection) in templating engines.
Recommendation: Verify that user input is not directly passed to template rendering engines (e.g., Jinja2, Handlebars, Thymeleaf) without context-aware escaping or sandboxing enabled.

Clarifications Needed for Effective Implementation

Certain ASVS statements, while technically sound, require additional explanation to ensure correct implementation by developers.

1.2.4: Database Queries

The Statement: "Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection..."
Why it needs explanation: This rule is excellent, but developers often assume that simply using an ORM makes them immune. They fail to understand that injecting user input into methods that construct the query structure itself reintroduces SQL injection.
Recommendation: The explanation should explicitly state: " Verify that data selection or database queries avoid raw queries with string concationation. Using an ORM or Entity Framework does not automatically prevent all injection. Verify that user-controlled data is only used as parameters within the query and never to dynamically construct or alter the structure of the query itself, such as table names, column names, or logical operators."

I would be happy to know the feedback from OWASP ASVS team.

[ajayojha]

++Clarifications Needed for Effective Implementation

Based on my experience working with development teams, I believe the following statements need further clarification, as developers may either misunderstand them or overlook important details.

1.2.2: Dynamically Building URLs

The Statement: Verify that when dynamically building URLs, untrusted data is encoded according to its context... Ensure that only safe URL protocols are permitted (e.g., disallow javascript: or data:).
Why it needs explanation: This rule combines two distinct but related risks: URL injection in application-generated URLs and open redirect vulnerabilities. Developers may focus on one and miss the other. Furthermore, "context" is key. Data destined for a path segment needs different encoding than data for a query parameter.
Recommendation: It would be clearer to separate these concerns and provide examples. "When placing untrusted input into URLs, ensure proper encoding for the specific URL component (e.g., URLEncoder for query parameters, path segment encoding for path elements). Additionally, when accepting a full URL as input for redirection, validate it against a strict allow-list of trusted domains and paths to prevent open redirects. Always validate the protocol to disallow dangerous schemes like javascript:, data:, and file:."

1.2.5: OS Command Injection

The Statement: Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding.
Why it needs explanation: The term "parameterized OS queries" is often confusing for developers, as most OS shell environments don't have a native, universal parameterization feature like databases do. This can lead to incorrect implementations.
Recommendation: The explanation should be more concrete. For example: "To prevent OS command injection, avoid calling the OS shell directly (e.g., bash -c, cmd.exe /c). Instead, use library functions that invoke commands directly, passing user-controlled data as distinct arguments in an array (e.g., execve in Unix-like systems, or the ProcessBuilder class in Java). This ensures arguments are treated as data, not executable code. If shell metacharacters must be allowed, they must be strictly validated against an allow-list.

I would be happy to draft a pull request if submitted suggestions are aligned with OWASP ASVS team.

[elarlang]

Recommendation: Verify that GraphQL resolvers implement strict input validation, enforce field-level authorization, and disable introspection queries in production to minimize the attack surface.

We do not duplicate general requirements for each technology or functionality, and it is specifically mentioned in the related chapter text:

Note that authentication, session management, and input validation concerns from other chapters also apply to APIs, so this chapter cannot be taken out of context or tested in isolation.

---

No mention of SSTI (Server-Side Template Injection) in templating engines.
Recommendation: Verify that user input is not directly passed to template rendering engines (e.g., Jinja2, Handlebars, Thymeleaf) without context-aware escaping or sandboxing enabled.

We have a requirement

1.3.7 Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated.

---

Verify that data selection or database queries avoid raw queries with string concatenation.

• String concat itself is not wrong; the problem is when user-controlled input is used for that.
• String concat is often used for the parameters that can not be bound, such as order by. In this case, allow-list validation must be in place.

---

Why it needs explanation: This rule combines two distinct but related risks: URL injection in application-generated URLs and open redirect vulnerabilities.

No, this requirement only covers building a URL; open redirect is a topic for validation. We have a requirement for this:

3.7.2 Verify that the application will only automatically redirect the user to a different hostname or domain (which is not controlled by the application) where the destination appears on an allowlist.

---

To prevent OS command injection, avoid calling the OS shell directly (e.g., bash -c, cmd.exe /c). Instead, use library functions that invoke commands directly, passing user-controlled data as distinct arguments in an array (e.g., execve in Unix-like systems, or the ProcessBuilder class in Java).

For me, this is the cheat sheet area already.

[ajayojha]

We do not duplicate general requirements for each technology or functionality, and it is specifically mentioned in the related chapter text:

Thank you for your feedback and for highlighting the intent to avoid duplication in the ASVS.

I’d like to respectfully note that I have already reviewed the dedicated GraphQL section (Section 4.3) before submitting my comments. As it's mentioned, this section addresses important GraphQL-specific risks—specifically query depth/cost limiting (4.3.1) and production introspection (4.3.2).

However, my concern is that critical controls such as input validation and field-level authorization at the resolver level are not explicitly covered in the current GraphQL requirements. In practice, these two areas are the root cause of many GraphQL vulnerabilities observed in mature enterprise applications, even when other ASVS controls are followed.

To be transparent, I was initially unsure whether to raise the GraphQL injection point under the general injection section or within the GraphQL-specific section, but decided to submit it here for team feedback and further suggestion.

Would the team consider enhancing Section 4.3 to explicitly require:

• Strict input validation of all incoming data at the resolver level.
• Field-level authorization to ensure users only access data they are authorized to view or modify.

Addressing these points would help bridge the gap between general API security and the unique risks associated with GraphQL.

We have a requirement

Thank you for referencing 1.3.7. I appreciate that it addresses template injection in general and mentions the importance of avoiding untrusted input during template creation. but for Server-Side Template Injection (SSTI), the issue is not just whether input is sanitized — it’s how template engines interpret that input.

Many SSTI exploits involve valid-looking input that passes validation, but still leads to code execution due to unsafe rendering logic or lack of sandboxing.

Would the team consider explicitly naming SSTI, and adding guidance on:

• Avoiding template engines with unsafe defaults,
• Enabling sandboxing or restricted modes, and
• Using context-aware escaping (not just input validation)?

String concat itself is not wrong; the problem is when user-controlled input is used for that.
String concat is often used for the parameters that can not be bound, such as order by. In this case, allow-list validation must be in place.

I completely agree—string concatenation is not inherently insecure. The key issue is when untrusted input is used within concatenated strings that construct query structure.

However, this is exactly the kind of subtlety that many developers miss. In real-world audits, we often find developers using ORMs or Entity Frameworks but still:

• Dynamically building WHERE, ORDER BY, or LIMIT clauses using user input without proper allowlist checks.
• Injecting user-controlled field names, table names, or logical expressions into raw SQL fragments.

While the existing ASVS 1.2.4 statement is strong, it may be misinterpreted to mean that simply “using an ORM or parameterized query” is sufficient.

My suggestion is to add a clarifying sentence to protect against this misinterpretation, such as:
“Ensure that user input is never used to dynamically construct or modify the structure of a query (e.g., table names, field names, ORDER BY clauses) unless validated against a strict allowlist.”

[elarlang]

The discussion format is not really followable here.

Please open a separate issue per requirement.

Before doing so, please read about the scope of ASVS and keeping in mind that:

• We consider precise implementation instructions to be area for the Cheat Sheet Project
• We don't duplicate the same principle to different section and requirements

In every issue, it must be clear what is the precise problem to solve for the current requirement.

[ajayojha]

Okay, thanks. I will create a separate issue for each requirement separately after reviewing the scope of ASVS, even though I had read it a while ago.