Why Flowable script tasks need secure scripting before non-developers write them
If analysts or process owners can edit models that contain script tasks, the team needs to know what those scripts can reach before anyone saves a change. A Flowable script task runs script code inside the engine while a process instance is executing. The script works with the process variables in scope and with whatever objects the scripting environment makes available to it. Confirm in the Flowable configuration and BPMN documentation for your version which objects are exposed by default, because that list defines the blast radius of any script a model author writes. Treat the answer as a fact to verify in your own environment, not as an assumption carried over from another engine or an older release.
The engine's default scripting trust level decides whether script content is treated as code your developers wrote and reviewed or as input that could come from anywhere. Read the Flowable configuration docs to see how the default is set, which settings change it, and who controls those settings. The secure JavaScript configurator becomes necessary as soon as script content can be written or changed by people outside your developer group, or when models can be deployed from a source you do not fully control. If non-developers can save or deploy a model, assume the script is untrusted until the configuration says otherwise.
Before opening model editing to non-developers, decide who may deploy process definitions, whether script changes go through review, and which limits you will enforce on execution time, memory, stack depth and reachable classes. Ask your Flowable contact, or your partner, to confirm which of these controls exists in the version you run and how each one is configured. Write the answers down as part of the release record. A script that passed review once can still behave differently after a version upgrade, so the same questions belong in every upgrade plan.
Which secure scripting controls fit which deployment
This table compares the main Flowable script task controls by what each one stops, what it breaks in legitimate models, and when it fits. Read each row against the models you actually deploy, and confirm default values and option names in the Flowable documentation for your exact version before you rely on them.
| Control | What it stops | What it breaks, and when it fits |
|---|---|---|
| Class allow list | Scripts reaching Java classes outside an approved set, such as file, network or process APIs | Breaks models that call helper classes not on the list, so each new helper needs a review. Fits teams where business users author scripts from a known set of utilities. |
| Maximum execution time | Long-running or looping scripts that hold threads and database connections | Breaks legitimate heavy computation inside a script task, which should move to a delegate or external worker. Fits almost every deployment as a baseline, with the limit value confirmed for your version. |
| Memory and stack depth limits | Runaway recursion and large allocations that can exhaust the engine's JVM heap or thread stack | Breaks deeply nested or data-heavy calculations inside scripts. Fits deployments that accept scripts from non-developers, where a small, predictable footprint matters more than flexibility. |
| Secure JavaScript configurator (Rhino) | Scripts running with the broad access of the host JVM, by constraining the interpreter's environment | Breaks scripts that rely on JavaScript features or host objects the configuration does not expose, so test existing models after enabling it. Fits any deployment where script tasks are written by people outside the development team. |
| Disable script tasks entirely | All script task execution, including the class of attack that scripts enable | Breaks every model that uses script tasks, so each one must be replaced by a Java delegate, expression or external worker first. Fits regulated deployments where the engine only runs reviewed, compiled code. |
| Code review and deployment control | Unreviewed script changes reaching production through the deployment pipeline | Does not restrict what a running script can do, so it complements the runtime controls above. Fits every deployment, and needs a named approver for each process definition change. |
Setting up secure scripting in a Flowable engine
This sequence moves script tasks from unrestricted to governed. It produces an inventory of existing scripts, a documented author policy, an engine configured with the secure JavaScript configurator, an allow list based on observed needs, execution and resource limits, and a test suite that runs on every deployment.
Inventory existing script tasks and authors
Search every BPMN and CMMN model in your deployment repository and in the engine's deployed definitions for script tasks, script listeners and expressions that run script code. For each one, record the process or case definition, its version, the script language, the variables it reads, any Java classes or host objects it calls, and the team that last changed it. The step is done when the list covers every deployed version and the owning teams have confirmed their entries.
Decide who may author scripts
Agree in writing which roles may create or change script content. Developers can usually work through version control with code review, while business analysts may need to edit models in a modeling tool without writing script code. Record the rule and the approved author list, and decide whether script changes must pass the same pipeline as Java code. The output is a short policy that the engineering and process owners sign off. Check it by sampling a recent script change and confirming it followed the review path.
Enable the secure configurator in engine configuration
Turn on the secure JavaScript configurator in the engine configuration for your deployment, whether it is set through a Spring Boot starter or programmatically. Confirm the exact property names, the Rhino-based behavior and the defaults for your Flowable version in the Flowable configuration docs before you change anything. Start the engine in a non-production environment and confirm the secure configuration is active, for example by logging the effective script settings at startup. Then run one trivial script task to confirm it still executes.
Build the allow list from observed needs
Use the inventory to list the Java classes, methods and host objects that legitimate scripts call, and add only those to the allow list. Treat anything not listed as denied, and do not add broad packages to save time. Each entry should have a short justification and an owner. The step is complete when every script in the inventory runs under the allow list. If a script fails, trace the failure to a specific entry and decide whether the script should change or the entry should be added with a recorded reason.
Set execution time, memory and stack limits
Set the maximum execution time, memory and stack depth options that the secure configurator exposes, using the values your configuration docs describe for your version. Base the values on measured runtime of the inventoried scripts under expected load, and document each value with the measurement behind it. The check is a set of deliberately bad test scripts: an endless loop, unbounded recursion and a large allocation. Each should stop under the limit, and you should confirm how the engine records the failed execution in logs and job or history data.
Test with malicious and ordinary scripts
Build a test suite with two groups. The first contains the ordinary scripts from the inventory, which must produce the expected variable changes. The second contains hostile samples that try file system access, process execution, network calls and reflection on engine internals, which must all be blocked. Run these in a non-production environment only. The step is done when both groups pass and the results are stored with the release record. Include the suite in your pipeline so it runs on every deployment.
Re-review scripts on every change
Add a deployment gate that checks new or changed script tasks against the author policy and the allow list before a definition reaches production. Any new host object or class requires a documented allow list change and a fresh run of the test suite. Schedule a periodic review of the inventory, because models accumulate scripts over time. The output is a gate that rejects unreviewed script changes, and a dated review record that shows who approved each allow list entry.
Security and operational risks that remain after the configurator
A secure configurator narrows what a script can reach, but it does not decide which classes you allow, how scripts use them, or who can change a model. The cards below cover the risks that stay with your team after the limits are set, and the checks that keep them small.
Allow lists that grow too wide
Each new class added to the allow list to fix a failing script widens what every script on the engine can reach. Over time a list built for date arithmetic can end up including file, network or reflection-capable types. Review the list as a security artifact: record why each class is present, who approved it, and which models depend on it. Remove entries that no current model uses, and ask for a tested way to confirm the list has not grown since the last review.
Unsafe use of allowed classes
A permitted class can still be misused. A script that is allowed to build strings may still loop until it exhausts memory, or call a method on an allowed object that triggers work the author did not intend. Allow lists control types, not behavior. Test representative scripts against the configured execution time, memory and stack depth limits, and include hostile inputs such as very large collections and deep recursion in those tests.
Outbound calls from scripts
A script that can open a connection, or call a helper that does, can send process data to hosts you never approved. Data exfiltration and server-side request forgery both depend on this path. Decide which outbound destinations the engine needs, route external calls through service tasks or HTTP tasks where egress rules and logging apply, and confirm with your network team that the engine's hosts cannot reach arbitrary addresses.
Secrets in logged script inputs
Script tasks read process variables, and those variables can hold tokens, account numbers or personal data. When errors or debug logging record the inputs, those values are written to log storage that often has wider access than the process itself. Confirm which logger levels capture script evaluation failures in your environment, mask or exclude sensitive variables from logs, and check existing log retention before the engine goes live.
Deploy rights for model authors
Limits on scripts do not help if anyone who can upload a process definition can also change what the limits apply to. Treat deployment as a privileged action: restrict who may deploy, require review of script tasks before deployment, and keep deployment history so a change can be traced to a person. Pair these controls with the engine's secure XML handling and with the authorization your application applies to deployment endpoints.
Why scripts written by non-developers need stricter limits
Scripts written by business analysts, process owners or citizen developers need tighter limits than scripts written by engineers, because the people writing them usually do not know which parts of the engine they can reach or what a runaway loop or unrestricted class call does to a shared server. A script task in a BPMN model runs with the privileges of the engine process, so an author who copies a snippet from a forum can read variables from other cases, slow every job executor thread or call a class that touches the file system. The secure JavaScript configurator and the class allow list exist to take those choices away from the model author. Treat the engine settings as the technical floor, not as a substitute for judgment about who is allowed to write script content at all.
The bigger change is in how the model reaches production. A BPMN file edited in a modeler and deployed through the REST API or a deployment pipeline can change live behavior without a code commit, a pull request or a build step that a security team already watches. Ask who holds the deployment privilege in your environment, whether the modeling tool and the engine share credentials, and whether a script change can be deployed by the same person who wrote it. Confirm these answers with your own identity setup, because the defaults depend on how you configured authentication and privileges in your deployment.
Combine the engine limits with governance controls that match how models are reviewed. Restrict deployment rights to a small group, separate the author role from the deployer role, and require a reviewer to read every script body, not only the diagram, before release. Store approved model versions in version control so a reviewer can diff the XML and so a rollback is a known action. Add a test that runs each script task against representative variables and fails the build if the script calls a class outside the allow list. Ask your team to document which limits apply to each environment, since a permissive setting in a development engine can be copied into production by accident.
Limits to confirm in your environment before relying on secure scripting
Secure scripting limits only protect you if they apply to the engine version, runtime and script types your models actually use. The cards below cover the checks to run before you treat script task restrictions as a control.
Confirm the Flowable version and scripting behavior
Start by recording the exact Flowable engine version in production, then read the release notes and configuration docs for that version to confirm how the secure JavaScript configurator is enabled and what it restricts. Behavior can differ between major lines, and the upgrade path changes the Spring, Java and Jakarta baseline underneath the engine. Do not assume a setting from a blog post or older tutorial applies to your release.
Check the Rhino and Java baseline
The secure configurator depends on the scripting runtime bundled with or expected by your chosen release. Confirm which Rhino version the engine uses, which Java version your runtime requires, and whether your container image or application server ships a different JDK that overrides it. Record the result in your build so a base image update cannot silently change the sandbox behavior.
Map every script language your models use
The JavaScript configurator covers JavaScript only. Inventory every script task, execution listener and expression in your BPMN and CMMN models and note the script language of each one. Any Groovy, JUACC or other language script that remains unrestricted needs a separate control, such as removing that language from deployment, or a review gate that blocks it. Confirm the engine's supported script languages with Flowable before you assume coverage.
Test limits on delegates and expressions
Secure scripting limits apply to script tasks. Java delegates, expression language calls and bean references run with the full privileges of the application classpath, so a class allow list on scripts does not restrict them. Trace each delegate and expression to the code it can reach, and decide whether those paths need their own access checks or a restricted classpath. Test with a model that calls a blocked class from each path.
Verify execution time and memory limits
Confirm that the maximum execution time, memory and stack depth settings take effect in your environment, not only in a unit test. Run a deliberately long loop and a deep recursion from a deployed model under your real thread pool and async executor settings. Record the observed behavior, including what the engine does with the failed job and whether a retry repeats the same expensive script.
Confirm who can deploy scripts
Limits are only one layer. Confirm which roles can deploy process definitions, edit models in any modeling tool, or change script content through the REST API. Scripts written by non-developers should go through the same review and deployment path as code, with a record of who approved each model version. Check that your deployment pipeline enforces this rather than relying on convention.
Questions teams ask before securing Flowable script tasks
How much effort does securing Flowable script tasks take?
The effort depends mostly on how many script tasks exist, how many people write them, and how many deployed models already contain scripts. A small engine with a few developer-written scripts can usually be reviewed in a short series of sessions. A large estate with many models across several business units needs a full inventory, a classification of each script by what it touches, and a staged rollout. Most setup work is one-time: configuring the secure JavaScript configurator, writing allow lists and limits, and testing them. Recurring work comes from reviewing new scripts and revisiting allow lists when models change. Ask any quote to split the work into inventory, configuration, testing and ongoing review, and to name the models it covers.
Can our internal team secure Flowable script tasks without a partner?
Yes, if the team has working knowledge of Flowable and Java and someone who owns the decision about what scripts may do. The configuration itself is manageable. The harder parts are finding every script task across process and CMMN models, deciding which classes and resources each script may use, and confirming that legitimate scripts still run once limits apply. A team that does this work only occasionally will need to relearn these steps each time. Before starting, confirm the settings against the Flowable configuration documentation for the exact version you run, because configuration details can change between major releases.
What do we need to provide before a secure scripting project is scoped?
Three inputs make scoping practical:
- A model inventory listing every process and case definition that contains a script task, along with its author and the environments where it is deployed.
- A test environment running the same Flowable version, database type and deployment style as production, so limits can be tried against real model behavior.
- Named decision makers who approve allow lists and who can accept that some existing scripts will be rejected until they are rewritten.
Without the inventory, the scope cannot say how many scripts need review. Without the test environment, limits can only be tested on paper. Without decision makers, allow lists stall during build.
Who should decide which Java classes script tasks are allowed to call?
The decision belongs to a named owner in the business and security functions, not to whoever edits the model. Security should set the risk position, such as which classes and resources are off limits by default. Process owners should confirm which business behaviors must keep working, because an allow list that is too narrow will break legitimate workflows. Engineering implements the list and tests it. Record each approved entry with its reason and owner, so future reviews can tell whether an entry is still needed. Without this record, allow lists tend to grow with each exception and lose their meaning.
How long does it take to scope a secure scripting project?
No single duration applies to every environment, and DeployOpen does not publish one. Scoping is driven mainly by how quickly the model inventory can be produced, how many script tasks need a decision, and how many people must approve allow lists. A small set of models with clear owners scopes faster than a large estate with unclear ownership. Most DeployOpen engagements are fixed-scope, which means scope, deliverables and timelines are agreed in writing before work starts. Ask for that written scope to state the inventory method, the decisions required from your side, and the dates each step depends on.
When is outside help worth paying for with Flowable scripting?
Outside help is usually worth considering when the model count is high, when no one on the team has Flowable and Java depth, when a Camunda 7 or Activiti migration is already in progress, or when you need evidence that controls work before an assessment. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms in your infrastructure, and prepares systems and evidence for compliance assessments. DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies do that work. Compare outside quotes with an internal estimate built from the same inventory, so the difference in scope is visible.
Why do scripts written by non-developers need tighter limits?
Business analysts and process owners often edit models directly, and a script task runs inside the engine with the engine's access. A script written without engineering review can call classes it should not use, loop for a long time, or consume more memory or stack depth than the server can spare. Limiting class access, maximum execution time, memory and stack depth reduces the impact of a mistake or misuse. The limits do not replace review. Treat them as a boundary that holds even when a script is reviewed poorly, and keep the review step for scripts that change business outcomes.
What breaks when we tighten script limits on existing models?
The most common breakage is a working script that calls a class missing from the allow list, or a script that runs longer than the new time limit. Scripts that depend on a helper library or an external resource can also fail in ways that only appear on specific paths through the model. Test each deployed model against the new limits in a non-production environment, using the same data shapes production sees. Then confirm with your Flowable version how changed settings apply to definitions already deployed, and plan a redeployment or migration step where needed. Record each failure and its fix, so the allow list changes with evidence rather than memory.
How DeployOpen scopes and delivers secure scripting for Flowable
DeployOpen starts with an inventory of every script task, the people who write and change those scripts, and the engine configuration that runs them. We then agree in writing which scripting controls will be applied, tested and handed over. Engagements are fixed-scope, and the agreed scope defines what the work covers.
How we scope
- Inventory every script task, its language, and who is allowed to create or edit it
- Record which models are authored by developers and which by business users or uploads
- Agree in writing which allow list, time, memory and stack limits apply to each script class
- Confirm the Flowable version and Spring or Java baseline before choosing configuration steps
How we build
- Configure the secure JavaScript configurator on the engine and verify it is active in the runtime
- Define class allow lists and deny unlisted Java access from script tasks
- Set maximum execution time, memory and stack depth values from measured script behavior
- Move reusable logic from scripts into tested Java delegates where the team prefers that approach
How we hand over
- Provide test cases showing blocked calls, timeouts and oversized scripts failing as designed
- Document the configuration keys, their values and the reason each value was chosen
- Deliver a review checklist for approving new script tasks before they are deployed
- Train maintainers on how to request changes to the allow list through a controlled process
How we support
- Review new models and script changes against the agreed controls on a scheduled basis
- Retest script limits after each Flowable upgrade, since defaults and APIs can change
- Ongoing support, upgrades and continuous testing are available as a retainer
- Confirm support terms, response expectations and included activities in the written proposal
