The process engine offers numerous extension points for customization of process behavior by using Java Code, Expression Language, Scripts and Templates. While these extension points allow for great flexibility in process implementation, they open up the possibility to perform malicious actions when in the wrong hands. It is therefore advisable to restrict access to API that allows custom code submission to trusted parties only. The following concepts exist that allow submitting custom code (via Java or REST API):

• Deployment: Most of the custom logic is submitted with the deployment of a process, case, or decision model. For example, an execution listener invocation is defined in the BPMN 2.0 XML.
• Queries: Queries offer the ability to include expressions for certain parameters (currently task queries only). This enables users to define reusable queries that can be repeatedly executed and dynamically adapted to changing circumstances. For example, a task query taskService.createTaskQuery().dueBeforeExpression(${now()}).list(); uses an expression to always return the tasks currently due. Camunda Tasklist makes use of this feature in the form of task filters.

Only trusted users should be authorized to interact with these endpoints. How access can be restricted is outlined in the next sections.

Camunda 7 in a Trusted Environment

When Camunda 7 is deployed in an environment where only trusted parties can access the system (for example due to firewall policies), no untrusted party can access the APIs for submitting custom code and the following suggestions need not be adhered to.

Deployments

Access to performing deployments can be restricted by using the authorization infrastructure and activating authentication checks for any endpoint a potentially untrusted party may access. The crucial permission for making deployments is Deployment/Create. Untrusted users should not be granted this permission.

Queries

Query access cannot be generally restricted with authorizations. Instead, a query’s result is reduced to entities a user is authorized to access. Thus, authorization permissions cannot be used to guard expression evaluation in queries.

The process engine offers two complementary mechanisms to harden query expression evaluation:

1. Expression Allow-List – restricts which EL functions, methods, beans, and properties may appear in query expressions. Enabled by default.
2. Enable/disable flags – toggle expression evaluation as a whole for adhoc and stored queries.

Expression Allow-List for Query API

When the allow-list is enabled, only explicitly permitted EL functions, chained method calls, dot-notation property accesses, and bean references may be used in query expressions (e.g., taskAssigneeExpression, dueAfterExpression). Any other usage is rejected with a BadUserRequestException before the expression is evaluated, preventing malicious code from being executed.

This feature is enabled by default (queryExpressionAllowListEnabled=true). Built-in safe defaults cover the engine’s standard date/time and current-user functions (now, dateTime, currentUser, currentUserGroups) plus a comprehensive list of Joda-Time DateTime arithmetic methods (plusDays, minusDays, withTimeAtStartOfDay, toDate, etc.). No beans and no dot-notation property access are permitted by default.

The allow-list can be extended via three optional process engine configuration properties:

• allowedExpressionFunctionsInQueries – additional EL function and chained method names (comma-separated)
• allowedExpressionBeansInQueries – bean names accessible in query expressions
• allowedExpressionPropertiesInQueries – dot-notation property names accessible in query expressions

For advanced use cases – for example, when the engine is configured with a non-JUEL ExpressionManager – a custom implementation of QueryExpressionValidator can be injected programmatically via ProcessEngineConfigurationImpl#setQueryExpressionValidator. Any custom validator should uphold equivalent or stricter security guarantees than the built-in one.

See Expression Allow-List for Query API in the Security guide and the process engine configuration reference for full details.

Enabling and Disabling Expression Evaluation

In addition to the allow-list, the process engine configuration offers two flags to toggle expression evaluation in adhoc and stored queries. Adhoc queries are directly submitted queries. For example, taskService.createTaskQuery().list(); creates and executes an adhoc query. In contrast, a stored query is persisted along with a filter and executed when the filter is executed. Expressions in adhoc queries can be disabled by setting the configuration property enableExpressionsInAdhocQueries to false. Accordingly, the property enableExpressionsInStoredQueries disables expressions in stored queries. If an expression is used although expression evaluation is disabled, the process engine raises an exception before evaluating any expression, thereby preventing malicious code from being executed.

The following configuration combinations exist:

• enableExpressionsInAdhocQueries=true, enableExpressionsInStoredQueries=true: Expression evaluation is enabled for any query. Use this setting if all users are trusted.
• enableExpressionsInAdhocQueries=false, enableExpressionsInStoredQueries=true: Default Setting. Adhoc queries may not use expressions, however filters with expressions can be defined and executed. Access to filter creation can be restricted by the granting the authorization permission Filter/Create. Use this setting if all users authorized to create filters are trusted.
• enableExpressionsInAdhocQueries=false, enableExpressionsInStoredQueries=false: Expressions are disabled for all queries. Use this setting if none of the above settings can be applied.

Note that the allow-list applies on top of these flags: when expression evaluation is enabled for a given query type, the allow-list still restricts which expressions are permitted.