Which parts of a Flowable deployment widen the attack surface
When a security team asks which endpoints and beans a Flowable engine exposes, the honest answer is a list of choices your team has to make: what the REST application publishes, whether the actuator endpoint is reachable, and which Spring beans are visible to expressions. Reducing the surface means deciding each of these deliberately and keeping Spring, Spring Boot and Jackson on supported versions so that framework flaws do not sit underneath those choices. Teams need this work before the first external exposure, after adding Spring Boot starters that bring in new endpoints, and before any major upgrade that changes the framework baseline.
The Spring Boot docs describe an actuator endpoint at /actuator/flowable for monitoring running processes, and the REST application is reachable over HTTP by design. Both are useful to operators and both reveal process definitions, instance state and variables to anyone who can reach them. Start by inventorying every route and actuator endpoint in the build you deploy, then confirm in your own environment which ones answer without authentication or from networks you did not intend to serve. The Flowable Spring Boot docs and the Flowable configuration docs describe these surfaces, but the exact property names and defaults change between versions, so verify them against the version you run before writing firewall or gateway rules.
Dependency currency belongs in the same review. Flowable 8.0.0, released on February 27, 2026, moved to Spring Framework 7, Spring Boot 4 and Jackson 3 as the default JSON library, with a Jackson 2 compatibility layer. Those changes alter which libraries you ship and which fixes you inherit, so ask your team to record the Spring, Spring Boot and Jackson versions in each environment and to set a patch cadence for them. Any expression or delegate that reaches a configuration bean should also be listed during this review, because exposed beans are easy to add and hard to notice later.
Which Flowable surfaces to inventory before exposure
Before you change any exposure, list every route into the engine and what each one can reach. The surfaces below overlap: a REST call, an expression and a bean lookup can all end up in the same code path, so review them together rather than one at a time.
The Flowable REST API
The REST application exposes engine operations over HTTP, including deployments, process instances, tasks and jobs. Anyone who can reach it with valid credentials can usually start processes, complete tasks and read variables, so the caller population matters more than the endpoint list. Confirm which client applications, service accounts and user groups call it, whether it is reachable only inside your network or from the internet, and whether it runs behind a gateway that adds its own authentication. Check which privileges each caller holds.
The actuator endpoint
The Spring Boot starter publishes an actuator endpoint at /actuator/flowable that reports on running processes. It is a monitoring feature, but it also reveals process structure and instance activity to anyone who can call it. Confirm whether the endpoint is enabled in each environment, which actuator endpoints share the management port, and whether that port is bound to an internal interface. Decide who needs this data and whether your monitoring system reaches it from a separate network segment.
Expressions in process and case models
Expressions in BPMN and CMMN models are evaluated by the engine at runtime, so a model author can effectively run code. The risk depends on who can deploy or edit models, not only on who calls the API. Inventory every expression, script task and listener in your deployed definitions, and note which ones were written by business users. Confirm whether your deployment pipeline reviews models before they reach production, and whether any model accepts user-supplied text that is later evaluated.
Spring beans and configuration objects
Expressions resolve names against Spring beans, so any bean registered in the application context can potentially be reached from a model. Configuration objects, service facades and utility classes that hold credentials, URLs or internal settings are the most sensitive entries. List the beans your engine context exposes by name, identify those that hold secrets or perform privileged actions, and confirm which of them a model can call. Remove or narrow access for anything a process definition has no legitimate need to reach.
The identity service
The identity management service stores users, groups and their membership, and the engine relies on it for candidate groups and task assignment. Whether identities live in the engine tables, LDAP or an external identity provider changes who can be impersonated and how passwords are stored. Confirm which identity implementation runs in each environment, which accounts exist by default, and who can change group membership. Map each identity source to the callers that depend on it.
Spring and Jackson dependencies
The engine's security posture inherits from Spring Framework, Spring Boot and the Jackson JSON library that parses every request body. Version 8.0.0 moved the default JSON library to Jackson 3 with a Jackson 2 compatibility layer, and it requires Spring Boot 4. Confirm the exact versions in each service, who owns patching for transitive libraries, and whether your software composition scanning covers the engine's dependency tree. Plan upgrades so that security fixes in these libraries reach production on a schedule you can state.
Exposure choices and when each fits
This table compares four exposure decisions that shape the attack surface of a Flowable deployment: REST reachability, the actuator endpoint, expression access to Spring beans, and dependency pinning. Read each row as a choice you make before go-live, with the trade-off and the question to settle with your platform and security teams. The main takeaway is that the narrowest exposure that still serves your clients is usually the easiest to defend and to evidence.
| Option | What it exposes or protects | When it fits | Trade-off or what to confirm |
|---|---|---|---|
| REST API published to internet-facing clients | Process, task and case endpoints reachable from outside your network, protected only by the authentication you configure | External applications must start processes or complete tasks directly and no gateway can mediate the calls | Requires HTTPS, strong identity, and application-level checks on every operation; confirm which privileges each caller holds |
| REST API kept on an internal network behind a gateway | Engine endpoints reachable only from approved services, with the gateway handling routing, rate limits and token checks | Most back-office and service-to-service integrations where clients already sit inside your network | Gateway policy becomes a control you must test; confirm that no alternative route reaches the engine |
| Actuator endpoint left enabled on the application port | Monitoring data about running processes served on the same port as application traffic | Only in a lab or during short-lived troubleshooting with access restricted | Monitoring data can reveal process structure and volumes; confirm who can reach the port and whether the endpoint is exposed by default in your build |
| Actuator restricted to a management port or operator network | Monitoring data reachable only from operator hosts or a separate interface | Production systems where operators need metrics but end users and external clients do not | Adds a network rule and a scrape path to maintain; confirm the monitoring stack can reach the management port |
| Expressions reaching shared Spring beans directly | Any bean in the context that an expression can name, including services that hold credentials or perform writes | Rarely justified; sometimes used for quick prototypes by developers who control the models | Anyone who can deploy or edit a model can call what the bean exposes; confirm which beans are visible to expressions |
| Logic routed through explicit delegates | A small set of named classes with defined inputs and outputs that the model calls | Production models, especially where business users or external teams author or change process definitions | More code to write and review per step; the delegates themselves must still validate inputs and enforce authorization |
| Dependency versions pinned and changed by review | A tested set of Spring, Jackson and Flowable versions that changes only when your team approves the update | Regulated environments that need a documented change record and time to test each release | Patches can lag; schedule regular reviews and confirm how quickly you can apply security fixes to the pinned set |
| Dependencies tracking the latest release | Newest security fixes and framework changes as soon as they publish | Teams with automated test coverage and a fast release path that can absorb breaking changes | Major baselines can break builds; for example, the Flowable 8.0.0 release notes describe no backward compatibility for Spring Boot 3 |
How expressions reach Spring beans and why that matters
Any bean that a BPMN or CMMN expression or delegate can resolve becomes reachable from model content, because the Flowable engine evaluates those expressions inside the application context of the host application. The model file itself is therefore part of your attack surface. A process definition that calls a bean method, or a service task that delegates to a class, runs with the same permissions as the application that loaded it, regardless of who wrote the model. Teams that treat diagrams as harmless configuration often overlook this, especially on Spring Boot deployments where many beans are registered by default.
The risk grows when non-developers edit models or when deployment is open to many people. A business analyst who can upload a definition through the REST API, a modeling tool connected to a shared repository, or a deployment pipeline without review can introduce an expression that reaches a bean nobody intended to expose. Start by listing every bean your process and case models can resolve, and by listing every identity that can deploy definitions, whether through the REST application, the Spring deployment process or a CI job. Confirm in the Flowable docs for your version how expressions resolve bean names and whether any bean is resolvable by default, because the rules differ between engine configurations and releases.
The design response is to narrow what models can reach and to control who changes them. Expose only the beans that process logic needs, give them method-level purpose rather than general utility, and keep administrative or credential-handling beans out of the expression context. Pair this with a deployment review step: model changes should pass through the same code review and approval as application code, with a record of who deployed each definition version. Ask your Flowable partner or internal team to produce a written inventory of resolvable beans and deployers as a deliverable before the engine goes into production.
How to lock down the surface before first exposure
This sequence maps every REST, actuator, expression and deployment path in a Flowable engine, then narrows each one to the callers that need it and proves the restriction holds from outside the trusted network.
Inventory every exposed Flowable surface
List each REST application or starter in use, the actuator endpoint at /actuator/flowable, every bean or service that expressions can resolve, and every path that accepts model deployments. Your platform or security engineer should record these in a single table with the owning team for each item. The step is complete when the table covers all deployed Flowable services in each environment, including non-production ones that share a network with production.
Decide which callers need each surface
For each item in the inventory, record the humans, services and workers that must reach it, such as a front end, a modeler, an operations team or a monitoring system. Anything without a named caller is a candidate for removal or disablement. Ask the application owners to confirm the list, since an undocumented integration is the most common reason an endpoint is left open. The step is complete when every surface has an owner and an approved caller list.
Restrict actuator and REST access to approved networks
Apply network controls such as ingress rules, service mesh policies or a reverse proxy allow list so the actuator and REST endpoints accept traffic only from the approved callers, and remove any public route to the management port. Confirm the authentication method for each approved caller against the Flowable REST authentication guidance, and check your Spring Boot configuration for the exposure settings that control which actuator endpoints are published. The step is complete when the configuration is in version control and a peer has reviewed it.
Review expression-visible beans and remove unused ones
Expressions and script tasks can call Spring beans registered in the engine context, so list each bean and service that is reachable from a model and remove or stop registering any that no approved process needs. Confirm with the development team which beans carry side effects, such as those that call external systems or read configuration. The step is complete when the remaining bean list is documented, each entry has an owner, and the secure scripting controls for script tasks are set in line with the team's decisions.
Confirm deployment rights for model content
Identify which identities can deploy BPMN, CMMN and DMN definitions, through the REST API, the modeler or an automated pipeline, and make sure only the pipeline service account and named administrators hold that right. Remove deployment rights from shared or demo accounts. The check is a test deployment attempted with a non-approved identity, which should be refused, followed by a deployment from the approved pipeline, which should succeed and appear in the audit trail.
Verify the result from outside the trusted network
Run requests against each surface from a host outside the trusted network and from an unapproved identity inside it. Calls to the actuator endpoint, unauthenticated REST calls, calls with the default demo credentials and deployment attempts should all be refused, and each refusal should be logged. Keep the requests and their responses as evidence. Repeat this verification after every Flowable, Spring Boot, Spring Framework or Jackson upgrade, because dependency changes can alter default exposure and authentication behavior. The step is complete when every test returns the expected result and the record is filed with the release notes for that change.
Operational checks after the surface is locked down
Locking down expressions, endpoints and dependencies is a starting position, not a finished control. The four checks below keep the exposed surface visible over time, so that a new bean, an extra endpoint or an outdated library is noticed by the team that owns it.
Log and alert on REST and actuator access
Record every call to the Flowable REST API and to the /actuator/flowable endpoint, including the caller identity, the path and the response code. Alert on failed authentication bursts, on any access to the actuator from outside the management network, and on calls by accounts that should never reach administrative paths. The platform team owns the pipeline, and the security team owns the alert rules. The pipeline needs a log destination the application cannot edit, and the engine's own logs must be retained long enough for an investigation to start after the fact.
Review beans exposed to expressions
Keep a written list of every Spring bean and service that process expressions, listeners or script tasks can call. Repeat the review whenever a model is added or a service is registered, and remove any bean that exposes methods with side effects, file access or network calls beyond what a process needs. The development lead owns the list, and the security reviewer signs off on additions. The team needs a way to diff the list between releases, so that a new bean appears in review rather than in production.
Maintain a dependency inventory
Record the exact versions of Spring Framework, Spring Boot, Jackson and Flowable in every deployed application, including transitive libraries that the build pulls in. Compare that inventory against the Flowable release notes when a new version ships, because major releases can change the Spring and Jackson baseline. The engineering lead owns the inventory, and the build pipeline should generate it from the same lock file that produces the artifact. Confirm with the vendor which versions are supported before planning an upgrade.
Test exposed endpoints from outside
Have an independent tester probe the REST API, the actuator and the expression surface on a schedule and after significant changes. Testing should start from an unauthenticated position and from a low-privilege account, and it should check that admin paths refuse those callers. The security team owns the scope and the findings, and the platform team supplies a non-production environment with production-like configuration. Ask any testing partner to confirm in writing which environments, accounts and tools they will use before testing starts.
Keeping Spring, Spring Boot and Jackson current
Dependency updates belong to the attack surface work because the Spring and Jackson libraries under Flowable parse requests, serialize responses and route the REST calls that reach your engine. A stale framework keeps known weaknesses in the same code path that exposes the endpoints you decided to keep. Flowable 8.0.0, released on February 27, 2026, moves to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and it makes Jackson 3 the default JSON library with a Jackson 2 compatibility layer. Flowable 7.x runs on Spring Boot 3, Java 17 and Jakarta EE, so the update path depends entirely on which line you run today.
Start by confirming the versions your build actually resolves, not the ones in your parent POM or starter declarations. Run your dependency tree for the Flowable starters, Spring Boot, Spring Framework and both the Jackson 2 and Jackson 3 artifacts, and check for overrides in your build or container image. If you are on the 7.x line, decide whether to stay there with a planned patch cadence or to move to 8.0.0, which the Flowable 8.0.0 release notes describe as a breaking baseline change. Treat the Spring Boot 4 move as a platform migration with its own test cycle, not a routine patch.
After any Jackson or Spring change, test JSON handling against the REST surface you expose. Serialization differences can alter how variables, dates and null values appear in responses, and a changed default can change how request bodies bind to the engine. Build tests that post and read representative process, task and variable payloads, and compare the responses with the previous release. Ask your team to confirm which Jackson compatibility setting is in effect and to record it in the change ticket, because a silent default change is hard to trace after go-live.
Hardening on Flowable 7.x or moving to 8.0.0
Flowable 7.x runs on Java 17, Spring Boot 3 and Jakarta EE, and it is the line to stay on if your platform team cannot yet move to Spring Boot 4. The 7.2.0 release, dated August 21, 2025, is the latest 7.x release supplied for this page, so first confirm that you run the newest 7.x build your organization can deploy. The Flowable 7.0.0 release notes describe the baseline your configuration was written against.
- Patch to the newest 7.x line: Read the 7.2.0 release notes and any later 7.x notes for fixes to REST and identity code before you tune anything else.
- Restrict the actuator endpoint: Confirm whether
/actuator/flowableis reachable outside the management network, and limit it to monitoring hosts or put it behind authentication. - Review beans reachable from expressions: List every Spring bean that process models call in expressions, and remove any that expose configuration, secrets or runtime control.
- Pin and scan dependencies: Keep Spring Boot 3 and Jackson at versions with current fixes, and scan the dependency tree your build produces.
- Set an exit date: Record when you intend to leave 7.x so the 8.0.0 work is not rushed by a support deadline you did not choose.
Check every configuration key against the 7.x documentation for your exact version before you change it, because property names can differ between releases.
Flowable 8.0.0, released February 27, 2026, moves to Spring Framework 7 and Spring Boot 4 and does not keep backward compatibility with Spring Boot 3. It also makes Jackson 3 the default JSON library, with a Jackson 2 compatibility layer, and removes JUnit 3 and 4 support. Each change affects how REST payloads are parsed and how the actuator is wired, so the upgrade should be treated as a security review, not only a version bump. Start with the Flowable 8.0.0 release notes.
- Jackson 3 default: Serialization differences can change how malformed or unexpected JSON is handled, so write tests for rejected input and decide whether the Jackson 2 compatibility layer is temporary.
- Spring Boot 4 security configuration: Security filter chains and actuator exposure written for Spring Boot 3 must be recreated and verified, because they do not carry over unchanged.
- Actuator and REST paths: After the upgrade, confirm that
/actuator/flowableand the REST endpoints answer only the callers you intend, using exposure settings confirmed in the Spring Boot 4 documentation. - Test framework migration: Move tests off JUnit 3 and 4 before the upgrade, so the security regression suite runs on the platform you ship.
- Java and Jakarta baseline: Confirm the Java version and package requirements in the 8.0.0 release notes instead of assuming they match your 7.x build.
Compare the 8.0.0 release notes with your current configuration file by file, and confirm each key against the 8.0.0 documentation before the cutover.
Whichever line you run, retest the same surfaces, because a passing build does not show that unauthenticated callers are blocked. Test from outside the application cluster and from outside the management network, and use a caller with the lowest privilege you issue. Keep the results with the version tested so that auditors and the next upgrade team can see what was verified.
- Unauthenticated access: Request each exposed REST endpoint and the actuator path without credentials, and confirm that each one refuses the call.
- Least-privilege callers: Repeat the requests with a standard user to confirm that the user cannot reach administrative operations.
- Expression behavior: Run process tests that call each exposed bean through an expression, and confirm that none returns configuration or accepts unexpected parameters.
- Error responses: Check that error messages do not reveal stack traces, bean names or internal paths.
- Dependency evidence: Save the dependency tree and scanner output with the release record, including the Spring and Jackson versions tested.
Record each result against the version tested and attach it to the change ticket, so the next upgrade starts from recorded evidence.
Limits and what to confirm in your environment
The exposure on a Flowable deployment depends on choices your team makes outside the engine: which artifacts you package, which identity service you run, and which beans your models call. The cards below are questions to answer with the vendor, the docs or your own test results before you size the hardening work.
Is the actuator and REST app in use
Confirm whether your build includes the actuator endpoint at /actuator/flowable and whether you deploy the Flowable REST application at all. Both are optional parts of the stack. If neither is packaged, the exposure discussed here shrinks, but you should verify that by inspecting the built artifact and the running service rather than relying on the design document. Check that no monitoring agent or ingress rule reaches the endpoints by another path.
How starters expose endpoints
Ask which Spring Boot starters your application pulls in, and whether the actuator's exposure settings are set in your configuration or left at framework defaults. Starter defaults can change between major versions, so compare the effective configuration in each environment with the settings your team intended. Record which endpoints answer on the management port and which answer on the application port.
Built-in IDM or external identity
Determine whether identities come from the engine's IDM tables or from an external provider implemented through the identity service interface. The answer decides who owns password storage, group membership and the privileges that gate REST calls. If you use an external provider, confirm which service implementation is active and whether the IDM tables still contain accounts that could authenticate.
Expression behavior in your version
Test how expressions resolve in the Flowable version you run, not in the version a blog post describes. Confirm which objects are reachable from a process variable or a listener expression, and whether a model author can call methods on them. Repeat the check after each upgrade, because Flowable 8.0.0 moved the stack to Spring Framework 7 and Spring Boot 4 and changed the default JSON library to Jackson 3.
Beans referenced by your models
Inventory every Spring bean and delegate name that appears in your BPMN, CMMN and DMN models, including expressions in service tasks, listeners and gateways. Any bean a model can reach is part of the attack surface, even if no developer meant to expose it. Compare that list with the beans you intended to publish, and remove or narrow the ones that are only needed by a single process.
Whether commercial controls are needed
Ask Flowable whether the security controls in its commercial products, such as governance and access features, cover a gap that your open-source deployment cannot close with configuration and code. Decide this after you have listed the exposed endpoints and beans, not before. Get the answer, the licensing terms and the support boundaries in writing, and confirm that the open-source engines you already run are not changed by the decision.
What buyers ask about securing Flowable expressions and REST endpoints
What drives the cost of hardening Flowable expressions and REST endpoints?
The cost follows the amount of surface to review and change. The main drivers are the number of REST endpoints you expose, how many Flowable engines and applications share the deployment, how many custom Spring beans or helper classes are reachable from expressions, and how much of the Spring and Jackson stack must be updated. A single engine behind a private network with a short list of exposed endpoints costs less to review than several engines in a shared cluster with public ingress. Ask any provider to price each surface separately in the written scope, and ask whether the quote is one-time work, recurring support, or both. Your own team pays for internal review time and change approvals, which is a cost to plan for even when a partner does the technical work.
How long does a fixed-scope hardening engagement take?
Duration depends on the same drivers as cost: the number of engines, endpoints, custom beans and environments, plus how quickly your change process approves deployments. Ask for a timeline that breaks the work into discovery, changes, test runs and production rollout, and check which steps wait on your team. Dependency updates for Spring and Jackson can take longer than expected when custom code depends on older library behavior, so ask how the provider plans to test those changes before they reach production. DeployOpen agrees timelines in writing before work starts, so the scope document should state the schedule for your environment.
What does the work need from our team?
Expect to provide architecture access, a current inventory of Flowable engines and their deployment topology, and read access to the configuration files that set exposed endpoints, the actuator, and expression beans. You will also need deployment rights in staging and production, or a defined release path through your change process, and at least one test environment that mirrors production closely enough to exercise the REST API and running process instances. Name a technical owner who can approve configuration changes and a business owner who can confirm which processes depend on which endpoints. Missing test environments are a common reason hardening work slows down.
Can our own team harden Flowable expressions and endpoints without a partner?
Yes, if your team has Java and Spring experience, can read the Flowable configuration docs, and has a way to test changes against running process instances. The work is mostly review and configuration: deciding which REST endpoints must be reachable, turning off or restricting the actuator endpoint, removing or limiting beans exposed to expressions, and keeping Spring and Jackson current. A partner adds value when your team lacks capacity, when you need an independent review of custom code, or when you want documented evidence for an assessment. Whichever path you choose, confirm each change against your own deployment rather than relying on defaults.
Does the engagement cover the actuator endpoint and dependency updates?
It can, but only where the written scope names them. The Flowable Spring Boot docs describe an actuator endpoint at /actuator/flowable for monitoring running processes, so that endpoint should be reviewed for exposure, access control and what it reveals about your processes. Dependency updates for Spring and Jackson are a separate workstream: they depend on which Flowable version you run, because the 8.0.0 release moved to Spring Framework 7, Spring Boot 4 and Jackson 3 by default, with a Jackson 2 compatibility layer. Ask the provider to list the actuator settings, endpoint permissions, dependency versions and test cases included in the scope, and to state what is excluded.
What does a fixed-scope engagement deliver?
A fixed-scope engagement should deliver a written record of the surfaces reviewed, the changes made or recommended, the configuration applied in each environment, the tests run, and the open items your team must own. For this topic that typically means an endpoint inventory, a configuration baseline for REST access and the actuator, a list of expression-accessible beans with the changes made, a dependency update record, and a rollback procedure. It should not promise that the system is secure or that an auditor will accept it. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any audit reports or certifications.
Who is responsible for ongoing maintenance after the work ends?
Your team stays responsible for the deployed configuration after the engagement closes unless you agree to a retainer. Each new Flowable release, Spring Boot update or Jackson change can reopen exposure questions, and new process models can add expressions that call new beans. Ask whether the quote includes handover training, runbooks for changing endpoint exposure, and a recurring review schedule. Ongoing support, upgrades and continuous testing are available as retainers, and their scope and cost should be quoted separately from the one-time hardening work.
How DeployOpen scopes and delivers Flowable surface hardening
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Flowable engines. For securing Flowable expressions and the REST surface, we start from the endpoints, beans and dependencies your deployment actually exposes, then change them under written scope.
How we scope
- Inventory which Flowable REST endpoints, actuator paths and Spring Boot starters are reachable from each network zone.
- List every bean and service that process expressions can call, and record the business reason for each.
- Agree in writing which Spring, Spring Boot and Jackson versions are in scope, and who approves each change.
How we build
- Restrict or disable unneeded REST endpoints and move the actuator endpoint behind authenticated, internal-only access.
- Narrow expression-accessible beans to an explicit allow list and test that expressions still resolve for approved models.
- Update Spring and Jackson dependencies in a staging environment, then run regression tests on deployed process definitions.
How we hand over
- Deliver a written record of exposed endpoints, removed beans, dependency versions and the reasoning behind each decision.
- Provide test cases that show blocked endpoints and rejected expressions, so your team can rerun them after changes.
- Document the configuration keys, deployment steps and rollback path your engineers need to maintain the hardened setup.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, Flowable upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Ask any partner to confirm how each Flowable release changes endpoints and dependencies before you accept a quote.
