Budibase automation identity: requester, app role, or privileged worker
Budibase lets a team build an internal app and attach automations, datasources, and an agent-like workflow. The same app can be used by an end user with a narrow role and by an automation that needs broader access to a backend. The security decision is not only which role a user has. It is which identity an automation uses when it performs an action.
Budibase's documentation separates workspace roles, app roles, and end-user access. It also describes an automation agent that can run with the requester's identity or access resources outside the requester's role. That distinction is important. A user who cannot read a table directly may still trigger an automation that can.
Map the role model before granting app access
Review the workspace role and the app-specific role for each user. A creator in one workspace may be an end user in another. The combination determines whether the user can edit the app, publish it, change data sources, or only interact with screens.
Use the platform's preview or test controls to view the app as a different role. Test a screen that lists records, a form that creates a row, and a query that reads a restricted table. Confirm that the backend enforces the same access you see in the interface.
Data sources are shared across a workspace. A datasource added for one app may be available to another app in the same workspace. Review the datasource inventory and the credentials behind it, not just the app list.
Make automation authority explicit
An automation can run under the requester's identity or use a system role with broader access. The first model keeps the user's permissions in the path. The second can perform tasks that the user cannot perform directly, which may be necessary for approvals or scheduled jobs but creates a privilege boundary.
Document each automation that uses a system identity. Record the trigger, the data it can read or write, the role it runs under, and the reason the requester's identity is insufficient. Require an approval for a change that expands the automation's resource access.
Do not rely on the absence of a UI button as an authorization control. A user may call an endpoint or trigger an automation through a public app path. Test the action with a role that should be denied and confirm the response does not leak data.
Protect hosting secrets and test environments
Budibase hosting settings include sensitive environment variables for database access, object storage, and JWT signing. Rotate these values carefully and verify that every service instance uses the same intended configuration. A change made only to one container can create inconsistent authentication behavior.
Keep development and production data sources separate. A test automation should not use a production secret with broad write access. When a workflow needs production data, use a dedicated account and a small set of tables or API operations.
Restrict who can export or copy an app. An export may contain sensitive configuration or references to credentials. Review the backup and migration process, including the environment variable values required to restore the app.
Measurement
ZoomEye can identify systems that expose a Budibase application fingerprint. The count is a starting point for finding owned or shadow deployments. It does not show whether an automation is public, which role it uses, or whether a datasource is connected to sensitive data.
On 2026-11-11, a count-only query with dork app="Budibase", sub_type=all, page 1, and page size 1 returned 3,685 matching assets. The deterministic search link is the Budibase ZoomEye query. The total describes matching product assets, not confirmed vulnerable apps or exposed credentials.
Use the measurement with DNS and cloud ownership data. Validate a host before accessing it. If an unmanaged instance belongs to the organization, review its workspace membership, public app links, datasource credentials, and automation triggers.
Review a suspected exposure
Start with the public app and automation inventory. Identify which apps can be opened without authentication and which automations can be triggered from outside the workspace. For each automation, determine the execution identity and the resources it can reach.
Review logs for role changes, app publication, datasource edits, and failed authorization. Preserve the app version and automation definition before changing a role or rotating a credential. If a credential is exposed, revoke it and check the downstream system for activity from the automation identity.
After containment, remove unused data sources, replace shared accounts with dedicated automation identities, and reduce the number of workflows that can run outside the requester's permission. Require a periodic review of the users who can publish apps and edit automation definitions.
Budibase makes it easy to connect an interface to an action. The security model has to make the actor behind that action visible.
Top comments (0)