I often come across people with Bubble applications that they don't realise have effectively public databases, ie all their data is accessible by anyone on the internet. It's quite terrifying.
Often Privacy Rules just weren't the first priority when first getting your app built but that priority changes as soon as you have a real customer.
Sometimes people buy a template expecting it to be fit for purpose but has no Privacy Rules, sometimes they've had an agency or Freelancer build their site and Privacy Rules just haven't been implemented. Sometimes Privacy Rules are implemented that are explicitly "This data is public" creating a delusion that the data is secure. Don't worry it is fixable.
Straight from the Bubble manual .....
If you haven't explicitly created privacy rules for a given thing, then the data is not secure.
https://manual.bubble.io/help-guides/working-with-data/protecting-data
It can (and must) be fixed if you are going to store private data.
This is how I work together with Clients to implement Privacy Rules to an existing app. It could be Brokers, Patients, Customers, Dentists, Applicants, Subscribers - it doesn't matter who the private data belongs to or the domain of the application the same process applies.
1. Categorise every table with a prefix so that they sort into groups that make sense. For example everything to do with Brokers, contain Brokers data - prefix with B. Another example - everything to do with Data Loading - not directly accessed by Brokers - prefix with D. Anything to do with system setup and config prefix with S. It doesn't need to be too scientific - it is just an aid to help us make sense of all the tables. Any table you don't understand - prefix with X - so we can sort these out later. Any table you know is an unused table - prefix with Z - so all the least useful relevant tables are at the bottom of the list. As a separate task we will search and confirm the tables are or aren't being used and delete or categorise however makes sense. I'd expect 5-8 groupings.
2. Figure out what roles are there. Admin is one. Brokers is another. Patients is another. Admin can see all data. Brokers can only see their own data. Are there any other roles? Roles generally have names
3. Figure out which tables are public and which aren't. There may be some public data. There may not be some public data. It just depends. A list of states for example is probably public. Anything with personal information is almost certainly private - unless there is a specific requirement for it to be public eg a public directory listing of Brokers in a region available on the internet.
4. Check there is no personal information in Option sets. Make a list of any option set that contains personal information. As a separate task these will need to be converted to tables that can be protected by Privacy Rules.
5. Decide which roles see which data - going table by table (cut and paste a list into a spreadsheet so we check each one methodically) . Typically it will be
- Broker sees own brokers data and can autobind certain data
- Admin sees everything and can autobind certain data (probably not brokers data)
- Not logged in and everybody sees nothing. This we will make the default behaviour of the App after we have fixed the Privacy Rules.
6. Figure out if there are any schema changes required to make the Privacy Rules work. We may need to put a "broker id" of some tables to make the Privacy Rules work. Probably not if the app is working without Privacy Rules.
7. Categorise the tables into high and low risk depending on the data they contain. Highest risk tables might be User, Security Question & Answers, anything money related. We will look at the high risk first. We want to uncover any necessary database schema changes as early as possible.
8. Consider for each table if different roles see different fields. Using the search capability in the Bubble Editor we will check which fields are being used where. And cross check that with our understanding of how the app works. If fields aren't being used we will name them as marked for deletion or just delete them. Same with tables.
9. Now implement the Privacy Rules for each table in the Bubble editor.
And just for good measure .....
If you haven't explicitly created privacy rules for a given thing, then the data is not secure.
