All Collections

Running an audit

The buildprint audit command runs local security checks against the synced Buildprint branch workspace. It is useful before risky changes, before handing a branch back to a user, or before merging a branch that touched privacy, backend workflows, uploads, authentication, or API connector settings.

Audit is advisory. It reports programmatic findings that still need product context and human review. It does not modify Bubble, block buildprint apply, deploy to live, or replace Bubble's own issue checker.

Run an audit

Run audit from inside a branch workspace:

buildprint sync
buildprint audit

Use JSON for automation:

buildprint audit --json

The command reads the local files currently on disk. If someone changed the Bubble branch in the editor after your last sync, run buildprint sync first.

What it checks

buildprint audit is currently security-focused. It checks for:

  • Data types with no Bubble privacy rules.

  • Data types that grant public read, search, attachment, or field access.

  • Public backend workflows that appear to lack an authorization gate.

  • File and picture uploaders that store public files.

  • Temporary password actions running in frontend workflows.

  • Page redirect guards that look security-sensitive but will not run as server-side redirects.

  • Secrets, API keys, tokens, or credentials copied into workspace files, when gitleaks is installed.

It does not currently run general performance checks.

Understanding results

Human-readable output includes the path, severity, check id, title, explanation, and suggested fix:

data_types/orders/type.json
  high [public-data-types] Data type has no privacy rules
    Data type 'Orders' has no privacy_role entries, leaving it publicly readable in Bubble unless another layer blocks access.
    Fix: Add privacy rules for this data type. At minimum, define an everyone role with conditions and only the record and field permissions that should be public.

JSON output has this shape:

{
  "message": "These audit results are programatic checks. Consider each result in context of the desired application logic",
  "results": [
    {
      "check": "public-data-types",
      "title": "Data type has no privacy rules",
      "message": "Data type 'Orders' has no privacy_role entries, leaving it publicly readable in Bubble unless another layer blocks access.",
      "fix": "Add privacy rules for this data type. At minimum, define an everyone role with conditions and only the record and field permissions that should be public.",
      "severity": "high",
      "path": "data_types/orders/type.json"
    }
  ]
}

Severity is intentionally conservative. A high finding does not prove the app is exploitable, but it means the configuration should be reviewed before the branch is shipped.

Fixing common findings

For public data type findings, review the type's Bubble privacy rules. Add an everyone role only for records and fields that are intentionally public. For private data, add role conditions or remove public search, view, attachment, and field permissions.

For public backend workflow findings, require admin-only authentication or add a workflow condition that proves the caller is authorized for the specific operation. Authentication alone is not authorization.

For uploader findings, set the file or picture uploader to private and attach the uploaded file to a Thing protected by Bubble privacy rules.

For frontend temporary password findings, move the temporary-password assignment and every later use of that password into a backend workflow. Do not expose the temporary password result to frontend workflow steps.

For redirect findings, use a Page is loaded workflow whose first and only active action is a simple Go to page action to another page. Keep the condition server-evaluable, do not send page data, and only add static URL parameters.

For secret findings, remove the value from the workspace file, rotate it if it may have been exposed, and store it in the relevant private API Connector or plugin setting. Buildprint does not read or store private Bubble API keys or plugin secrets, so agents cannot move those values for you.

Secret scanning

Secret scanning uses gitleaks when it is available. If gitleaks is not installed, buildprint audit still runs the other security checks and skips secret scanning.

Install Gitleaks locally when you want buildprint audit to catch copied API keys, tokens, or credentials in the branch workspace:

brew install gitleaks
buildprint audit

Gitleaks results are redacted before they appear in audit findings.

Limits

buildprint audit only sees the synced local branch workspace. Direct Bubble editor changes are invisible until you run buildprint sync again.

Audit findings are not automatically fatal for buildprint apply. Treat audit as a release checklist tool for security-sensitive branches, especially when changing data privacy, exposed backend workflows, uploads, logins, redirects, or API connector configuration.

Was this helpful?