Why HTTP task headers in Flowable leak secrets
A process calls a third-party API, and the call needs a bearer token or API key in a request header. The question for your team is where that value can end up once the engine has run the step. Flowable is a set of Java engines for BPMN, CMMN and DMN, and the process data around an outbound call can be recorded in several places: process and case variables, history tables, application and engine logs, REST responses that return variables or task details, and the deployed model XML itself. Each of these is a separate place where a secret can persist, and each has its own access path. This page does not assume how the HTTP task handles header values internally. Confirm that behavior against the Flowable HTTP task documentation and your engine version before you rely on any masking setting, and test it with a dummy credential in a non-production environment.
Two groups of teams need this work. The first is teams running outbound integrations in regulated environments, such as banking, healthcare or public sector systems, where a leaked API key can expose customer data or allow unauthorized transactions, and where auditors will ask who could read it. The second is teams that inherited process models from another team, a vendor or an earlier migration. Those models may already contain literal tokens in header fields, and the people who deployed them may have left. Because Flowable is licensed under Apache 2.0 and runs in infrastructure you control, the controls around the secret are yours to design: database access, log retention, backup handling, deployment permissions and REST privileges. The engine stores what it is given, so the storage and access decisions sit with your organization and should be documented as such.
The practical first step is an inventory. List every model that performs an HTTP call, record which header values are literal and which come from a variable, and check which variables and history records hold them. Confirm with the Flowable team or your engine version notes how deployed definitions and historic data are retained, since a secret removed from a model may still exist in older deployments and in history. Decide, before any redesign, who owns each credential, how it is rotated, and who may view a model that contains one. Those decisions shape the remediation steps in the rest of this page.
Where outbound credentials can live and when each option fits
This table compares five places an outbound credential can come from in a Flowable HTTP task and what each exposes in model XML, variables, history and logs. Read each row against your own audit and logging settings, then choose the lowest-exposure option your team can operate. Items marked for verification depend on the Flowable HTTP task documentation for the version you run.
| Credential source | What it exposes | When it fits |
|---|---|---|
| Literal value in the model | Secret stored in BPMN XML, visible to anyone who can read or deploy the model, and copied into every deployment | Not recommended for live secrets; acceptable only for public, non-sensitive test values in a sandbox |
| Process variable | Value persisted in runtime and history variable tables, and possibly echoed in logs or exports if logging is verbose | Short-lived, non-privileged tokens passed between tasks; avoid for long-lived API keys |
| Expression reading configuration | Resolved value held in engine memory; the model shows only the expression name, but the value may surface in errors or logs (verify for your version) | Environment-specific settings loaded at startup from externally managed configuration, provided expressions cannot print values |
| Custom delegate with a secret manager lookup | Value exists only in memory during the call; the model and history hold just the reference, and access depends on the manager's policies | Teams with a secret manager and developers who can maintain delegate code and rotation handling |
| Identity or gateway layer injecting credentials | Process never sees the secret; the gateway or proxy holds it and attaches it to outbound requests | Strongest separation when the external call can route through a controlled proxy; confirm the proxy can log without headers |
Where exposed secrets end up in a Flowable deployment
A header value that carries an API key or token can be copied into several places once a Flowable engine runs it. Each place below needs its own control, because blocking one path does not close the others.
Deployed model XML
Process definitions, including the headers you set on HTTP tasks, are stored as BPMN XML and can be read back through the REST API by any caller with access to the definition endpoints. A literal key written into the model is therefore readable to anyone who can query deployments. Check who holds read access to deployment and definition endpoints, and confirm the exact privilege needed in the Flowable REST and identity documentation for your version.
Runtime and history variables
If a secret is copied into a process variable, it persists in runtime and history data and can be returned by variable queries. Users with access to process instances may see it without ever opening the model. Keep credentials out of variables, name any unavoidable variable so it is easy to find and filter, and clear or avoid writing sensitive values to history wherever your retention settings keep them.
Application and debug logs
Verbose logging of outbound HTTP requests, engine debug output or proxy access logs can record the Authorization or custom key header in plain text. Logs are often copied to central systems with wider readership than the engine itself. Confirm which loggers are set to debug in production, filter sensitive header names at the logging layer, and review log pipelines for copies of request traces.
Actuator and monitoring output
Monitoring endpoints expose operational detail about running processes and the environment around them. Configuration views or diagnostic output can reveal values that were never meant to leave the application. Restrict who can reach monitoring endpoints, confirm which properties they render, and keep secrets in external configuration rather than in values the monitoring layer can display.
Database backups and replicas
Every secret stored in the engine database also lands in backups, snapshots and read replicas, which often have looser access than production. Restores can recreate old model versions that still contain a key you already rotated. Confirm encryption at rest and restricted access for backup media, and plan rotation so that a restored backup does not reactivate a revoked credential.
Exports of process data
Reports, CSV exports and data extracts built from history tables or variables can carry header values or variables into spreadsheets and downstream systems. These copies are outside the engine's access controls. Review export queries for sensitive variables, restrict who can run them, and confirm that export jobs exclude secret-bearing fields before they are shared.
How to move credentials out of HTTP task headers
This sequence takes a Flowable model that carries literal API keys or tokens in HTTP task headers and moves each credential to a managed source resolved at call time. Each step ends with a check that confirms the value no longer appears in models, logs, history or REST responses.
Inventory every HTTP and service task calling external APIs
Export the deployed BPMN definitions and search them for HTTP tasks, service tasks and any delegate class that calls an external endpoint. Record the process, the target system, the header names and whether a literal value is present. Ask the model owners for any models deployed outside the normal pipeline, since those are the ones most likely to be missed. The step is complete when you have a list where every outbound call is matched to an owner and a credential status.
Choose a credential source for each integration
For each entry in the inventory, decide where the secret will live: a dedicated secrets manager, an environment-supplied value injected at container start, or a credential held by the integration layer rather than the process model. Confirm with the platform team which options they already operate and who is allowed to read each secret. The output is a short register that maps every integration to one source, one owner and one rotation contact.
Replace literal header values with runtime references
Change each header in the model so it refers to a named variable or configuration property that the engine resolves when the task runs, instead of containing the token itself. Keep the reference name meaningful, such as the integration name, so reviewers can see what is called without seeing the value. Confirm the exact expression syntax against the Flowable documentation for your engine version before editing production models. Done means no header in the redeployed models contains a literal credential.
Restrict who can deploy and read models
Limit deployment rights to the pipeline service account and a small set of named maintainers, and review which users or REST privileges can read process definitions and their XML. Because a model can reveal a secret reference or, if mishandled, the value itself, treat definition read access as sensitive. Check the result by attempting to list and fetch definitions with an ordinary user account and confirming the request is refused. Record who holds deploy and read rights.
Keep credentials out of logs at debug and trace levels
Review the logging configuration for the engine, the HTTP client and any custom delegate, and make sure headers are not written at debug or trace level in production. Pay attention to request dumps that some HTTP libraries produce when debugging is enabled. Confirm the effective level in the running environment rather than only in the configuration file. The check is to trigger a test call with a dummy credential and search the log output for it.
Keep the credential out of process variables and history
Look for any expression, variable mapping or script that copies a header value or token into a process variable, since variables are stored in the database, appear in history and may be returned by the REST API. Remove those mappings, or hold the value only in memory for the duration of the call. Confirm by inspecting the variables and historic variables tables for a test instance. The output is a clean variable set with no secret values.
Rotate the exposed credentials
Any credential that was ever stored literally in a model, log or variable should be treated as exposed, even if access was limited. Issue new credentials at the external provider, update the secrets source, and revoke the old values after the integrations switch over. Ask the provider how revocation is recorded so the old key is confirmed inactive. The step closes when the old credential fails against the external API.
Verify with a test process across logs, history and REST
Deploy a small test process that calls an endpoint using a known dummy secret, then run it and search every place the value could surface: application logs, the historic variables and activity tables, and REST responses for the instance and its variables. Repeat the search after any future change to the model. The sequence is complete when the dummy value is absent from all of these locations and the external call still succeeds.
How to review existing Flowable models for exposed secrets
Start the review by finding out what is already deployed, because a header leak in a model is only as contained as the places it was copied to. Export the deployed BPMN XML for every process definition, and do not limit the export to the latest version. Search each file for header names such as Authorization, api_key, x-api-key and token, then search for literal high-entropy strings that look like keys, such as long Base64 or hexadecimal runs. Record each hit with its definition key, version and the element it sits on, since a secret in an HTTP task is often also reused in a script task, a service task or a variable expression.
Older versions need the same treatment. Deploying a new definition does not remove the prior ones from the database, and the engine keeps them so that running instances can finish on the version they started with. Confirm with your own test environment how your deployment process and your Flowable version handle old definitions before you assume a delete will clear them, and check the repository table and deployment records directly. Then trace each hit to everything it could reach: process variables, history tables that retain variable values, job and execution data, application logs, and any monitoring or audit exports. A secret that reached a log or history table is exposed to every reader of those stores, not only to the model author.
Remediate in a fixed order. Rotate the credential first, at the external service, because a copied key stays usable until it is revoked whatever you change inside Flowable. Next, change the model so that the header value comes from a secured configuration source rather than literal XML, and remove the secret from any variable or log path you traced. Only then deploy a new definition version. Decide in advance what happens to running instances that still reference the old version, including whether they finish, are migrated, or are stopped, and confirm that the rotated credential is what those instances will use when they reach the HTTP task.
How the approach changes by deployment style
When the engine runs as a JAR inside a Java SE application or a servlet container such as Tomcat or Jetty, your application code usually owns the engine configuration and the process definitions. Secret values for HTTP task headers are typically resolved by your own code, from environment variables, a secrets manager or a configuration file that the container reads at startup. The application team and the platform team share responsibility for the logs, because the engine writes to whatever logging framework the host application has configured.
- Configuration hooks: Confirm the exact engine configuration and header handling for your version in the Flowable configuration docs before relying on any property name.
- Log ownership: Check which appender, level and format the host application uses, since debug logging of outbound requests may come from the application's HTTP client as well as the engine.
- Variable storage: Review whether header values are ever copied into process variables by your own delegates or listeners, because variables persist to the database.
- Container configuration: Confirm where environment variables and mounted files are read, and who can change them on each server or pod.
- Dependency surface: Track the HTTP client libraries bundled in the application, since their debug output is outside the engine's control.
Confirm with your engineers which configuration source the container uses and whether any header value reaches a log line in a non-production run.
When the engine runs through the Flowable Spring Boot starters, secrets usually live in Spring configuration: application properties, profile-specific files, environment variables or an external configuration source your platform supplies. Spring's property resolution determines the value, and the engine receives it through the Spring context. Log ownership sits with the Spring Boot logging setup, and the actuator endpoint at /actuator/flowable adds a monitoring surface that must be scoped on its own.
- Configuration hooks: Confirm the starter version and property keys in the Flowable Spring Boot docs because supported Spring Boot versions change between Flowable releases.
- Actuator exposure: Check whether
/actuator/flowableand other actuator endpoints are exposed beyond the internal network, and whether they reveal variables or task details. - Logging configuration: Confirm the logging levels for Spring's HTTP and client packages, since verbose settings can echo headers.
- Externalized secrets: Decide whether secrets come from a secrets manager integrated with Spring or from environment variables, and verify that Spring does not print resolved property values at startup.
- Profiles and overrides: Review that production profiles do not carry demo or development values that were copied from examples.
Check with your team that the actuator endpoints and logging levels in the deployed profile match the design, not the local development profile.
When Flowable runs as the REST application and other systems call it over HTTP, the HTTP task headers are defined in process models deployed to a server you operate, and the secret values are resolved on that server. Model authors may not be the people who manage the server's environment, so the controls split between the model review process and the runtime configuration. The REST surface itself is an additional exposure, because callers that can read process data or deploy models may be able to observe header configuration indirectly.
- Configuration hooks: Confirm how the REST application reads its settings and environment variables for the version you run, using the Flowable getting started guide as the starting point.
- REST exposure: Limit which endpoints are reachable and by whom, and confirm how authentication applies to deployment and history queries that could show definitions or variables.
- Model review: Require review of any deployed model with an HTTP task before it reaches production, since the header definitions live in the model file.
- Access logs: Decide what the reverse proxy and the application log for each request, and whether query strings or headers are captured.
- Shared hosting: If several teams deploy to one REST instance, assess whether they can read each other's definitions and history.
Confirm with your security team who can deploy models and read history on the REST instance, and test whether a header value appears in access logs or history output.
What to confirm for your Flowable version and integration
The HTTP task, the secret store and your logging stack each decide whether a header secret stays hidden. Confirm these items against the vendor documentation or your own test environment before you commit to a design, because the answers depend on the Flowable version, Java baseline and tooling you run.
HTTP task hooks in your version
Confirm which HTTP task behaviors and configuration hooks exist in the Flowable version you run, including how header values are set, whether they can be resolved from an external source at runtime, and whether any hook lets you suppress or mask values before the engine writes them. Do not assume a feature exists because a newer release has it. Test each option in a non-production environment and record the exact configuration that worked.
Flowable 8.0.0 framework baseline
Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4, dropped support for Spring Boot 3 and made Jackson 3 the default JSON library. If you upgrade, custom delegates, serializers and logging configuration that touch headers or request bodies may change behavior. Check that your masking code compiles and runs against the new baseline, and that log output still matches your redaction patterns after the change.
Secret store client compatibility
Confirm that the secret store client library you plan to use supports your Java version and the Spring stack your Flowable release requires. Check its minimum Java level, its transitive dependencies and whether it works with the Jackson version in your application. A client that fails on your baseline pushes teams toward hardcoded credentials, which defeats the design.
History retention for sensitive variables
Determine whether history retention settings can be changed for specific variables or process definitions, and whether header values or variables passed to HTTP tasks are copied into history tables. If history keeps values you intended to hide, a log fix alone will not remove them. Ask for the retention behavior in writing and test it with a sample credential before you deploy.
Log aggregation storage and indexing
Identify how your log aggregation tool stores, indexes and retains what the engine writes, including debug output from the HTTP task and stack traces that include header values. Search for the test secret across ingestion, indexes, backups and dashboards. Confirm who can query those logs, because a masked value in the engine can still appear in a shared search index.
Questions teams ask before securing HTTP task secrets
How much effort does a review and fix of HTTP task secrets take?
The effort depends on how many places a secret can reach, so there is no fixed figure until someone counts them. The main drivers are the number of BPMN and CMMN models that contain HTTP tasks, the number of external integrations each model calls, how much process history already holds headers or variables with credentials, and whether a secret store such as a vault already exists. A team with a small model set and an existing store can scope the work quickly. A team with many deployed versions and years of history will spend more time on discovery, on deciding what to purge, and on coordinating with the systems that issue the keys. Ask any partner to base a quote on a written inventory of models, integrations and history retention.
Can our own team secure HTTP task headers without a partner?
Yes, if the team has three skills: working knowledge of Flowable's BPMN and HTTP task configuration, experience operating a secret store, and the ability to review logs and history for leaked values. Many teams can handle the model changes and the header move internally. Where teams often need help is in the exposure review across old process versions and history tables, and in designing a pattern that keeps secrets out of variables from the start. Decide which of these you can staff before you start, and note that the review itself is easier to do with someone who has not written the models.
What do we need to provide before the work starts?
The work needs four things from your side. First, read access to the deployed process and case definitions and to the history data, so the exposure review can run against real content. Second, a test environment that mirrors production closely enough to validate header changes and log output. Third, rotation authority, meaning a named owner who can issue new keys at each external provider and approve cutover dates. Fourth, access to application, engine and gateway logs for the period you want reviewed. Confirm each of these in writing, because a missing item usually delays discovery rather than the fix itself.
Do we have to rotate credentials if a secret may have leaked?
Yes, rotation is the first step once exposure is confirmed. Masking headers going forward does not remove a value that already sits in logs, history or variables, and anyone with read access to those stores could still use it. Treat a confirmed exposure as a compromised credential: issue a new key at the provider, update the secret store, switch the HTTP task to reference it, and then revoke the old key. Clean up stored copies afterward, and record the dates so your incident and compliance records show what was exposed and when it was closed.
What does a fixed-scope engagement cover for HTTP task secrets?
A fixed-scope engagement covers the work you agree in writing before it starts. Typically that includes an inventory of models and integrations that call external APIs, a review of headers, variables and logs for secret values, a change plan for moving credentials into your secret store and referencing them from HTTP tasks, validation in your test environment, and a cleanup plan for historical data. Rotation at external providers is often handled by your team or the provider, so confirm who performs each step. Ask the scope document to list what is excluded, including any production changes, provider accounts and log retention decisions that stay with you.
Where should API keys live instead of HTTP task headers?
Keep them in a dedicated secret store that your organization controls, and let the HTTP task reference a named entry rather than carry the literal value. Options include OpenBao, which is an open-source secrets manager in this catalog, or an existing store your organization already runs. The design question is how the engine or worker retrieves the value at runtime, how access to the store is scoped per integration, and how rotation reaches running processes without redeploying models. Confirm with the Flowable documentation for your engine version how HTTP task headers are resolved before choosing the pattern.
How do we check that no secret is still exposed after the fix?
Verify with evidence rather than assumption. Search application logs, engine and gateway logs, the history tables and process variables for the patterns your keys follow, such as known prefixes or header names, across the period you care about. Repeat the search after each change and after rotation. Keep the search queries, dates and results in a record your compliance or security team can review. Keep in mind that a search only finds what it is designed to match, so include header names and value formats from your integration inventory, not just generic patterns.
How DeployOpen scopes and delivers HTTP task secret reviews
DeployOpen treats secrets in Flowable HTTP task headers as a defined piece of work with a written scope. We review how each HTTP task sends credentials, move them into storage the engine can reference without logging them, and document the result for your team to run.
How we scope
- Inventory every HTTP task in your deployed process definitions that sets an Authorization or API key header.
- Agree in writing which models, environments and outbound services the review covers before work starts.
- Confirm with your team where credentials are currently kept, who can deploy models and who reads engine logs.
How we build
- Replace literal tokens in model headers with references to externally stored credentials, in the form your environment supports.
- Test that task execution, failed-job records and history no longer display header values in plain text.
- Check that the change works with your async executor retries so credentials are not written into job or variable data.
How we hand over
- Provide a written register of each HTTP task reviewed, the credential source it now uses and the owner of that source.
- Document the deployment and rotation steps for outbound credentials so your platform team can repeat them without DeployOpen.
- Record the controls on who may deploy or edit models, so that new literal secrets are caught in review.
How we support
- Fixed-scope engagements end with the agreed deliverables, and any further review is scoped separately in writing.
- Ongoing support, upgrades and continuous testing are available as a retainer for teams that add HTTP tasks over time.
- Ask any partner to confirm how credential stores, log sinks and Flowable version changes will be handled in your environment.
