Bubble Privacy Rule Mistakes: Inside a Database Leak

A developer hides a group, removes a field from a page, adds a client-side constraint, and assumes the record is no longer visible. It is not. If the data has already been sent to the browser, the application has lost control over it. A user can inspect network traffic, examine API responses, or call an exposed endpoint directly. The visual interface is only the last layer of presentation. It is not a security boundary.

This is the core of a bubble database privacy rule misconfiguration: the app appears to restrict access, while the database and server responses do not. The result can be an inadvertent Bubble app data leak involving private fields, hidden records, or entire data types exposed through the Data API.

The mechanics are straightforward. The consequences are not.

The illusion of client-side security

Bubble applications are assembled visually, which makes it easy to confuse interface behavior with access control. A condition on a page element looks like a restriction. A filtered repeating group looks private. A field that is not displayed appears unavailable.

None of these assumptions survive inspection.

Client-side filtering happens after the browser has received the relevant data, or after the application has received enough information to make a filtering decision. That means the browser is already in possession of the payload. Hiding the result does not retract it. It merely prevents the normal interface from displaying it.

This distinction matters because browsers are controlled by the user. They can inspect:

• Network requests and responses.
• JSON payloads returned by the application.
• API calls initiated by page actions.
• Hidden elements and their associated data.
• JavaScript-visible application state.
• Requests made to exposed Bubble endpoints.

A user does not need privileged access to perform this inspection. Technical skill changes the speed and method, not the underlying permission. Once sensitive data is sent to an untrusted client, the application has already made the security decision incorrectly.

A typical failure looks harmless in the editor:

1. A repeating group loads a list of company records.

2. A condition hides records that do not belong to the current user.

3. The page displays only the approved subset.

4. The developer considers the list protected.

The server may still have returned the broader set. The client-side condition controls rendering, not authorization. A determined user can look below the visual layer and find the records that the interface was instructed to hide.

This is why “the field is not visible on the page” is not a meaningful security argument. The relevant question is whether the field was delivered to the browser at all.

If a private value reaches the browser, it is no longer private. A hidden element is a design choice, not an access-control mechanism.

The same problem applies to page constraints. A page may be configured to show a record only when a user matches a condition. That can improve navigation and reduce accidental exposure in the interface. It does not replace server-side enforcement. The application needs to reject unauthorized access before the data is serialized into a response.

Why visual builders make this mistake easy

Traditional application stacks separate authorization logic from presentation more visibly. In a no-code environment, the same editor may contain database fields, workflow actions, page conditions, and visual groups. That proximity creates false confidence. Everything looks like part of one system, so developers assume every condition has the same authority.

It does not.

A condition attached to a group is a presentation rule. A constraint in a search may affect the query, but it should not be treated as the final authorization layer for sensitive records. A server-side Privacy Rule is the mechanism intended to determine whether a user can access a data type or field.

The visual interface is where access should be expressed to the user. Privacy Rules are where access must be enforced against the user.

Those are different jobs.

The shared responsibility model: infrastructure is not application security

Bubble’s security model is divided between platform infrastructure and application configuration. The underlying infrastructure, including AWS-managed physical security and DDoS protection, is not the same thing as the privacy configuration of an individual Bubble application.

This distinction is operationally important. Platform-level protection does not automatically secure the records created by a developer. Bubble can provide the infrastructure and the mechanisms for restricting data. The application owner still has to configure those mechanisms correctly.

The responsibility split is roughly this:

This is not a semantic distinction. It determines who must investigate an exposed record.

If a Bubble application has a weak Privacy Rule, the problem is not resolved by the fact that the application runs on protected infrastructure. The request may be served exactly as configured. The system is operating correctly according to defective application logic.

That is the uncomfortable part of shared responsibility models: they move security from a vague platform promise to a series of specific developer decisions. The database does not know what the business considers confidential. It knows what the rules permit.

Application-level controls are not optional hardening

Privacy Rules should be treated as part of the data model, not as a final polish step before launch. When a new data type is created, the access model should be designed alongside its fields and relationships.

For each type, the application needs an answer to a few basic questions:

• Who can read the record?
• Who can see each sensitive field?
• Who can modify it?
• Does access depend on the current user, a company relationship, a role, or a workflow state?
• What happens if the relationship is missing?
• What happens to records created before the rule was added?
• Is the type exposed through the Data API?
• Can a workflow return the record indirectly?

The absence of an explicit answer is not neutrality. It is usually an access decision made by omission.

This is particularly dangerous in growing applications. Early-stage products often begin with a small user group and a simple database. Privacy Rules are added later, after the schema has expanded and records already exist. Fields that were harmless during internal testing become sensitive when the application starts storing customer, employee, financial, or operational data.

Technical debt accumulates quietly in the same place as business logic. A rule that was “temporary” becomes part of the production boundary. Nobody remembers why it was written. Nobody checks what happens when a related field is empty. Then a new page, API endpoint, or workflow exposes the gap.

Anatomy of a leak: empty reference fields and orphaned records

One of the more subtle Bubble Privacy Rule mistakes involves reference fields.

Suppose a record contains a reference to a company. The intended rule is simple: a user can access the record when the record’s company matches the user’s company. On paper, that appears to isolate data correctly.

The edge case is the record where the company reference is empty.

Bubble can evaluate an empty reference in a way that matches an empty user state. If the rule does not explicitly require the reference field to be present, an orphaned record may satisfy the condition unexpectedly. In the wrong configuration, that can make the record available to logged-out users or to users who should have no relationship with it.

The problem is not limited to company references. The same pattern can appear with:

• Empty owner fields.
• Missing workspace relationships.
• Deleted or detached parent records.
• Incomplete onboarding records.
• Imported data with null references.
• Records created before a relationship became mandatory.

The database may contain a perfectly valid record from a schema perspective. The application may still have no valid security context for it.

The missing condition that changes the outcome

A rule based only on equality is often incomplete. It may need an additional condition that confirms the reference is not empty before the relationship is evaluated.

The logic should be considered in two parts:

1. The reference exists.

2. The reference matches the authorized user or organization.

If only the second part is present, the empty state becomes part of the security calculation. That is where orphaned records enter the picture.

The operational lesson is simple: every relationship used in a Privacy Rule needs an explicit failure path. Ask what the rule returns when the reference is absent, malformed, deleted, or not yet populated. Do not assume that “no relationship” automatically means “no access.” The platform evaluates conditions. It does not infer the business intent behind them.

A practical review of a company-scoped record might examine:

• Whether the company field is required at creation.
• Whether old records contain empty company references.
• Whether users can edit or remove the company reference.
• Whether the Privacy Rule requires the reference to be non-empty.
• Whether logged-out access is explicitly denied.
• Whether an alternative ownership path unintentionally grants access.
• Whether imported records follow the same constraints as records created in the UI.

This is not bureaucracy. It is the difference between a rule that works for the normal record and a rule that works for the database.

Orphaned records are a schema problem and a security problem

Teams often treat orphaned records as cleanup work. That is incomplete. An orphaned record can be a security state.

For example, a record may lose its company relationship because a workflow clears the field, because an import omitted it, or because a parent entity was deleted. If the Privacy Rule uses that relationship without checking whether it exists, the record has moved into a different access category. The application may not show an error. It may simply apply the rule to an empty value.

That makes orphaned data difficult to detect through normal product testing. Testers use complete records with valid relationships. Security failures often sit in the records nobody considers interesting: unfinished submissions, abandoned accounts, migration leftovers, or deleted organization members.

The database does not care whether a record is operationally important. If the record contains private data, it needs a valid access rule.

Securing the Data API: the endpoint is not the boundary

When the Bubble Data API is enabled, data types without active Privacy Rules can be publicly accessible through API requests. The endpoint pattern follows the form:

/api/1.1/obj/{datatype}

That creates a direct exposure path independent of the application’s visible pages. A user does not need to find a hidden element if the underlying data type can be requested through the API.

This is where a bubble database privacy rule misconfiguration becomes more than a UI defect. The application may look restricted in normal use while the API provides a broader view of the database. If the type has no active rules, the API can become a public directory of records and fields that the developer assumed were private.

The risk has several dimensions:

• A data type may be exposed even if no page displays it.
• A field may be sensitive even when the record itself appears harmless.
• An API response may reveal relationships to other objects.
• An attacker can automate requests rather than interact with the interface.
• A later page or integration may activate exposure that was previously unnoticed.
• A rule added to one type may not protect related types returned separately.

The correct question is not whether the Data API is being actively used by the product. The question is whether the endpoint can return data that should not be public.

API access and page access must be reviewed separately

A common audit error is to test only the application’s pages. The reviewer logs in as a standard user, navigates through the product, and confirms that restricted records do not appear. That test says little about direct access to data types.

The API should be reviewed as its own attack surface. For every data type, determine:

• Whether it is exposed through the Data API.
• Whether active Privacy Rules apply.
• What an unauthenticated request returns.
• What a basic authenticated user can retrieve.
• Whether fields are excluded or merely hidden in the interface.
• Whether linked records reveal additional private information.
• Whether search constraints are enforced server-side.
• Whether create, update, and delete operations have separate restrictions.

Read access is only one side of the problem. A weak rule on write operations can allow users to alter ownership, remove a company reference, change a status, or attach a record to a different organization. That can create a second-order exposure even when the original read rule appears correct.

For example, a user who cannot read another company’s records might still be able to modify a relationship field if the write rule is broader than the read rule. Once the record is reassigned or detached, the application’s access behavior changes. Security rules are not independent decorations. They interact through workflows and mutable data.

Data minimization still matters

Privacy Rules are necessary, but they should not become an excuse to send every field to every client. The safest response is the smallest response that serves the operation.

If a page only needs a display name and status, returning internal notes, billing data, or administrative metadata creates unnecessary exposure. Even when rules are configured correctly, excessive data transmission increases the impact of future mistakes.

This is a basic architectural principle: authorization controls who may receive data; minimization reduces how much data is available to expose.

In a no-code application, that discipline is especially useful because visual workflows can grow faster than the underlying access model. A search that begins with three fields may later be reused by a page that carries a much broader object. The interface remains familiar while the payload changes.

Audit the actual response, not just the visual result.

Auditing a Bubble app with the Privacy Rules Checker

Bubble provides a Privacy Rules Checker within the editor to inspect data types for fields accessible without restriction to logged-out or unauthorized users. It is not a substitute for judgment, but it is a practical mechanism for finding obvious exposure.

The checker should be used as part of a repeatable audit process, not as a one-time launch ritual. A clean result only means the tool did not identify the tested class of issue. It does not prove that workflows, API behavior, relationship edge cases, and business roles are all correct.

A useful audit sequence is:

1. Inventory every data type.

Include types that do not appear on the main product pages. Administrative, imported, temporary, and legacy types are common sources of overlooked exposure.

2. Classify the data.

Separate public content from internal operational data, customer information, account records, and security-sensitive fields. A rule cannot be evaluated without understanding what the record contains.

3. Review the default state.

Determine what happens for logged-out users and for authenticated users with no special role. The default path should fail safely rather than depend on a page condition.

4. Inspect every Privacy Rule.

Check the fields and relationships used by each rule. Look for broad conditions, missing non-empty checks, and rules that rely on mutable values.

5. Run the Privacy Rules Checker.

Use it to identify fields and data types accessible without restriction. Treat every finding as a database issue, not merely a page issue.

6. Test relationship failures.

Examine records with empty owner, company, workspace, or parent references. Test deleted relationships and imported records.

7. Review Data API exposure.

Confirm which data types can be requested and what responses are returned for different user states.

8. Review workflows and writes.

A secure read rule can be undermined by a workflow that modifies ownership, visibility, or relationship fields without equivalent restrictions.

9. Repeat after schema changes.

Adding a field, changing a relationship, importing records, or enabling an integration can alter the security posture. The audit must follow the schema.

This process is not complicated. It is simply more disciplined than clicking through the application and declaring it private because the restricted records did not appear.

What the checker does not absolve

Automated checks are useful at identifying configuration gaps. They are less effective at understanding whether the logic matches the business model.

A rule may technically restrict a record while still granting access to the wrong population. A company relationship may be present but point to a shared organization. A role may be valid in the database but too broad for a specific field. A workflow may expose a private object indirectly through a return value or notification.

The reviewer still needs to understand the access graph:

• Which user can reach which organization?
• Which records inherit access from that organization?
• Which fields require stricter restrictions than the parent record?
• Which workflows can change those relationships?
• What happens when the user loses membership?
• What happens when a record is archived rather than deleted?

The Privacy Rules Checker can expose an unlocked door. It cannot decide whether the person holding the key should enter the room.

The cost of postponing the fix

Security debt in a Bubble application behaves like other technical debt, except the failure mode is external exposure rather than a slow deployment. The longer a weak rule remains in production, the more records accumulate under it and the more workflows begin to depend on its behavior.

That creates three forms of overhead.

Remediation overhead. The team must identify which records were exposed, determine when the configuration changed, and assess whether the response payload contained sensitive information.

Migration overhead. Fixing the rule may reveal records with missing relationships, inconsistent ownership, or invalid legacy states. The database then needs cleanup before the stricter rule can operate reliably.

Operational overhead. Support, compliance, engineering, and management are forced into an incident process that could have been replaced by a small configuration review before launch.

The exact impact depends on the data and the application. There is no useful universal statistic for how many Bubble apps have suffered from these mistakes. What is consistent is the mechanism: data delivered to the client cannot be made private after the fact.

That is why the best time to inspect Privacy Rules is before a sensitive data type is connected to a page, workflow, integration, or API consumer. The second-best time is before the next deployment. Waiting for a visible incident is an expensive testing strategy.

The bottom line

Bubble is not insecure because it allows developers to configure application-level access. It is configurable because the application’s business rules cannot be inferred automatically from a visual schema.

The failure occurs when developers mistake presentation controls for authorization, assume infrastructure security covers database logic, or write relationship rules without handling empty references. The Data API then provides a direct path to whatever the application failed to restrict.

Securing Bubble database Privacy Rules requires a less attractive but more reliable approach:

• Enforce access on the server.
• Treat the browser as untrusted.
• Require valid ownership and organization references.
• Deny access when those references are empty or invalid.
• Review every data type exposed through the Data API.
• Audit read and write workflows separately.
• Use the Privacy Rules Checker, then verify its findings against the real business model.
• Repeat the review whenever the schema or relationships change.

The definitive verdict is simple. If the protection exists only in page conditions, the data is not protected. If the Privacy Rules do not define the server-side boundary, the application has no dependable privacy boundary at all.