Comment on page
Privacy rule checker
Scans Canvas applications for misconfigured privacy rules that expose private data to users.
Because the tool uses the Role option set associated with Users, it only works with Canvas apps made from the Base template in 2021 or later.
A professional license is required to use this feature
Privacy rules are your app's most important defense against exposing private data from your app's database. From user email addresses to transaction information, all data saved into the Bubble database needs to be protected by privacy rules.
These privacy rules are configured by the Bubble developer. We recommend setting them up while setting up your database in order to avoid additional work later on.
Before using the privacy rule checker, it's important to have a deep understanding of an app's database structure. If you are unaware of how certain features are used, it will be difficult to know which data should be shown to each type of user.
Ideally, review the DB and the app's user flows. Check where each data type is used in the app's design and logic, and what it is used for. Also look for
For the below screenshots, image a Twitter-like microblogging site where users can make short text Posts, start live streams with audio content, and some data is public. All data types can be set to public so logged-out users can see them, or "follower-only" so that only approved followers can see them.
For data types that contain any private data, mark them private. The tool will populate these by checking whether there are any privacy rules applied on a data type in order to know whether it should be private. If this tool has already been run on this app, the configuration from the previous test will be loaded here.
Note that in the above example, some data in the types marked as "private" are actually public to logged-out users. If a data type contains any data that is private in any situation, it should be marked as private.
For each data type marked as private, set up the logic for each role. Often, admins will be able to see all data, logged in users will be able to see some data, and logged out users will be barred from viewing most data.
In the microblog example, Standard users can see all data about their own Posts. They can only see Some of the data types, because users can mark their posts as private.
There are often some fields that "everyone else" will never be able to see. Maybe users can see metrics about how many times their owned posts were viewed, which wouldn't be visible to "Everyone else".
In this app, many Users are public to logged out users. The tool will always have an alert if User emails are exposed to logged out users, but it won't automatically flag other fields that might contain private data.
Individual data fields cannot be marked as private within this UI. We only check at the data type level whether things may be exposed.
Checking for data on the individual data fields would be more granular, but more cumbersome for the developer to specify.
Once you see which alerts are flagged (if any), modify the privacy rules to fix those alerts.
If you determine that an alert doesn't matter or isn't a serious issue, dismiss it and add a note explaining why. Notes will be accessible the next time the tool is run, as long as the same issue is still flagged.
In case you'd like to save the results for later, you can export a report which contains some abridged information about your app's privacy rule setup. This report includes the privacy rules for each data type as well as any flagged alerts. Because the tool doesn't work on the data field level, the status of each individual data field's check boxes are not included in this report.