The Bubble Security

Cheat Sheet

Making Bubble apps secure.

Bubble Security Cheat-Sheet

1 Flusk 2023
Summary
1. Introduction

2. Basics

1. Minimum password requirements

2. SSL Encryption

3. Optimize the application

4. Popups

5. Page access protection

6. Bubble editor’s privacy

7. Keep track of collaborators

8. Protect your test version

1. Test pages

2. Test data

3. The Stripe case

3. Public app details

1. Pages

1. Naming doesn’t matter

2. Understanding redirections

3. How to set up clean server redirections

4. Hiding content by default

2. Databases

3. Options Sets

4. Plugins

1. All plugins are public

2. The Google Map API Key

5. Front-end workflows

Bubble Security Cheat-Sheet

2 Flusk 2023
 1. Static values

2. App logic can be guessed

3. Resetting passwords

1. Assign a temp password to the user

2. The 2FA case

3. The solution to these issues

6. Back-end workflows

1. API Workflow exposition

2. Authentication in API Workflows

3. The Swagger file

4. Securing webhooks and API endpoints

1. Sending an API Token via headers

2. Sending an API Token via URL parameters

7. APIs

1. URLs

2. Headers

3. Parameters

4. JSON Body

5. Call response

8. Brute-forcing URL parameters

4. Privacy rules

5. Fetching incoming requests

6. The Data API

1. Privacy rules and Data API

2. The death combo

7. Create a professional push-to-production process

Bubble Security Cheat-Sheet

3 Flusk 2023
 Bubble Security Cheat-Sheet

4 Flusk 2023
1. Introduction
Welcome to the world of no-code development with Bubble. During your
journey to build powerful and innovative applications using this powerful
platform, it's important to keep security in mind. In this book, we will explore
the various security considerations and best practices that you should keep in
mind as you are building your Bubble applications.

From understanding how to secure your user's data and protect your
application from malicious attacks to ensuring that your application is
compliant with relevant laws and regulations, this book will provide you with
the knowledge and tools you need to build secure Bubble applications.

Throughout this book, we will also dive into real-world case studies and
examples to help illustrate the concepts and techniques discussed. So
whether you are a beginner or an experienced Bubble.io developer, this book
is a valuable resource for anyone looking to build secure and reliable
applications on this exciting platform.

As the use of no-code platforms and tools continues to grow, it is important for
individuals and organizations to be aware of the potential risks and challenges
that can arise when working with these technologies. One such risk is the
potential for data breaches, which can have serious consequences for both the
security of user data and the reputation of the individuals or organizations
involved, as well as legal consequences.

In 2022 at Flusk, we conducted a study of the top 100 Bubble.io apps sorted
by traffic to understand the current state of security practices on the platform.
Our findings were dismaying: we discovered that a staggering 80% of these
apps had experienced significant security weaknesses. This highlights the
importance of taking proactive measures to ensure the security and integrity of
no-code solutions built on Bubble.io and other platforms.
You can find the study by clicking here.

Bubble Security Cheat-Sheet

5 Flusk 2023
My name is Wesley Wasielewski, I am the co-founder at Flusk and I have 4+
years of Bubble experience.
At Flusk, we offer our expertise to companies that use Bubble as the core
development platform for their business, and to no-code agencies aiming to
develop secure applications.
What we mostly want is for the Bubble ecosystem to be unaffected by the lack
of security practices of developers and for people to see Bubble as a tool that
gives never-before-seen possibilities to today's innovative companies.
Our main mission is to bring all our expertise to the security aspect of
business application development.

But today, I’ll share with you the best security practices we use at Flusk to
ensure the data you are storing are safe, and more generally that the
applications you are developing are secure.

Bubble did not participate in the elaboration of this book, but reread it to
confirm that the facts elucidated in it were real and applied perfectly to the
tool.

Bubble Security Cheat-Sheet

6 Flusk 2023
2. Basics
2.1. Minimum password requirements
Minimum password requirements help to protect web applications by ensuring
that users create strong and unique passwords that are resistant to brute-force
attacks and guessing. This can help to prevent user accounts from being
compromised and protect sensitive data.

Just do it.

You can easily set minimum password requirements by going to “Settings >
General” (cf. screenshot).
I recommend putting at least 8 characters and requiring at least a number, a
capital letter, and a non-alphanumeric character.

2.2. SSL Encryption

SSL (Secure Sockets Layer) encryption is a technology used to secure the
transmission of sensitive information between a web server and a client (such
as a web browser). It uses a combination of public and private keys to encrypt
and decrypt data, ensuring that it cannot be intercepted or read by third
parties. SSL encryption is an essential security measure for any web
application that handles sensitive information.

Bubble Security Cheat-Sheet

7 Flusk 2023
It doesn’t make sense for you to deeply understand how it works, but SSL
encryption should always be enabled. Let this checkbox unchecked only
when you are absolutely aware of what you're doing.

It’s also really easy to set up: that’s just a checkbox to check.

You can find it by going to the settings, and then to « Domain/email » :

This feature is only available if you have a custom domain configured (and
therefore, you are at least on the personal plan).

2.3. Optimize the application

As changes are made to your Bubble app over time, it may store information
about parts of the app that are no longer relevant, such as deleted styles or
data types.

To help improve the overall performance of your app, you can use the
"Optimize Application" tool in the General tab to remove some of this unused
content. However, it is important to note that using this tool may prevent you
from performing certain actions, such as restoring a deleted data type, if you
have cleared its history.

Bubble Security Cheat-Sheet

8 Flusk 2023
To access the "Optimize Application" button, go to « Settings > General ».

2.4. Popups
During application audits, we often see the use of pop-ups to block access to
pages or elements.

It is essential to recognize that obscuring or hiding elements does not provide

security.

Let’s see why it is not a secure way for protecting your pages and how to pass
through.

1. Open the Chrome DevTools (by right-clicking on the popup and clicking
« Inspect » or by pressing CTRL+SHIFT+C on Windows, or CMD+SHIFT+C
on Mac)

Bubble Security Cheat-Sheet

9 Flusk 2023
2. Look at the screenshot: select the pop-up in the list of HTML elements (it
should be highlighted when hovering it)

3. Add the following CSS attribute to the pop-up: « display: none »

Now, you have access to the entire page by having completely gotten rid of
the popup.

Bubble Security Cheat-Sheet

10 Flusk 2023
It is important to remember that pop-ups are not a reliable or secure way to
protect content or pages. Proper security measures require a comprehensive
understanding of potential vulnerabilities and the implementation of effective
strategies to mitigate those risks.

2.5. Page access protection

To hide content or groups to a certain user based on a condition, the best way
to do (and that is used most of the time by Bubble developers) is the following:

1. Hide the content by default by unchecking this box

2. When a certain condition is matched, show the element:

By doing this, the elements inside the group (works also for repeating groups)
won’t even be downloaded if the condition is not matched. It also means that

Bubble Security Cheat-Sheet

11 Flusk 2023
the content inside invisible groups will not be called when the page is loaded.
And there is (as far as we know) no way to brute-force this security.

However, this will not make it impossible for potential hackers to retrieve this
data. It will only make it harder. Keep in mind that your security strategy
should be focused on privacy rules and proper page redirections, which we
will discuss later in this book.

Tip: group all the content of your page in a container group, and put the
condition on this top-level group. You won’t have to repeat it on all your
different containers.

2.6. Bubble editor’s privacy

This may seem like an obvious point, but it is something that we still see from
time to time: the application rights must be set to private.

If the rights are set to « Everyone can view » or « Everyone can edit », it means
that anyone can access your database, run the app as an administrator, view
all of your API and private keys, and access everything else in the Bubble
editor.

We have encountered professional Bubble applications with over 20,000 users

that had their editor fully open during an audit. It is important to be vigilant
about this issue as it is easy to overlook but can have significant
consequences. Fortunately, it is also easy to fix.

Make sure to set your application rights to private to protect your sensitive
information and your business logic.
This prevents any unauthorized user from accessing your Bubble editor.

You can take a look at this screenshot below to see where you can change this
option.

Bubble Security Cheat-Sheet

12 Flusk 2023
2.7. Keep track of collaborators
It is also important to keep track of who has access to your application.

Think of it like the keys to your house – you want to know who has a copy.
In cybersecurity, it is often said that the biggest weakness of a company is its
humans. If one of the individuals with access to your app has their account
hacked, your application could be compromised.

It is essential to carefully monitor who has access to your app and to keep the
list of individuals as short as possible. This helps to reduce the risk of
unauthorized access and potential compromise.

Bubble gives you the ability to define permissions for each collaborator of your
app. Give them access only to what they need.

Checking the « Admin » box will give them full permission over your app. They
will be able to view and edit the app, the data, and the logs for all versions.

The « App » section defines the permissions for making changes to your app.
You can allow them to only view, or to view and edit.

Bubble Security Cheat-Sheet

13 Flusk 2023
The « Data » section covers everything about data querying and editing. You
can allow a collaborator to view the data, to view and « Run as » (log in as a
specific user), to view and edit (including « Run as ») or to not even be able to
view.

The « Logs » section can be more sensitive than you think. Every action writes
a record in the logs with the associated information to it. For example, when
an API call is performed, all the parameters are written in the logs. Same for
writing in the database.

A useful thing for your developers can be to only allow them to work on the
test version by checking the box called « Only dev. version ».

Don’t give them more than what they need.

2.8. Protect your test version

By default, the test version is secured with a combination of a username and
password (HTTP Basic Authentication).

However, it is possible to manually disable this security measure, and we have

occasionally encountered apps where the test version is accessible to anyone.
This can lead to several critical issues that we will explore below.

Bubble Security Cheat-Sheet

14 Flusk 2023
It is important to remember to change the default username and password
combination to something that cannot be easily guessed, to further secure the
test version of your app.

A great combo should be something completely random, such as :

Username: myapp687689%%*
Password: sj@Ty9rmcLSmP#a3

2.8.1. Test pages

This is a major mistake that many Bubble developers make and is the source
of numerous vulnerabilities.

Please ensure that you delete any test pages from your Bubble app. During our
audits, we found a large number of applications that contain pages with names
like "test_dev," "admin_test," and so on.
These pages often have buttons that allow sensitive actions such as
"Download database as CSV," "Format database," and "Delete all companies."
Other pages may display lists of users or other sensitive information.

These pages have no place in a production app and should be removed, or at

least be secured. We’ll dig into page security a little bit later in this book.

2.8.2. Test data

The test version of your app may also contain sensitive information in the
database that should never be exposed to the public.

This can include data such as company, provider, and supplier information that
sometimes needs to remain private.

It is important to be mindful of the type of data that is stored in the test version
and ensure that it is properly secured to prevent unauthorized access.

Bubble Security Cheat-Sheet

15 Flusk 2023
Data in the test version should just serve tests so it should not be sensible.
Only the production version should be.

2.8.3. The Stripe case

As I told you before, leaving the development version open can lead to a big
issue, especially for SaaS businesses. When setting up Stripe on the
development version, you have access to a test credit card with the following
attributes in order to test your payments workflows:

• Number: 4242 4242 4242 4242

• Expiration date: XX/XX

• CVV: XXX

If you are developing a SaaS app and do not need the live database to be
functional to use your service, users may be able to use your app on the paid
plan and make payments with the test credit card when accessing the app
through the development version.

You should also try this test card in the live version to make sure it doesn’t
work.

This is a common flaw that can be easily avoided by properly securing the
development version and ensuring that it is not accessible to unauthorized
users.

Bubble Security Cheat-Sheet

16 Flusk 2023
 Bubble Security Cheat-Sheet

17 Flusk 2023
3. Public app details
In Bubble, many aspects of an app are public, including the app ID (the name
you define when you create your app). There is no need to create complex app
IDs, such as « my-app-768568 » because they can easily be accessed. To view
the app ID and other information, you can follow these steps:

1. Go to the preview of your app

2. Right-click on the page and select « Inspect element » to open the Chrome
DevTools

3. Go to the console

4. Type "console.log(app)" and press enter

You will then see a JSON object containing a lot of information about your app.
It is important to be aware of the level of visibility of different elements of your
app and to take appropriate measures to protect sensitive information.

You can see the app ID here in the red rectangle.

Most of the stuff we are going to explore in the below sections comes from
this JavaScript Object.

Bubble Security Cheat-Sheet

18 Flusk 2023
We're going to talk about it several times in the rest of this book, so don't
forget what I'm referring to when I say “the JSON App Object”.

This object can be retrieved from third-party actors, and trying to hide it from
the console is useless and not recommended.

3.1 Pages
Naming doesn’t matter
I see sometimes people naming their admin dashboards with names like
« admin-dashboard-658697 » because they think no one is going to be able to
find it.

It is not an appropriate fix because your pages - and their names - are
completely accessible to anyone who knows the existence of this Javascript
object.
And it has nothing to do with the sitemap file.

If you go back to our app JSON object and open the property called « %p3 »,
you will see the list of all pages in the app.

A major issue that we frequently encounter during application audits is called

« bad redirections ».

To illustrate this issue, consider the following scenario: you have a page called
« admin » that is restricted to users with admin access because it contains

Bubble Security Cheat-Sheet

19 Flusk 2023
sensitive data such as private pictures of users, and allows admins to take
certain actions.

In this case, you might want to check if the current user has the admin role
and, if they do not, redirect them to the homepage. While this may seem like a
logical approach, it is important to understand that redirections can be
problematic.

It is essential to have a thorough understanding of how redirections work to

avoid this type of issue.

Understanding redirections
When you try to load a page, you are making an HTTP request to the Bubble
servers to retrieve the content of the page. The response from the server can
be one of five different types:

1. Informational (100 to 199)

2. Successful (200 to 299)

3. Redirect (300 to 399)

4. Client error (400 to 499)

5. Server error (500 to 599)

As you can see, there are multiple possibilities for redirection codes within the
3rd category. The most important thing to understand about redirection is that
if you receive a 3xx response from the server, no content will be downloaded
and you will be immediately redirected to the next page.

This is known as a « server-side redirect ».

Bubble Security Cheat-Sheet

20 Flusk 2023
In contrast to a server-side redirect, a « client-side redirect » is a manual
redirection that is initiated by a JavaScript instruction. It is important to note
that JavaScript needs to be downloaded before it can be executed. This is
how a client-side redirect works:

The admin page is downloaded, and then some JavaScript is executed to tell
the browser to go to another page. However, by this time, all of the data has
already been downloaded, making it too late to prevent unauthorized access.

It is important to be aware of the limitations of client-side redirects and to use

appropriate security measures to protect sensitive information.

How to set up clean server redirections

To set up server-side redirections, you need to use the « Go to page » action
without relying on any client-side conditions or events.

Bubble Security Cheat-Sheet

21 Flusk 2023
Your event should only contain one workflow: the « Go to page » action.

A client-side condition is a condition that relies on something on the page. In

order to verify that condition, the page will have to be fully loaded in order to
determine if the user should be redirected.

For example, you could set up a redirection using the « User is logged out » to
see what happens. Let’s see what we get:

To verify that you are correctly using a server-side redirect, you can use a
redirect checker such as https://tools.sureoak.com/seo-tools/301-redirect-
checker, which was recommended by Petter Amlie.

This will allow you to determine whether you are receiving a 3xx or 2xx
response from the server :

Bubble Security Cheat-Sheet

22 Flusk 2023
We indeed have a 302 redirect on the page « redirect », then we’re redirected
to the page « index » which is fetched with a 200 code.

All good!

Let’s try another method and use a client-side condition. We will use the « Do
when a condition is true » event (that gets executed once the page is loaded),

Bubble Security Cheat-Sheet

23 Flusk 2023
and check if the Current User is an admin or not:

Let’s check the response code :

We got a 200 code. This indicates that the page has been completely
downloaded and that no server-side redirect has been applied. This is because
we did not use the « When page is loaded » event or the « User is logged in/
out » event.

Bubble Security Cheat-Sheet

24 Flusk 2023
Let’s try the same condition, but with the event « When page is loaded »
instead of « Do when a condition is true » :

Let’s check the redirections status:

That’s perfect! We get a 302 redirection on the « redirect » page as you can
see on the screenshot.

Let’s resume client-side and server-side redirections for main events:

Bubble Security Cheat-Sheet

25 Flusk 2023
 Type Is safe?

Do when a condition is true Client-side No

Current User is logged in Server-side Yes

Current User is logged out Server-side Yes

Page is loaded Server-side Yes

Caution: if you add a client-side condition on a server-side redirection, the

page will wait for the client-side condition to be checked and then apply the
redirection. Your safe redirection will not be safe anymore.

3.2 Databases
In the JSON object I showed you previously, the entire database structure is
also accessible.

Here’s how to find it :

Just dig into the « user_types » property. You’ll be able to find:

• Data Type names

• Field names

• Field default values

• Field types

Bubble Security Cheat-Sheet

26 Flusk 2023
So please be especially careful about this and don’t store anything sensitive
inside the default values as it is publicly available.

3.3 Option Sets

It is important to note that every Option Set defined in the editor is
downloaded each time a page is loaded, making them publicly accessible.
There is no way to make Option Sets private, so it is crucial not to store any
sensitive information within them.

Here’s where you can find them:

You’ll be able to find:

• Options Sets names

• Attributes names

Bubble Security Cheat-Sheet

27 Flusk 2023
• Attributes types

• Options

• Options values

3.4 Plugins
All plugins are public
Plugins as well are completely public.

The API keys you define in some of them are not, but anyone can know what
plugin you are using.

In the JSON Object, you can find it by following this path:

« app[settings][client_safe][plugins] »

In this JavaScript object, you can see two attributes:

« 1479799259038x462847569184161800 » and « apiconnector2 ».

Bubble Security Cheat-Sheet

28 Flusk 2023
The « apiconnector2 » attribute is associated with the API Connector plugin by
Bubble, but the other attribute, with the value "1.0.3," is not immediately
recognizable.
This long string of random characters is the unique ID of the plugin in Bubble.
This means that you can find the plugin page (if it is a public plugin) by typing
the following URL into your browser: https://bubble.io/plugin/
1479799259038x462847569184161800.

And here is where we land :

So yes, every Bubble plugin you install is public. And it can be a point of entry
for potential hackers if a plugin you installed (or the library it is using) has a
known vulnerability.

The Google Map API Key

This small mistake will not cause you data leaks, but it might cause extra
billing costs.

In the JSON Object, the Google Map API Key is public. It means everyone can
see it, and it should not be a problem as long as you have restricted the use of

Bubble Security Cheat-Sheet

29 Flusk 2023
this key to your application domain.

If your key is not restricted to solely being usable from your application
domain, it means everyone could make Google Map API Calls from everywhere
else than your application.

In order to protect it, you have to go to your Google Cloud Console dashboard,
access the API Credentials section, and select the Google Map API: https://
console.cloud.google.com/apis/credentials

Bubble Security Cheat-Sheet

30 Flusk 2023
1. Application restrictions: select « HTTP referrers »

2. Add your website URL in the « Website restrictions » section

You might want to add these 4 URLs:

1. Your production Bubble URL (https://appname.bubbleapps.io/*)

2. Your test-version Bubble URL (https://appname.bubbleapps.io/version-

test/*)

3. Your production domain URL (https://yourdomain.com/*)

4. Your test-version domain URL (https://yourdomain.com/version-test/*)

3.5 Front-end workflows

Front-end workflows and values specified within them are publicly available to
all users upon page load.

Static values
Let’s make it simple: every character you enter while being in the Bubble
Editor and editing a page is public.

Bubble Security Cheat-Sheet

31 Flusk 2023
Let’s take the example of the « Log the User in » workflow :

I filled the fields with static values (things that you should normally never do,
but we still find it sometimes when auditing professional and money-making
applications).

Let’s see how I can retrieve it from the front-end page :

Bubble Security Cheat-Sheet

32 Flusk 2023
It behaves in the same way for

• Custom states

• Database actions (Create, make a change to a thing)

• Plugin actions

• And every front-end action

App logic can be guessed

Because every front-end workflow is public, it is relatively easy for someone
with some experience and determination to guess the logic of your app.

To mitigate this risk, it is a good idea to move as much as possible to the

backend side when possible. By doing so, you can keep sensitive information
and critical app logic more secure.

Resetting passwords
A lot depends on how you use it and the context behind the execution of the
action, but we’ll dig into it and see together what solution we have in order to
make them secure.

Assign a temp password to a user:

We could think this action is completely secured, - as actions with credentials

usually are in Bubble - but this one can compromise depending on the context
in which it is used.

For example, some admin dashboards (that can be compromised with bad
redirections) have buttons to define a temporary password for a specific user.

What you have to know is that you can retrieve the assigned temp password in
crystal-clear text in the « Result of Step X »

Bubble Security Cheat-Sheet

33 Flusk 2023
I created the following action by making sure I assign a temp password to a
user that is not myself:

And I could find the assigned password in the Network requests (we’ll dig into
this point in Chapter 6):

The 2FA case:

Two-factor authentication (2FA) is a security process that requires a user to

provide two different factors to verify their identity when logging in to their
account. One of these factors is typically a one-time code sent to the user's
phone via SMS, phone call, or email (excluding Google Authenticator and other

Bubble Security Cheat-Sheet

34 Flusk 2023
2FA apps like this, that are secure). 2FA adds an extra layer of security to the
login process and can be used as a backup option in case the user is unable
to use other authentication methods.

We see more and more apps setting up this process and it’s a good thing
because it improves the security of Bubble applications, but it has to be done
in a secure way.

Let’s inspect how most developers are doing this 2FA process and why it is a
bad idea to do it like this:

1. After the user types his password in, create a random string (the 2FA code)
and store it in the database.

Bubble Security Cheat-Sheet

35 Flusk 2023
2. Send this code to the user via email or phone

The problem with this method is that it is possible to fetch the code by staying
in the browser and without getting the code from our email inbox.

As the example before, we can get it via the response of the « mget » request
in the DevTools Network tab.

Bubble Security Cheat-Sheet

36 Flusk 2023
The solution to these issues:

The problem is that our actions are made client-side and that everyone with a
little knowledge of how the Web works can easily intercept exchanges
between the browser and the server while it is not encrypted.

An easy-to-implement solution that works for these 2 cases and for most of
your security issues related to actions is to perform them on the back-end side
instead of the front-end side.

It is recommended that the creation of the 2FA code, assigning temporary

passwords, and other potentially compromising actions be executed primarily
on the back-end to enhance security measures.

3.6 Backend workflows

Backend workflows (including API Workflows) are used to handle complex or
sensitive workflows and are run on Bubble servers.

You have to be careful not to publicly expose them without authentication.

Exposing API Workflows

In the settings of every backend workflow, you can make it publicly visible or
not (by default, it is visible). This means it can be triggered from outside your
application.

I heard many beginners saying that « I don't care to secure this URL: I didn't
share it with anybody. Why would I bother? You won't access a URL you don't
know it exists ».
We will see later in this book that they are completely public if you don’t
uncheck a checkbox that is checked by default.
So please take care, and don’t expose API Workflows that are not supposed to
be publicly visible.

Bubble Security Cheat-Sheet

37 Flusk 2023
As it is public by default, a lot of developers forget to disable it when not
necessary.
As soon as your backend workflow is internal and is never triggered from
outside your application, you have to uncheck this box:

Authentication in API Workflows

If a backend workflow is publicly exposed, you have to define whether the
caller needs authentication in order to run this workflow or not.

It seems obvious, but most of the time you will want to have authentication
required on your workflows to avoid them being triggered by entities that are
not supposed to (hackers most of the time).

Bubble Security Cheat-Sheet

38 Flusk 2023
So uncheck this box as often as possible, except if it is necessary for your
business logic.

The Swagger file

An OpenAPI specification, also known as a Swagger file, is a JSON document
that describes the capabilities of an API. It includes information about the
API's endpoints, the parameters that can be passed to each endpoint, and the
structure of the responses that the API returns.

It is most often used to communicate with other developers on how to use the
API. If your business doesn't need that, then you don't need a Swagger file.

And by default, Bubble exposes this Swagger specification publicly for all our
data and backend workflows.

You can find it at this URL: https://appname.bubbleapps.io/api/1.1/meta/

swagger.json

Bubble Security Cheat-Sheet

39 Flusk 2023
Here is what it looks like:

But it is not easy to extract valuable pieces of information from it with this
JSON layout.
A way to format this data is to go to this website: https://editor.swagger.io/
and paste the JSON file in the left part of the page.

Bubble Security Cheat-Sheet

40 Flusk 2023
Here’s what we get:

We can see an API Workflow called « case-close-case » that requires 3

parameters:

• Case, type: String (UUID of the Case object)

• By, type: String (UUID of the User)

• Message, type: String (the message), optional

We can even see it clearly if we scroll down the page:

Bubble Security Cheat-Sheet

41 Flusk 2023
And this is not a problem by itself.

You always have to remember that obfuscating is not secure. It is not because
you hide the access to your API documentation that someone will not be able
to reverse engineer it.
Keep it in mind: the heart of the matter is in the privacy rules.

But if you don’t have any use for this Swagger file, then it just makes sense to
hide it.

To hide it, it’s just a checkbox to uncheck under « Settings > API » :

Securing webhooks and API endpoints

A webhook is a way for one application to send information to another
application automatically. When a certain event happens in the first application
(like a new user signing up), it sends a message to the second application
through a URL (kind of like a phone number for the second application to
receive information at).

Bubble Security Cheat-Sheet

42 Flusk 2023
The second application can then do something with this information, like send
an email or a text message. Webhooks allow different applications to
communicate with each other and share information in real-time.

You should secure your webhooks as much as you can. As far as I know, only
a few Bubble developers do secure their webhooks. The best way to do this is
by creating an API Key per webhook provider.

This is quite easy to do:

1. Keep authentication enabled on your webhook by leaving this checkbox

unchecked.

2. This means you will have to provide an API Key when triggering this
endpoint in order to accept requests only from authenticated third-party
applications.

3. Create this API Key for this service provider. You can do this by going to
« Settings > API » and creating a new API Token.

Bubble Security Cheat-Sheet

43 Flusk 2023
Then, you will have to give this API Token to the third-party service (Sendgrid
in my case) so that he can authenticate with your Bubble app.

The next step is to pass the API Token to your Bubble endpoint (that you use
as a webhook). There are 2 possibilities :

1. You pass it via the header (more secure because the token is invisible)

2. You pass it via an URL parameter (less secure because the token is visible)

Most third-party services do not allow you to include headers when making
calls, so you often need to use URL parameters instead. It is less secure than
through the headers, but it’s still better than not securing them at all.

Sending an API Token via the Headers

To send an API Token via the headers, you have to add a new header to your
call in the third-party service’s dashboard with the following properties:

Key: Authorization

Value: Bearer %API_TOKEN%

Sending an API Token via URL parameters

Bubble Security Cheat-Sheet

44 Flusk 2023
To send an API Token via URL parameters, you will have to add to your
endpoint’s URL a new parameter called « api_token ». Let’s suppose your
webhook is called « my-webhook », your final URL will look something like
this:

https://appname.bubbleapps.io/api/1.1/wf/workflow_name?
api_token=%API_KEY%

3.7 APIs
All your API calls & settings are also downloaded in this JSON Object and you
have to particularly pay attention to those. They often contain API Keys or
credentials that give access to third-party services that can be sensitive,
depending on what you are using on your app.

URLs
By default, the endpoints that you call in your API calls are not private and can
be accessed by anyone who knows where to find them. While this may not be
a significant issue when using third-party services that require additional
authentication to access data, it can be a concern when calling an internal
Xano endpoint or a private server running on AWS Cloud or any other platform
that doesn’t have authentication.

In these cases, you may not want anyone to know the exact URL, as the server
may not be adequately secured for external access.

Your security efforts are usually measured by your least secure component.

To protect the URLs of your API calls, you can use a workaround that involves
treating the endpoint URL as a private parameter in the API call.
This will help to conceal the URL and keep it private.

Bubble Security Cheat-Sheet

45 Flusk 2023
Here is how it looks before using the workaround:

And this is how it looks now:

Our URL is now considered as a private parameter, and it won’t be possible to

see it from the front-end pages of our app.

Do not forget to check the « Private » box.

Headers
The headers of an API call are most of the time where you define sensitive
properties that you want to provide to the API such as credentials or private
keys.

You may also want to define other properties such as « Content-Type », but as
this is not sensitive we won’t take care of it here.

Note that you can define headers at 2 different places in Bubble’s UI :

1. In the « Shared headers » section

Bubble Security Cheat-Sheet

46 Flusk 2023
 Every header added in this section (that is shared between all calls below)
will be private by default. This is the safest place to add any authorization/
authentication/private key or anything sensitive because it will always be
private and it does not allow for human errors.

2. In the « Call headers » section

If we examine our previous API call and add an Authorization header, we have
the option to make it private or not. This is where human error can occur.

If we set up a Stripe API call and forget to check the "Private" box, the app's
security is compromised. No matter if the call is in the front-end or in the
back-end. With a valid Bearer access token, anyone can make payouts to their
own Stripe account, retrieve transactions, or access general information about
your company's financial status.

To avoid this potential mistake, it is recommended to add any header to the

shared headers section if possible, and if this is not possible, make sure to
check the « Private » box. This will ensure the highest level of security for your
app.

Parameters
It’s the same for parameters as for the headers.
Let’s see both ways for adding an URL parameter to an API call:

Bubble Security Cheat-Sheet

47 Flusk 2023
1. In the « Shared parameters » section

2. In the « Call parameter » section

And as you can see here we have the same problem we had for the headers:
the « Private » checkbox can be unchecked and make your API Key viewable
for everyone.

The conclusion will be the same as for the headers: fill in the parameters in the
« Shared parameters » section as much as possible. And when not possible,
make sure to check the « Private » box.

JSON Body
When making POST, PUT, PATCH, or DELETE API calls, you may need to
include sensitive information in the request payload, also known as the body,
in the form of a JSON object.
It could be your client’s information, email, financial data, or information about
your business you don’t want to be public.

Bubble Security Cheat-Sheet

48 Flusk 2023
To protect this sensitive information, you can use a workaround similar to the
one used for hiding the endpoint URL. Instead of including the sensitive
information in plain text within the JSON object, you can use a parameter (or
dynamic value) and define it using « <param_name> ».

This will allow you to hide sensitive information from potential hackers and
increase the security of your app. Remember to always be cautious when
including sensitive information in API calls and to use best practices to protect
it.

If you look at the screenshot, it’s exactly what I did for my « password » value.
And as usual, do not forget to check the « Private » box.

But sometimes, you need a dynamic value that comes from the front-end so
you can’t check this « Private » box. The good thing to do here is to initialize
the call with a value that is not sensitive so it’s not critical if some people can
see it.

Call response
When you make an API call using the API Connector plugin in Bubble, the
response received is saved in the call's properties - and so, in the JSON
Object.

Bubble Security Cheat-Sheet

49 Flusk 2023
In most cases, this response does not contain sensitive data, but it might,
depending on the API.

Here’s what an API call response looks like (from the Jokes API, which I took
as an example):

For our example, I added an « api-key » property that is normally not here to
illustrate the case where something sensitive could be sent by the API provider
in the response object.

To remove a sensitive value from an API Call response, we’ll have to click the
« Edit raw data » button when initializing the API Call.

Bubble Security Cheat-Sheet

50 Flusk 2023
Then, replace the sensitive value with something not sensitive and click
« Save » :

Another way to do this is to select « Ignore field » in the data type selection
dropdown. By doing this, the data will not be stored in the response object.

Bubble Security Cheat-Sheet

51 Flusk 2023
3.9. Brute-forcing URL parameters
URL parameters consist of a key and a value and are added to the end of a
URL preceded by a question mark (?). Multiple parameters can be added to
the same URL by separating them with an ampersand (&).

For example, consider the following URL:

https://www.example.com/search?q=keyword&sort=relevance&page=2

In this URL, the q parameter is used to pass a search query to the server, the
sort parameter is used to specify the sorting order of the search results, and
the page parameter is used to specify which page of the search results to
display.

URL parameters can be useful because they allow you to pass information to a
server without the need to store it in a server-side database or file, and they
can be easily changed or updated by the user. They are also easy to read and
understand and can be used to track user behavior and preferences.

In Bubble, they are often used to conditionally display or hide specific groups
depending on what the user wants to see. For example, let’s say we are on a
dashboard and we want to see the list of our customers. The URL might look
like this:

https://myapp.com/dashboard?tab=users_list

And most Bubble developers think that as they’re the only ones to know the
value of the URL parameter that will display the list of all their users, that’s
safe enough. And that’s false.

Remember the JSON object?

All the conditionals about all the elements that are on the page are public.
Let’s look at a quick example I built.

I am on my page called « dashboard », in which I have 3 groups (Users list,

user actions, and companies). They are all invisible by default and become
visible when a certain condition is met:

Bubble Security Cheat-Sheet

52 Flusk 2023
Most people think that no one will find this particularly secret and hard-to-
guess URL parameter, so they think they’re safe. But let’s dive into our JSON
object:

And look at what we’ve found. If we read the 3rd rectangle, then the 2nd, then
the 1st and then the 4th, here is what we can guess:

When GetParamFromUrl tab equals users_list => %iv=true

Bubble Security Cheat-Sheet

53 Flusk 2023
Where %iv means « is visible », so you can easily guess what will happen if
you add « ?tab=users_list » to the end of the URL.

Bubble Security Cheat-Sheet

54 Flusk 2023
4. Privacy rules
When you build a new app in Bubble, by default, all data that is collected and
generated within the app is open to the public.
However, in most cases, you may want to protect user data that is submitted
to your apps, such as names, emails, or private comments that are intended
only for certain individuals. To protect this sensitive information and ensure
that it is kept private, Bubble provides you with privacy rules.
These rules allow you to specify how data is collected, used, and shared
within your app, and ensure that it is kept secure.

If you have not explicitly set up privacy rules for a particular piece of data, it
may not be fully protected and could potentially be accessed by others.

Let’s make it simple: you have to master privacy rules to build a secure
application. One cannot go without the other.

You can find ideal tutorials on the web, such as:

• This official tutorial from Bubble: https://youtube.com/watch?v=1-

meIeBUXPY

• This tutorial by Gregory John: https://youtube.com/watch?v=jIIQ0wXTvXE

• More generally, the Bubble documentation: https://manual.bubble.io/help-

guides/working-with-data/protecting-data

The performance aspect of privacy rules

Setting up privacy rules has also a significant aspect of your app’s
performance. This part is a bit out of the scope of this book, but I think it’s
always useful to know.

Let’s suppose we want to do the following:

Bubble Security Cheat-Sheet

55 Flusk 2023
We are building a marketplace of services provided by persons.
This is what our « search » page looks like:

This is what our User Data Type looks like:

Bubble Security Cheat-Sheet

56 Flusk 2023
And these are our privacy rules for the User Data Type:

Let’s distinguish two cases for our Repeating Group of Users:

1. If you do not set up privacy rules for a specific piece of data in your app,
the entire user object, including all its fields, will be sent from the server to
the front-end when you query for it.
And then you are going to choose between all the fields which one you
want to show to the end-user.
Let’s say the name, and where he/she lives in our example.

2. When you set up effective privacy rules and query the Bubble server for a
specific user, the server will only send you the fields that the current user is
allowed to see. This means that only necessary data is downloaded, rather
than the entire object. In this case, the user will receive only the fields
« City », « First name », « Last name », « Profile picture », and « Role ».

Effective privacy rules help to improve the performance of your Bubble

application by only sending the necessary data to the user's browser.

Bubble Security Cheat-Sheet

57 Flusk 2023
This means that pages and repeating groups will load faster because there is
no need to download unnecessary data, such as phone numbers or emails in
our example.

By setting clear privacy rules, you can ensure that only the necessary data is
downloaded and protect sensitive information at the same time.

The privacy rules you apply here also apply to the Rest API endpoints.

Bubble Security Cheat-Sheet

58 Flusk 2023
5. Fetching Incoming Requests
Chrome DevTools is a set of web development tools built into the Google
Chrome browser. It allows developers to debug, inspect, and modify the
behavior of web pages and applications.

There are a lot of things we can do to improve performance and security using
the Chrome DevTools, but what I want to put focus on here is the « Network »
tab.

The Network tab in Chrome DevTools allows you to monitor network requests
made by the browser and the resources that are loaded as a result.

What we want to inspect in our case are the incoming and outgoing requests
that are made between the browser and Bubble’s server, especially database
requests.

Let’s open the Chrome DevTools by right-clicking on the page and clicking on
« Inspect » :

Bubble Security Cheat-Sheet

59 Flusk 2023
Then, let’s click on the « Network » tab (« Réseau » on my French computer):

Here, we are able to see all the outgoing requests going from our browser to
Bubble’s server, including Bubble’s response.

We want to understand how database requests work in Bubble and how to

interpret them.
There are 3 interesting types of requests that can be made by our browser to
Bubble’s server:

• « search »: Do a Search for (single entry)

• « msearch »: Do a Search for (multiple entries)

• « mget »: Get a specific database record

Other options are available, such as maggregate, however, their capability to

disclose sensitive data is limited. As such, our attention will not be directed
toward them in this context.

These 3 types of requests are API Calls that are made from your browser to
Bubble’s server. What can be problematic is the response from Bubble’s server
in case the privacy rules are not well defined.

Let’s go back to our previous example with the marketplace.

Remember, we only wanted to display our sellers' names and cities. Let’s see
where the request finds a place in our Network tab.

Here is our Repeating Group :

Bubble Security Cheat-Sheet

60 Flusk 2023
And let’s try to find the according requests in the Network tab:

Here it is.
Here is our first cell of the Repeating Group: Thomas Debon.
But hopefully, we defined perfectly our privacy rules so that Thomas's credit
card number is only visible to himself.

Bubble Security Cheat-Sheet

61 Flusk 2023
By the way, storing credit card numbers directly in Bubble is always a bad
idea. I just took this as an example, so that we can all agree that this is a
sensitive field.

But what if my privacy rules were badly set up?

Let’s try to remove them and inspect this request again.

Without the privacy rules enabled, we can see all of Thomas’ secure info. Most
Data Leaks are found in the Chrome DevTools Inspector section.

Something interesting is to look at the payload of the request. This is how

Bubble traduces the « Do a Search for Users » request to send it to the server:

It is encrypted, but it is not unbreakable. This is what we use at Flusk to make

sure your privacy rules are properly set up when running an automated audit
with Flusk Vault.

Bubble Security Cheat-Sheet

62 Flusk 2023
6. The Data API
The Data API allows users to access, modify, and delete data within an
application through a RESTful interface. It is disabled by default, but can be
enabled by checking a box in the Settings tab accessible under « Settings >
API ».
Privacy rules govern which data is accessible and what actions can be taken
with it. These rules apply in the context of the authentication method being
used. When modifying data through the API, there are specific permissions for
modifying, deleting, and creating data that must be granted through privacy
rules.

First of all, if you do not need the Data API, then disable it by unchecking this
box :

It will save you from dozens of headaches coming from this feature and this
little checkbox to check.

But hiding the Data API is only obfuscation. It will not protect your data, as
only privacy rules do.

Privacy rules and Data API

The second thing you have to know about the Data API is that privacy rules are
applied when using the Data API.

Remember what we said about privacy rules?

You grant different access to data depending on a condition.

Bubble Security Cheat-Sheet

63 Flusk 2023
The queries through the Data API work the same. The conditions are just on 2
layers now.

We have 3 cases to consider because you can call the Data API with 3
different Authorization types:

1. Using an API Token generated in Bubble accessible under « Settings >

API ». This is the full access key, and Bubble understands that you’re a full
admin when using this key. No privacy rules apply here, so you have to be
very careful.

2. Using your cookies as a logged-in user. This means just going with your
browser to the desired Data API endpoint (https://appname.bubbleapps.io/
api/1.1/obj/typename). And in this case, the same privacy rules you’ve
defined before apply. And that makes a lot of sense because you’re just
directly querying Bubble’s server (without getting through a Repeating
Group for example) but still as the user you are logged in as.

3. Using an OAuth 2.0 Token. The privacy rules will apply here, as same as if
the user related to this token would perform the call.

The death combo

The worst thing to do - and the easiest way for a hacker to penetrate your app
- is to have those 3 conditions at the same time:

1. Open Data API

2. Privacy rules set on the User

3. « Create via API » allowed for non-admin people

Bubble Security Cheat-Sheet

64 Flusk 2023
This is what could be your worst nightmare:

What does it exactly mean?

It means that everyone can create a user via the API by setting its role to
admin. Here is a quick example of a Postman call doing this on my test app:

And here is my brand new user with the admin role:

Bubble Security Cheat-Sheet

65 Flusk 2023
So this can be dangerous, especially when your roles and permissions are
defined in an Option Set (that is also public as you now know) that can be
easily integrated into a simple API Call with its Display name.

Bubble Security Cheat-Sheet

66 Flusk 2023
7. Create a professional push-to-
production process
As experts in cybersecurity, our team specializes in performing manual audits
on Bubble applications. However, in recent months, we have been working
diligently to develop a new tool that can automate these audits: Flusk Vault.
The goal of this project is to not only improve efficiency and reduce costs for
both agencies and makers but to also provide a valuable resource for the
industry. After dedicating over two months to research and development, we
are excited to announce that our automated audit tool for Bubble applications
is now available for use.

You can try it now from this link.

All the things you’ve learned in this book are automatically checked by our tool
on a recurring basis, keeping you away from human mistakes and security
vulnerabilities and allowing you to keep your data and your business logic
safe.

Developing a tool for security was also a way for us to implement all our
knowledge - that sometimes goes way further than what we saw in this book -
and to automate it, so that the entire Bubble community can benefit from it.

Here is a list of what the tool covers as of today :

• Data API checker: Automated check of all the opened Data APIs with non-
empty items inside

• Page per page redirect checker: Instantly know which page is well secured
and which one is not and avoid compromised admin dashboards

• Key-to-path backdoors

• API Workflows - Exposition and authentication

Bubble Security Cheat-Sheet

67 Flusk 2023
• API Workflows analyzer: Automated check of all the opened API Workflows in
the back-end of your app. You’ll know which one needs authentication, and
which one could be compromised

• Privacy rules semi-automated checker: During Vault setup, you define which
data and which fields are sensitive depending on your business case. This
will help us to define if sensitive data is leaked with your Data API or your in-
page search requests

• Swagger privacy checker: Flusk Vault checks if the OpenAPI specification is

publicly available

• Editor privacy checker: You automatically receive an alert when the privacy
of your Bubble editor is switched to « Everyone can view » or « Everyone can
edit » to avoid human mistakes

• Admin injections: We perform admin injections on your app to see if it can be

compromised (V2)

• XHR requests crawler: Page per page, we crawl every single XHR request
(searches, msearches) and look for compromised data that you defined as
« sensitive » for your business (V2)

• URL parameters brute-forcing: Page per page, we scrape the public JSON
object of your app and figure out how to access hidden content via URL
parameters and check for data leaks (V2)

• Cookie exploit

At the end of the analysis, you can find a detailed report with all the issues the
tool found on your app.

Bubble Security Cheat-Sheet

68 Flusk 2023
Here is what it looks like:

Flusk Vault Dashboard

Issues found by Flusk Vault

As you read this book and I’d like to personally thank you for that, you can
subscribe to Flusk Vault with a special 20% discount for your app for the first
year.

Bubble Security Cheat-Sheet

69 Flusk 2023
The promo code is the following: READER4800 (keep it for you!)
You can signup using this link, and here’s an article about how to apply promo
codes if you struggle with it.

We’re always ready to help you during your onboarding process on Flusk. Feel
free to ask whatever you want through our chat, which you’ll find in the
bottom-right corner of the Flusk website.

Bubble Security Cheat-Sheet

70 Flusk 2023
Conclusion
Thank you for reading this book.

As we say in French, « we never talk about trains that arrive on time » and you
will be faced with the same bias when securing your apps. When everything’s
going well, no one talks about it. But as soon as a vulnerability appears on one
of the apps you’ve built, you will be at fault.

People expect developers to have 0 flaws in the apps they build and they
consider it normal (and it is normal, isn’t it?). But as of today, I only know a few
Bubble apps with exactly 0 security vulnerabilities.

This book is a good starting point that will keep you away from most of the
known Bubble flaws, but it’s not enough to guarantee a 100% secured
application without any leaks or breaches.

Anyways, I hope this book will be useful for the Bubble community to build
better and more secure apps from the start. Flusk will always be there to try to
give as much credibility as possible to the Bubble & no-code ecosystem
because it is something we truly believe in and we think we have our job to do
in this lovely community.

If you want to push your Bubble Security knowledge further, I couldn’t miss
recommending you the Ultimate Guide to Bubble Security, by Petter Amlie.

ncScale also published a helpful book about security best practices.

Bubble Security Cheat-Sheet

71 Flusk 2023
Special thanks
This book was written in collaboration with a part of the Bubble ecosystem to
whom I owe a lot. Many have given their time to suggest, improve and correct
this book. This ecosystem has rare values of community and cohesion that
make our job a passion. We must absolutely keep this.

Special thanks to David Pal, Joris Grouillet, Dimitri Nicolas, Thibault Marty,
Antonin Javelle, Jean Zeren, Geoffroy Pélissier, Charles-Edouard Turquais,
Rémi Fossembas, Thierry Martin, Pierre Simonnin, Pierre Tillement, Peter
Prosper, Catherine Le Gressus, Alessandro Jeanteur and Julián Valentín.

If you have any questions or suggestions about this book, feel free to tell us.
I’d also love to know what you think about this book more generally.

Let’s connect on LinkedIn: https://www.linkedin.com/in/wesley-

wasielewski-664028203/

Bubble Security Cheat-Sheet

72 Flusk 2023
Made with love by Flusk ❤

Bubble Security Cheat-Sheet

73 Flusk 2023