Running an audit

buildprint audit runs local security checks against a Buildprint branch
workspace. It can be used specifically to audit the entire application for issues relating to security and performance.

The audit is a guardrail, not a deployment gate. It reports programmatic
findings that need product context and human review.

When to run it

Run the audit after syncing the latest Bubble branch and after making local
changes:

buildprint sync
buildprint audit

For automation or agent workflows, emit structured JSON:

buildprint audit --json

The command must run from inside a Buildprint branch workspace created by
buildprint project clone <appId> --branch <branch>.

What it checks

buildprint audit currently looks for:

• Data types with no Bubble privacy rules.

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

• Public backend workflows that 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.

• Publicly exposed API secrets

Findings are sorted by severity first, then by file path and check details so
the highest-risk items appear at the top.

Understanding results

Human-readable output includes the file path, severity, check id, summary,
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 programmatic 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 does mean the configuration should be reviewed before the
branch is shipped.

Fixing common findings

For public data type findings, review the data type’s Bubble privacy rules. Add
an everyone role only for fields and records 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 the same as 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 made after the last sync are invisible until you run
buildprint sync again.

The audit does not modify Bubble, block buildprint apply, merge branches, or
deploy to live. It also does not replace Bubble privacy review, manual testing,
or Buildprint Reviews. Use it as one step in the release checklist for
security-sensitive branches.