Server-Side Template Injection (SSTI) and QPR ProcessAnalyzer

This page explains why external security scanners may flag a potential Server-Side Template Injection (SSTI) issue for the /api/query-PA endpoint, why this is a false positive for QPR ProcessAnalyzer, and what security measures and tests we have in place for the QPR ProcessAnalyzer Expression Language. QPR ProcessAnalyzer uses expression language extensively to allow user to flexibly perform complicated analyses on user data.

Summary

Some automated scanners (e.g., Qualys) may report potential SSTI related to the /api/query-PA REST API. This is a false positive. The payload fields such as Root and Expression use QPR ProcessAnalyzer’s proprietary Expression Language, not a general-purpose template engine. Expressions are fully parsed, validated, and executed by our own code in a controlled, sandboxed runtime that enforces permissions and configuration checks. Independent penetration testing targeting the Expression Language has been performed. No general-purpose template rendering, dynamic code evaluation (e.g., eval), or direct access to server-side objects is exposed through this interface.

What scanners detect and why

Automated web vulnerability scanners often use patterns and heuristics:

They look for endpoints that accept “template-like” payloads or expression-looking strings. They attempt to inject template syntax from known engines and observe server responses for code execution or error signatures.

Because /api/query-PA accepts fields named Root and Expression that contain expressions, scanners may assume the presence of a server-side template engine and flag SSTI. However, these expressions are not processed by any third-party templating engine. They are parsed and executed by QPR ProcessAnalyzer’s own Expression Language runtime.

Why this is a false positive

Proprietary Expression Language

• The syntax and semantics are specific to QPR ProcessAnalyzer.
• No general-purpose template engine is used.
• Known SSTI payloads for common template engines are not applicable.

Fully controlled parsing and evaluation

• Parsing, type checking, binding resolution, and function invocation are implemented in our codebase.
• There is no passthrough of user input to an external interpreter or dynamic language runtime that could lead to arbitrary code execution.

Sandboxed execution

• Expressions execute in a constrained runtime that:
  • Restricts available functions and operators to a vetted, documented set.
  • Disallows arbitrary file system, process, network, or OS-level access.
  • Prevents reflection or direct access to server internals.
• All potentially sensitive operations are either unavailable or guarded by permission checks.

Enforced authorization and configuration checks

• Expressions are evaluated in the context of the authenticated user.
• Data access is subject to authorization rules and configuration constraints.
• Even if an expression references secured objects, access control is applied before any result is returned.

Robust error handling

• Expression parsing and execution errors surface as controlled, non-verbose error messages that do not leak server internals or stack traces useful for exploitation.

Security controls in and around the Expression Language

Input validation and parsing:

• Strict grammar with deterministic parsing.
• Rejection of unsupported constructs and suspicious tokens.

Hardened system API functions:

• The only interface from the expression language to its execution environment goes through system API functions, all of which ensure that the user cannot access anything they don’t have permissions for.

Resource and execution limits:

• Guards against excessive recursion, deep nesting, or long-running evaluations.
• Query and expression timeouts, size limits, and paging strategies.

Authorization enforcement:

• Per-user and role-based checks at data access points.
• Context-aware evaluation prevents privilege escalation.

Safe error responses:

• Sanitized error messages; no raw stack traces to clients.

Auditability:

• Server-side logging of expression usage and significant security-relevant events.

Penetration testing

A targeted penetration test focusing on the Expression Language and its execution pathway has been conducted. The objective was to identify risks such as:

• Code execution via expression injection
• Privilege escalation through expression evaluation
• Unauthorized data access or data exfiltration
• Denial-of-service via computationally heavy expressions

Outcome:

• No exploitable SSTI or arbitrary code execution was identified in the Expression Language.
• Recommendations (if any) from the engagement were reviewed and relevant hardening actions incorporated into our development lifecycle.

Guidance for responding to scanner findings

Finding type

“Potential Server-Side Template Injection (SSTI)” on /api/query-PA.

Recommended response

QPR ProcessAnalyzer does not use a general-purpose template engine in /api/query-PA. The Root and Expression fields are parsed and executed by QPR ProcessAnalyzer’s proprietary Expression Language within a sandboxed runtime. Authorization and configuration checks are enforced during evaluation; sensitive functions and system access are not exposed. Independent penetration testing specifically targeted the Expression Language without finding exploitable SSTI. Therefore, this is a false positive with respect to classic SSTI risk.

If the scanner allows, consider adding a false-positive exception referencing this page and the notes above.

Frequently asked questions

Can user expressions execute server-side code or shell commands?

No. Expressions do not expose OS-level or runtime APIs and run in a restricted environment.

Can expressions read arbitrary files or environment variables?

No. File system, environment, and network access are not available through the Expression Language.

Can expressions bypass data permissions?

No. Access control is enforced for every data access during evaluation.

How are performance risks handled?

The engine enforces limits on expression complexity, recursion, depth, and execution time, mitigating DoS-style attempts.

Are errors verbose?

No. Errors are sanitized and do not reveal sensitive implementation details.