What are the signs that an application is vulnerable to HQL or JPQL injection?

Warning signs include query strings assembled with user input, manual quote escaping instead of parameters, and filters or ordering clauses taken directly from request parameters. Static analysis should also flag data flows that enter ORM builders from HTTP inputs, RPC calls, or form fields. If a query can be altered by changing a single request value, it is likely exposed.

What warning signs show HQL or JPQL injection risk?

The strongest warning signs are not subtle: query fragments built from request data, string concatenation around entity names or predicates, and “escaping” logic used instead of bound parameters. HQL and JPQL are especially dangerous when developers let user-controlled values shape the structure of the query rather than only its inputs.

That distinction matters because ORM-based code can look cleaner than raw SQL while still preserving the same injection path. If a field can alter a query construction path, the application has crossed from data handling into query interpretation.

Where HQL or JPQL injection usually appears in code

Typical hotspots include dynamic WHERE, ORDER BY, JOIN, or entity-name clauses that are assembled from HTTP parameters, form fields, RPC payloads, or other external inputs. The risk is higher when the code uses concatenation, interpolation, or ad hoc quote replacement, because those patterns often mean the ORM is receiving text that was never meant to be executable query logic.

Look closely at repository methods that accept “search”, “sort”, “filter”, or “status” values and then hand them straight into query builders. A related red flag is when the application accepts a field name, property path, or direction value from the client and inserts it into HQL or JPQL without a fixed allowlist.

What a vulnerable path looks like in practice

A vulnerable path often has a simple shape: a user can change one request value and meaningfully change the query’s behaviour. That may mean broadening the result set, bypassing authorization logic embedded in a filter, or forcing the ORM to resolve a different property, entity, or clause than the developer intended.

Static analysis is useful here because it can trace whether untrusted data reaches ORM query construction from web inputs, messaging payloads, or backend service calls. In mature codebases, the tell is not just “string concatenation exists”, but that the application uses application security verification patterns that should have required parameterization, fixed query templates, and strict allowlists instead.

Risk and Threat Considerations

HQL and JPQL injection can expose more than data leakage. Because these languages sit close to application logic, a successful injection may change filter behaviour, defeat tenant or role scoping, or enable unauthorized access to records that the application normally hides.

Failure mechanism: The application lets attacker-controlled text alter query structure instead of limiting it to bound values, so the ORM executes a different predicate, sort, or entity reference than intended.

Impact: Depending on the query path, the attacker may read unauthorized data, bypass business rules, or pivot into broader application compromise through logic abuse.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V4 — API and Web Service	HQL and JPQL injection are query-input handling problems that ASVS testing should catch.
	V15 — Secure Coding and Architecture	The issue is caused by unsafe dynamic query construction in application code.
Recommendation — Verify query inputs are parameterized and reject user-controlled query structure. Remove string-built query paths and use fixed query templates with allowlists.
CIS Controls v8	CIS-16 — Application Software Security	Application injection flaws belong in secure application testing and remediation.
Recommendation — Test ORM query construction for injection before release and after changes.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Injection in exposed application endpoints is a common public-facing exploitation path.
Recommendation — Hunt exposed endpoints that pass request data into ORM query builders.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	The vulnerable condition is failure to validate untrusted input before query use.
Recommendation — Validate and constrain request inputs before they reach query construction.

Practitioner Guidance

What to verify: Confirm that all HQL and JPQL paths use parameter binding for values, while any dynamic property, entity, or sort field is selected only from a closed allowlist. If you see manual escaping, treat it as a code smell rather than a control.

What practitioners underestimate: Many teams secure raw SQL and still leave ORM query builders exposed. The most dangerous cases are often the “convenience” features, such as user-driven search and sorting, because they appear harmless but directly influence query structure.

Practitioner takeaway: If untrusted input can change anything beyond a parameter value, assume the query path is injectable until you can prove the ORM is enforcing fixed structure and strict input constraints.