Bubble Security Checkout points

Security is often seen as a dull topic in the tech world. Everyone wants to read about it, but very few actually do anything about it. Why? Because most content about security is not engaging and uses complex language that many don't understand. However, since security is closely linked to financial loss, it naturally interests everyone.

I wrote this article to encourage action, not just reading.

I experienced this firsthand when I launched an application on Bubble. Everything seemed fine until I received an email listing all users and their emails. I wondered how this happened, suspecting a former contractor, but it turned out the person had no connection to the app. They had simply found a way to access it and retrieve a lot of private information.

This was my first encounter with security issues on Bubble, and I've worked to ensure it's the last. Many new Bubble users might face similar problems, especially those who prefer learning by doing rather than following structured courses (though thanks to course creators like Buildcamp and Matt Neary for their organized content).

I used to believe Bubble handled all aspects of security, but I was mistaken.

We can break Bubble app’s security in two parts:

1. Your Bubble App Security.

2. Security at the Bubble platform level.

Bubble platform security involves database protection, data transfer between client and server, and Bubble's connection with AWS. We have little to no control over this aspect, so we won't delve into it. You can learn more about it here.

Our focus will be on making your application more secure. I'll try to keep everything straightforward and engaging.

Let's get started without further delay.

1. Privacy rules-

This is the heart of the your app security.

Privacy rules determine who can access your app database's data. By-default, your data is public.

So write the correct privacy rules for all the data types in your app. If you want to understand what’s exactly is the privacy rules and how it works, Checkout this video.

Here are some examples of the privacy rules -

• Below privacy rules allow only the creator of the "Audio" data type to access their own data when they are logged in. No other person can access your data.

  

  
  

• The privacy rules below permit only users of the "admin" type to access the data; no one else can access it.

  

• The privacy rules below permit only your team members to access the data. no one else can access it.

  

Ensure to write proper privacy rules for your app that restrict data access, allowing only authorized users to view the data.

2. Check What data is exposed-

The first step in addressing data security is identifying what data is leaking. Only then can you take the appropriate steps to fix it.

Navigate to your application in preview mode. Right-click and select "Inspect". Then, go to the Console and type:

Console.log(app)

Here I have breakdown what’s all the info it exposed - that we will go through one by one.

1. Current Page Element - It will list all the elements like Text, Group etc used on the page along with the default values you pass. So don’t forget to remove the sensitive info if you are passing.

2. Page list - It will display a list of all the pages, including their names and the elements used on each page.

   Don't forget to remove any test pages and secret key/value pairs that were added during the app testing process.

3. Option Sets: Option sets are public by nature. Therefore, do not store any private information such as the Stripe plan ID, secret keys, or any information related to business logic there.

4. API Connector (Settings) : This keys exposed the following info -

   1. API Connector - The setup of your API connector plugin, along with the URL and default values, are publicly available unless marked private.

   2. Plugins - This information also includes a list of all the plugins you're using. Double-check to ensure none of them expose your secret keys.

   3. Google Maps keys- If you've set up a Google Maps key in the settings section of Bubble, it's publicly available. Bind it to your domain from the Google Cloud console.

   4. Ziggeo Keys- If you're using the Bubble Ziggeo plugin to record and upload videos, your API keys are publicly available. Avoid using this plugin.

5. All the Data types- All data types, along with the column names and their types, are publicly available. The default value of each column name is also exposed publicly. Do not store any private information there.

3. Secure your API

As mentioned above "API Setup," in the API Connector plugin information is publicly available. It includes the API URL, parameters, and their default values.

Let’s learn how to secure them:

1. Hide your API URL:

Instead of putting url like -

Convert your URL into a private parameter

2. Secure your parameter values: Don’t forget to make them private or remove it after you successfully initialised the API.

4. Secure your Backend Workflows:

Visit the following url and see if you have any public backend workflow that is exposed:

https://<your_app_id>.bubbleapps.io/version-test/api/1.1/meta

If there is any backend workflow that is exposed , uncheck the “expose as a public API Workflow”.

If it necessary to make the API workflow public, incase of Stripe webhooks or any other reason, don’t forget to setup the correct validation of incoming request. Matt have go-indepth on how to secure your webhooks (AKA API workflow) . watch here.

If you check the "This workflow can be run without authentication" option, any user can call this API workflow, even if they are not logged into your app. Be mindful of this as you proceed.

5. Secure the page access/content:

If you have pages intended for a specific type of user, for example, admin pages accessible only to users with the "admin" role, it's essential to secure these pages.

Implement server-side conditions for this purpose rather than client-side conditions. Always apply these conditions when the "page is loaded" event occurs.

Don't use client side conditions (like checking custom state etc) . If you do, your page's content will first be downloaded and then the condition will be checked. This approach undermines the security of the page, allowing anyone to access the page data.

6. Protect your Test version:

By default, anyone can access the test version of your app by adding “version-test” to the URL. To make it password-protected, go to Settings, then General, and look for the relevant section to check.

Conclusion:

In conclusion, this article is the first step in securing your Bubble app and its data. Remember, security in Bubble is an ongoing process. It's important to revisit this guide after every major app update to ensure your app's security is current. Paying attention to how Bubble actions work will further improve your app's security.

FAQ

Q: Is bubble secure enough for an educational setting?

A: Yes, Bubble is secure to build the education apps. If you follow the correct path of app building, then your app is secure.

Q: Is there any Bubble security checker available?

A: Yes, you can browse https://check.tinkso.com/ and to test the privacy rules - https://www.flusk.eu/ressources/free-ai-privacy-rules-checker-for-bubble-io

Q: Is Bubble is secure?

A: Yes, 100%. Read about it more here - https://bubble.io/security

Q: Where is Bubble hosted and is it secure?

A: Bubble is hosted on AWS, and you can read about it here - https://bubble.io/security