bubble app security: a privacy-rules and API checklist before Live

Problem: UX help is not hardening

Search mixes how to use bubble app tutorials with real bubble app security work. I ship solo as a bubble.io app builder. Hiding an admin link is not access control. Server-side privacy rules, API exposure, workflow auth, and field-level least privilege are what I fix before Live. A closer look: Bubble MVP in two weeks:.

Bubble uses shared responsibility: the platform runs infrastructure; I own authorization design, secrets, and integrations. A closer look: AI coding for Bubble builders:.

1. Privacy Rules baseline

• New data types. Since 2021, new types default to public unless you mark them private at creation (which adds a creator-only placeholder rule). I do not defer rules until after launch.
• Rule shape. Additive grants for roles/conditions, then Everyone else denies for view/search/modify where needed (see Admin-on-User patterns in the manual).
• Fields, not just elements. Allowed view fields can reach the browser even when hidden in the UI. I minimize exposed fields per role.
• Search privacy mode (Settings → General): Strict is recommended for sensitive apps; Automatic may allow inference via page-defined searches. Moving to Strict broke searches for me until I configured constrainable fields—I plan for that migration.
• Built-in User type. I audit its rules with the same rigor as custom types.

I use the Privacy rules checker with sample data in each type I care about.

2. Roles: server rules, not popups

Common SaaS pattern: role on User (e.g., a User Role option set) referenced in privacy rule conditions (company/tenant fields, creator, etc.).

• Option sets ship to the client and have no privacy rules—I never store API keys or internal tokens there.
• Page-load redirects away from admin routes improve UX but do not replace data-type rules.

3. URL parameters and temporary data

Docs are explicit: URL params and custom states are editable and not encrypted.

• Passing a thing’s unique id in the URL is fine if privacy rules block unauthorized read/update.
• I never put secrets, tokens, or sensitive values in URLs or custom states.

4. Workflows vs auto-binding

Privacy rules do not stop database writes via workflows the way they gate auto-binding. I guard edits/deletes with Only when conditions. I enable Allow auto-binding only on fields that should be user-writable from the client.

Mechanism	What it is for	What privacy rules do (or do not)
Workflows	Database writes via workflows	Do not stop writes the way they gate auto-binding
Auto-binding	Client-side writes to fields users should edit	Gate auto-binding (unlike workflow writes)
Only when conditions	Guarding edits and deletes	Complement privacy rules; not described as blocking workflow writes
Allow auto-binding	Fields that should be user-writable from the client	Enable only on those fields; not a substitute for workflow write behavior

5. Data API and Workflow API

Data API (disabled by default):

• Admin bearer tokens grant full DB access and ignore privacy rules. I treat them like root credentials; separate dev/live; least count.
• User-authenticated API calls respect privacy rules.
• I expose only the types and operations I truly need externally.

Workflow API:

• A public endpoint (no auth) is callable by anyone who knows the URL—workload/abuse risk, not only data leaks.
• Ignore privacy rules when running the workflow elevates server-side access to admin-level data—dangerous with weak endpoint auth or broad internal searches.
• I layer endpoint authentication, in-workflow conditions, and privacy rules on user-facing paths—I do not use ignore-rules as a shortcut.

See Data API security and Workflow API security.

6. API Connector secrets

• Default server-side routing keeps private auth off the client.
• I avoid risky Use as: Data combinations with weak auth when sensitive params sit in query/body.
• I put keys in private headers; I never store keys in option sets, page workflows, or URL params; I separate dev/live keys.

7. Security Dashboard (scan.bubble.io)

Automated checks complement manual review: privacy/search modes, leaked credentials, unsafe connector configs, unauthenticated API workflows, password policy, and more. Heuristics miss issues—I retest after fixes.

8. Dev-app test matrix (author-derived)

Bubble docs describe tools but not a minimal scenario list. Before Live, I run this with 2–3 test users (roles/tenants):

1. Logged out — hit deep links with another user’s record id; try public searches; probe Data API if enabled.
2. Wrong role — id swap in URL; attempt API workflow calls with the wrong session.
3. Correct role — confirm legitimate flows still work after tightening rules.
4. Browser inspection — verify ordinary users do not receive excess fields in responses.

9. Third-party plugins

Official docs do not guarantee plugin data residency. Community guidance: plugin authors do not get Bubble DB access unless your workflows send data via the plugin’s external calls. I review what leaves my app; I use plugin secret fields instead of public properties flagged by the Security Dashboard. Same topic: Bubble.io pricing in 2026: which.

10. OWASP LCNC as an external frame

I map my review to OWASP Citizen Development / LCNC risks (authorization misuse, leakage, secrets, misconfiguration, untrusted components)—adaptation only, not Bubble-specific procedure.

Pre-Live order of operations

1. Privacy rules and search mode on every type holding PII or payments.
2. Roles enforced in rules, not only UI.
3. Clean URLs/custom states.
4. Workflow conditions and auto-binding review.
5. Lock down Data/Workflow API; authenticate endpoints.
6. API Connector routing and keys.
7. Security Dashboard plus manual scenarios.
8. Plugin pass.

bubble.io login handles session identity; it does not replace per-type privacy rules on my data.

Sources: Security | Bubble Docs, Protecting data with privacy rules, Security dashboard.