La data security is a fundamental pillar for any application, whether it is coded in a conventional manner, or in No code.
In The Bubble.io ecosystem, the Privacy Rules (or confidentiality rules) are the main mechanism for protect your data and ensure that only authorized users have access to the data in question.
These Privacy Rules Define who can create, read, modify, or delete data in your application. Without these rules, your application would be vulnerable to unauthorised access, which may lead to sensitive data leaks or malicious manipulations.
On this subject, we recommend that you follow our Tips & Tuto on security:
→ How to secure a Bubble.io App in 5 minutes
💡 Key concept : Privacy Rules work as an additional layer of protection between your data and your users, allowing precise control of permissions.
In the world of no-code, the ease of development can sometimes make you forget the security fundamentals computer science. However, like a classic application, applications created with Bubble also handle sensitive data :
The consequences of a Poor implementation of Privacy Rules can be disastrous :
🔥 Word from the expert:”Always develop keeping in mind the security of your Apps. If you don't protect your data with Privacy Rules, you're not protecting it at all. Each record in your application database that is not public should be designed appropriately.” by Peter Amlie, in his performance guide.
Bubble uses a system of rules in four axes to control access to data. Each type of data in your application can have its own rules that determine:
1. Create - Who can create new entries
→ Example: Only logged in users can create posts
2. Read - Who can read or visualize existing data
→ Example: A private message can only be seen by the sender and the receiver
3. Update - Who can modify Existing entries
→ Example: A user can only change their own profile information
4. Delete - Who can suppressing Entrances
→ Example: Only administrators can delete comments
💡 Note: Privacy Rules are not just a user interface restriction - they are applied at the database level and are your main security mechanism.
Bubble allows to apply security at two distinct levels :
1. Data type security : Control access to an entire record.
2. Field-level security : Allows for finer control by defining who can see or edit specific fields within a record.
✅ Recommended practice : Use field level security for sensitive information like passwords or payment details, even if the record itself is accessible.
When you create a new data type in Bubble, it is not protected by no rules (publicly visible). The only type of data that includes Privacy Rules is the “User” type, which is the basic type in all applications.
⚠️ lookout : It is your duty as a developer to review each data type and apply security where needed.
The rule”This user“is one of the most commonly used in Bubble. It refers to The owner user of the recording.
For example, let's take a configuration for a type”Commentary“under a blog post:
💡 Practical tip : For “This user” to work properly, you need to have a field in your data type that establishes the relationship with the user. For example, in your “Comment” Type you need to create an “Author” satellite field of type User.
For more complex applications, you will often need to set permissions based on different roles.
Example for a project management application :
To implement these roles, you can:
Contrary to some preconceived ideas, Privacy Rules don't have a significant impact on performance of your Bubble application. In reality, they function as an additional filter applied at the server level before data is transmitted to the browser.
Privacy Rules are integrated in an optimized way by Bubble into database queries. So they can theoretically improve performance of your applications because they limit the number of data returned to the page by the server, which can improve load times.
You can measure the data returned on the page and the charging time in the” tabConsole“from your browser (Ctrl + Shift + J).
💡 Key concept : Privacy Rules are not a client-side filtering mechanism that would run after the data is loaded - they are applied on the server side before the data even leaves the database.
Since Privacy Rules do not negatively impact performance, priority should be placed on designing a data architecture that facilitates a robust security for your applications.
Hierarchy of priorities:
If you don't protect your data with Privacy Rules right from the start, you will make inconsistent choices in the database design later. Safety takes precedence over performance in that case.
Key considerations when designing your database with security in mind:
Different use cases require different approaches in terms of security:
Single-user application (e.g. personal CRM)
Multi-user platforms (e.g. social networks)
Business applications (e.g. project management)
To ensure that your security policies work as intended, take a methodical approach :
If your App is complex, here's what you can do:
For effectively test your rules, create test accounts representing different types of users:
💡 tip : Create a test matrix where each row represents a user type and each column represents an action (create/read/edit/delete) on a specific data type. Execute all scenarios consistently.
At the end of 2024, Bubble had the brilliant idea of acquiring Flusk. A French startup specialized in... the security of Bubble applications!
The Full security check via the Flusk platform is now directly integrated into Bubble in the” tabPrivacy“.
Without going into more details, we will be doing a dedicated article on the subject in the coming weeks.
Here are the most common mistakes :
Of Misconfigured Privacy Rules may have serious consequences :
One Crucial point To understand about the Privacy Rules is that they do not really hide the records themselves, but apply an additional filter to a search... If you protect a record from being found in a search, that record will always be visible if it is part of a list saved on another record.
💡 Practical tip : Create a summary table of all your Privacy Rules to get an overview of your security system. This will help you identify potential inconsistencies and make it easier for new developers to be onboarded.
Ce specific case Is a real use case of an application (TransApp) that we developed for a customer in the road transport sector.
The context:
Drivers should send daily reports on the use they make of vehicles. The company counts 3 types of users. The Administrator, the operations team and the drivers. Each of these types has specific access, but there are subtleties.
→ In the event that a sinister is reported in a report for example, the driver who consults should be able to see The condition of the vehicle and photos of the disaster, but he doesn't have to Know the identity of the driver who caused the accident.
Database Structure & Privacy rules :
The Privacy Rules in Bubble.io constitute the cornerstone of your application security. Well implemented, they offer robust data protection without compromising user experience or performance.
Key points to remember:
Safety is never”Ended“. As your application evolves, so should your Privacy Rules.
Plan some regular audits of your security system to identify and fix potential vulnerabilities.
💙 The final word : When you master Privacy Rules, you're not only protecting your data - you're also building the trust of your users, which is critical to the success of any application.
