We've updated Privacy Rules and the security dashboard as part of routine, proactive security maintenance.
Privacy Rules previously let you control whether a field can be viewed and whether a record can be found in searches. This update adds a third control: whether a field can be used as a search constraint, giving you more precise access management.
What's included
A new "constraint" permission in Privacy Rules – field-level control over which fields can be used as constraints in app searches, independent of whether the field can be viewed.
A new "Constrainable Fields" issue type in the security dashboard – flags fields that are not viewable but still usable as search constraints.
App Search Tool – new "search by" option, "Uses constraint field" – helps you find where a field is used as a search constraint. Note: this option has already shipped and isn't behind a feature flag.
Search Privacy Enforcement (infrastructure) – a platform-level change and in-editor setting that protects against unauthorized searches across apps.
Carveouts – proactively granted Constraint access on affected privacy rules (based on shadow-testing logs) before deployment to avoid breaking existing searches.
What 'constrainable' means
A field is constrainable if it can be used as a constraint in a search within an app – e.g., Search for Users where email = x@example.com or Search for Orders where status = paid. The fields after where are constraints.
This is separate from whether a field is viewable. The four combinations are all valid:
Viewable | Constrainable | Meaning |
Yes | Yes | Standard, fully accessible field. |
Yes | No | Visible to users, but can't be used to filter/search. |
No | Yes | Hidden value, but still usable as a search constraint. Still supported for legitimate use cases. |
No | No | Fully restricted. |
Search Privacy modes
Search Privacy is a branch-level application setting that controls how Constraint permissions are enforced in privacy rules. There are three modes:
Strict – every constraint is checked against Privacy Rules, regardless of where the search originates. This is generally recommended for the highest level of security and control.
Automatic – Bubble allows constraints that match a search defined on one of the app's pages; constraints are validated against detected page-defined searches. This mode is intended for applications where Constraint permissions have not been explicitly set. "Automatic mode” will be applied to all existing apps at the time of launch. Automatic mode does not detect every search constraint – see Carveouts below.
Off – enforcement disabled. Constraint access is automatically granted for all fields, regardless of Constraint permissions set on privacy rules. Users will see this warning in their privacy rules tab. Not recommended.
You can find this setting in the Settings > General tab.
The new search privacy setting.
Warning message displayed when Search Privacy is turned off.
Why is this setting useful?
A legitimate search always originates from something that exists in the app — a repeating group, a dropdown, a workflow, etc. An attacker's search doesn't come from any of those places. It's just a rogue query arriving from thin air.
Bubble can now inspect the source of every incoming search to ask: "Does this search match something that's actually defined in this app?" If the answer to that question is “yes”, that search will have a known provenance and be allowed to continue. Searches without known provenance will be compiled differently to block unknown/potentially exploitative queries.
Default Search Privacy modes
Type | Default mode | Created date |
Existing applications | Automatic | Prior to July 7, 2026 |
New applications | Strict | After July 7, 2026 |
New applications based on templates | Strict | After July 7, 2026 |
Carveouts
Automatic mode does not always detect all search constraints used by searches defined within the scope of an app's page. To avoid breaking searches that were confirmed active (via log data) before Automatic mode existed, Constraint permissions must be explicitly granted on the applicable Privacy Rules. This applies mainly to existing apps set to Automatic mode when Search Privacy deploys. Prior to deploying Automatic mode, engineering will explicitly grant Constraint access on Privacy Rules on a very small percentage of applications, based on the results of testing that has surfaced discrepancies with those apps. This will be a one-time change.
Privacy Rules: new Constraint option
A new field-level permission alongside the existing view and search permissions. When "Find this in searches" is selected, you'll now see separate checkboxes for both "View" and "Constraint" – previously there was only a "View" option. This lets developers control whether a field can be used in search constraints and filters, separately from whether it can be viewed. Previously, developers could only control the ability to view.
Applies when
Find this in searchesis granted on a data type.Grants access to use a field as a search constraint.
Fields granted Constraint are considered constrainable.
Constraintis enforced independently ofViewfield-level permissions. Possible combinations of Constraint and View are:Viewable and constrainable
Viewable
Constrainable
⚠️ If a field is constrainable, it can be searched. To prevent all access to a field, do not grant View or Constraint permissions.
New constraint permission.
Warning if view and constraint don’t match.
How the "constraint" permission is stored
The constraint permission lives in App JSON under non_filterable_fields[field]:
Value | Meaning |
| Constraint access not granted (field is non-constrainable). |
| Constraint access granted. |
undefined (key absent) | Field is not defined in |
If you've never touched the constraint setting, it just follows your existing View permission. Once you explicitly set it, it's stored and enforced on its own.
Constrainable Fields in the security dashboard
The Security Dashboard will include a new high-priority issue regarding privacy rules: sensitive data type has fields that are constrainable but not viewable.
The scan will flag fields only where they are tagged as "sensitive data" in the Security Dashboard. After the user runs a scan, a tooltip will appear to explain what the new issue is, and a link to the manual on how to resolve it.
The tooltip will be dismissible and will only appear once, meaning it won’t reappear after dismissal. The same details shown in the tooltip will be permanently available in the issue's details panel.
App Search Tool: 'Uses constraint field'
The App Search Tool has a new "Search by" option: "Uses constraint field". Use it to find where a specific field is used as a search constraint — filter by Type name and Field name, then click through the results.
Known edge cases
Slug fields
If a flagged field is used as a page slug (a page set to a content type using that field as its unique identifier), unchecking "constraint" may break page routing. Take extra care with these cases – always check whether the field is a slug before recommending the user disable constraint access.
Data API behavior
In automatic mode, Bubble allows constraints that match a search defined on one of your app's pages. A Data API call has no page context, so detection always comes up empty and the request falls back to Privacy Rules. In strict mode, every constraint is checked against your privacy rules regardless of origin.
Searches breaking after a Privacy Rule change
If a field that was previously used in search constraints is marked non-constrainable, searches relying on it may stop returning results or behave differently. The user may need to update workflows or their Privacy configuration.