This book is sold through GumRoad.

If you got it from somewhere else, please consider buying it or

buying me a coffee.

To stay up to date on new articles and tutorials about Bubble and

No-code, you can follow me on Twitter.

Petter is the founder of Amlie Solutions and an active Bubbler and

no-code developer, writer and public speaker since 2016. You’ll
find a growing number of articles and guides on
www.amliesolutions.com

This book is not in any way affiliated with or endorsed by Bubble Group, Inc.
 The Ultimate Guide to Bubble Security

Content
Content 2
Introduction 12
Thinking about security 13
Disclaimer (actually worth reading) 16
Extra material 17
What is app security? 18
Terms and definitions 24
Authentication and authorization 25
Privacy, security and compliance 26
Resources 27
Obfuscating versus securing 28
Data Compliance 30
Understanding data compliance 31
Regional case study: GDPR 35
Is Bubble GDPR-compliant? 40
Transferring Data 41
EU-US Privacy Shield 41
Sector case study: HIPAA 43
The Privacy Rule 44

2
 The Ultimate Guide to Bubble Security

The Security Rule 44

The breach notification rule 45
Is Bubble HIPAA-compliant? 45
Security and Privacy Policy 46
Policy vs. technology 47
Deciding on your Security and Privacy Policy 48
What makes up a security and privacy policy? 50
User Types 51
Online coaching platform 53
Blogging platform 55
CRM 57
Data types 60
Online Coaching platform 61
Blogging platform 63
CRM 64
Communication 66
Maintaining a consistent identity 74
Hardware 76
Storage and processing: the servers 79
Transit: the network of cables 87
The edge networks: the CDN 89
The final stop: the User’s device 92
Software 94
Vulnerability testing 95
Understanding encryption 96
Data in Transit: Understanding network protocols and TLS/SSL 99
Data at Rest: Encrypting the database 106

3
 The Ultimate Guide to Bubble Security

Backups and recovery 110

Database backups 111
Application backups 112
Snapshot backups 113
Passwords 114
Bubble 115
Securing your Bubble account 116
Setting a password 117
Two-factor authentication 121
Set a policy for your team and clients 121
Application rights 122
Keep track of collaborators 123
Naming your applications 125
Protecting version-test 126
Privacy Rules 127
What are Privacy Rules? 128
Why search constraints are not enough 130
The basic editor structure 130
Setting up a Privacy Rule 132
Security during submitting data via a workflow 138
Privacy Rules and APIs 139
Privacy Rules and refreshing page content 139
Page, Element and Workflow 141
Security 141
How to think about your UX and security 142
Optimize Application 150

4
 The Ultimate Guide to Bubble Security

Searches 151
Searches vs lookups 154
Workflows 159
Client-side vs server-side workflows 159
Scenario 1: hiding information in workflows 160
Scenario 2: overriding Privacy Rules 161
Making changes to database data 162
Privacy Rules and actions 163
Why you should use auto-binding to edit data 164
Conditions 165
Client-side vs server-side conditions: it’s all about the action 168
Setting up secure pages 175
Understanding redirect types 177
Server-side redirects (3xx) 178
Client-side redirects 179
Setting up different redirect types 180
On-page security 187
Designing with security in mind 192
Conclusion 199
APIs 200
Introduction 201
What is an API? 201
What is an API endpoint? 203
Swagger 205
How does Bubble connect to APIs? 209
Authentication 210
What is a token? 211

5
 The Ultimate Guide to Bubble Security

Authentication levels 212

Authenticating as a User Client 213
API workflows 217
Backend Workflows vs API Workflows 217
API Workflow settings 219
Parameters 221
Data API 222
Exposing Data Types 223
The Data API and Authentication levels 224
No token (Unauthenticated Clients) 225
API Settings 225
Privacy Rules 226
Temporary User Token 226
API Settings 227
Privacy Rules 227
API token 228
The API Connector 228
API Keys 229
How the calls are made 231
API endpoints and parameters 233
Initializing calls 233
The header 234
The Call 235
Hiding key information 238
URL 238
Parameters and initialization 239
User accounts 241

6
 The Ultimate Guide to Bubble Security

User stages 241

Sessions 242
Anonymous Users 242
Signing up 244
User attributes 245
User roles 248
What are User Roles 248
Permissions 248
Roles 249
Example 1: Simple Role Structure 251
Example 2: Complex Role Structure 267
Chrome Developer Tools 284
What is DevTools? 284
Opening DevTools 285
Ensuring a fresh download 286
Understanding network activity 288
Case: generating a one-time code 294
Sending the action to the Server 296
Fetching updated User information 297
Pseudorandomness 298
Lessons learned 299
Conclusion 301
Many decisions are made for you 303
What you see isn’t all there is 304
Security is about habits 305
Thank you for buying! 309

7
The Ultimate Guide to Bubble Security

8
 The Ultimate Guide to Bubble Security

Introduction
No-code is changing the world as we speak and Bubble is spearheading that
revolution. Founders with a great idea are suddenly able to bring it to a live, paying
audience in a matter of weeks, even without a technical background or a team of
developers. That’s huge.

As a reader of this book, you’re an early adopter of a framework that is likely to power a
big part of the web in the years to come. Being early means you have an opportunity to
leverage or become proficient in a technology with massive growth potential before
everyone else - but it also means you’re venturing into a sector where best practices
have not had time to develop. No-code naturally attracts those with limited coding
experience looking for ways to build their product without a tech team, and this
presents a challenge: those who have studied Computer Science for years have not just
learned to code. They’ve learned best practices that have evolved over decades on how
to keep data private, login forms safe and API connections secure. Now, even the best of
them fail sometimes, and data breaches happen even to the biggest of online players -
but the fact remains that to a non-techie founder building an app in Bubble, it’s very
hard to know what you don’t know. Even the bigger agencies occasionally leave
worrying security holes wide open in a client app, exposing everything from database

9
 The Ultimate Guide to Bubble Security

records to secret payment gateway API keys - unbeknownst to both developer and
client.

Bubble offers strong security, but doesn’t enforce it - you’re free to expose most data as
you please. What this book will attempt to do is to fill the knowledge gap on the things
you didn’t know that you didn’t know - so that every decision you make from there on
regarding security is a conscious choice and not an oversight.

Thinking about security

If you’re approaching Bubble without any development experience, one of the first
things you may need to familiarize yourself with is the simple fact that you actually
need to think about security in the first place. Because Bubble has a great security
structure in place, it’s easy to think that it’s already taken care of - and it kind of is - but
again, the never-ending differences in how Bubble apps are structured and the
platforms inherent open nature makes it possible and quite easy for you as a developer
to circumvent the built-in security and open up new, creative holes for data burglars to
squeeze their way into.

The solution is of course to make security a natural part of the development process - to
think about security while the work is planned, executed and handed over. To be able to
do that, we need to spend a bit of time getting to know the consequences of our
development decisions and how they affect the security of our app.

10
 The Ultimate Guide to Bubble Security

Your clients or users are not going to ask whether your app is secure or not - they’ll
simply assume that it is. And in this day and age, they’re right to do so. While you may
or may not question Google’s data collection practices, few people would argue that
Gmail or your Drive is insecure - you naturally take for granted that your data is safe
from hackers, accidental leaks and misuse.

Trust is a fragile thing, and a data breach or unintended access to accounts can make
your customers react in ways ranging from annoyance to legal action, depending on
what kind of data you store. Placing personal data in your hands and expecting it to be
safe there is a declaration of confidence and trust from your users, and one that
shouldn't be taken lightly.

Going back to the point of being an early adopter, we as members of the Bubble
community also carry a shared responsibility of maintaining Bubble’s reputation as a
secure platform. Bubble apps are now published by the thousands. In a few short years
there will be millions of apps, many of them made by newcomers to the platform.
While this is absolutely awesome, that growth also means increased exposure and
scrutiny - if cases keep popping up that Bubble apps are revealing user data, Bubble
and the no-code movement will suffer from it.

11
 The Ultimate Guide to Bubble Security

Let’s make sure we as developers create apps in ways that can withstand scrutiny and
strengthen no-code as the fast and secure way of building. It's not only the right thing
to do, but a wise investment however you're involved with no-code app development.

Especially since, as we’ll see, security isn’t that hard. There are really only a handful of
concepts that you need to know. But some of them can be very difficult to spot without
being told.

Hopefully, this book can be a first step towards establishing best practices for no-code
security in Bubble – we’re all better off if we can spread that information.

12
 The Ultimate Guide to Bubble Security

Disclaimer (actually worth

reading)
This is not legal mumbo jumbo: this is the first edition of this book, and best practices
in Bubble are still being established. While I’ve done my best to set up a guide to keep
your app secure from a range of different perspectives, you can never consider a book
able to cover every possible scenario that your app faces, nor does it in any way replace
a thorough security audit. This book does not constitute legal advice, and you should
consult your legal counsel to determine where your app falls under privacy and data
regulations in your sector and region.

In short - your app’s security is your responsibility, and the level of investment you need
to make into that security is up to you as its creator to decide.

It’s likely (like my previous book) that this book will be updated as Bubble’s platform
evolves, security flaws are identified and best practices are established.

13
 The Ultimate Guide to Bubble Security

Extra material
The book references several advanced methods, and to avoid straying too far from the
main topic, guides and tutorials for how to set those up are not included. In many cases
we have a free guide available on our website already, and where applicable we’ll link
to the article in a box like the one below.

We’ll sometimes also link to external articles that can provide additional information
about topics that are outside of the scope of the book.

If you want to learn more about how Option Sets work, you can find an
in-depth guide on the URL below:
https://www.amliesolutions.com/bubble/basic-features/option-sets

14
 The Ultimate Guide to Bubble Security

What is app security?

15
 The Ultimate Guide to Bubble Security

Your Bubble app is one of hundreds of thousands that exist right now, and they all have
a unique purpose, design and data content. Some of them may not need to secure
anything - others have security as a cornerstone of their feature set. Most of them fall
somewhere in between: naturally, every product in Amazon’s catalogue needs to be
public in order to sell, but you also trust that your personal information and purchase
history remains hidden.

In short, app security is every measure you as a developer take to prevent data from
being stolen or accidentally revealed. This includes both considerations that happen
while you build your app, and systems to make sure apps stay safe after they are
deployed and as development continues.

Generally, Bubble app security means making sure that:

● no one can access your Bubble account
● database content is only accessible to the right user(s)
● no one can access pages they’re not supposed to
● API connections don’t inadvertently reveal data or run unauthorized workflows
● you store code-related data (like API keys) in a secure manner

Methodologies such as the Lean Startup teach us that we should ship our product as an
MVP and invest the minimal amount of work needed to get it to the market. This
makes very good sense (I warmly recommend the book any chance I get), but the

16
 The Ultimate Guide to Bubble Security

security of your users is not one of the things you should sacrifice to ship quickly.
Especially - as we’ll see - because Bubble makes security pretty easy, as long as you
know what you need to protect and how.

Traditionally, app security requires a high degree of knowledge on both the hardware
and software side to set up. Over time, internet service providers like Amazon AWS
(which Bubble uses) have made sure that the hardware side and parts of the software
side are already taken care of. Bubble is leveraging this technology on their platform
and extending upon the software side of it with the aim of making app security
manageable by a single person with limited technical skills.

The good news is that you’re saving bucketloads of resources and cash on not having to
hire an expert team to maintain your app’s security. I’ll spend a chunk of this book
explaining how much structural investments, manpower, technology and billions of
dollars are spent setting up and maintaining the security of your app's data. Unless you
look for it, it remains well out of sight, but you can take my word for it - it makes airport
security look like child’s play. The app on your screen has been handed down by a chain
of professionals ranging from the engineer who designed the server’s microchips and
memory to the Bubble development team ensuring its integrity all the way up to being
printed as pixels on your monitor.

17
 The Ultimate Guide to Bubble Security

The bad news is that even if Bubble makes it a lot easier, there’s still a learning curve.
And let’s face it - we’re all but simpleminded humans with short attention spans easily
hijacked by more interesting things. And boy do we struggle with long-term abstract
threats. Security is not sexy. It doesn’t make your app look better, perform better or help
you sway new customers or investors. It simply rests there silently, never telling the
story about the time it saved your business from a PR nightmare - since its very
existence stopped that story from ever taking place. No one who has great security ever
seems to need it. Peculiar indeed.

You may also ask at this point "who on earth would try to hack my startup?", and
perhaps you'd be right that the chances are slim. But keep in mind that data leakage
doesn't need to be the result of a bad actor or malicious intent: it's just as much about
setting a security policy that is more lenient than your users expect, accidentally
revealing private data because of a missing search constraint or being unaware of how
much data Bubble sends to your browser even if it's not visible in your app.

Most developers don’t consciously choose not to prioritize security. In many cases,
they're unaware of the pitfalls. Other times, they simply delay it for a bit - let’s get a few
Users into the system first to get validation. As your app hits friends and family, bug reports
and feature requests start pouring in. You frantically and enthusiastically fix the issues
and add the features - all the while putting security to the side for another week. And
another.

18
 The Ultimate Guide to Bubble Security

Why does this happen? Well, just like procrastination, our priorities are more driven by
our emotions than we’d like to admit: if security is an area of Bubble development
where you feel not adequately educated and perhaps a bit bored, it’s easy to put it on
hold while you feel productive focusing on other things. Seeing immediate results,
getting user feedback and even perhaps starting to make a revenue is a lot more fun
than putting your precious work hours into preparing your defenses for an abstract
threat that may or may not materialize at some point in the future - especially if that
process involves having to learn something new.

Why do these psychological ramblings belong in a technical guide on security? Because

I’m hoping to drill the point home that from my experience, most developers put less
effort into their security than they self-report. As long as it’s on the to-do list, it feels like
it’s already done. But as we’ll see, security is an ongoing process that needs to be
considered before, during and after development.

If seeing security as something to be implemented ‘down the road’ sounds familiar,

you’ve got company. Security (at least outside of the Bubble sphere) is expensive and
the will to invest in it often comes after a breach has already occurred and a company is
caught with its pants down. Studies conducted by IBM revealed that 50% of companies
have a $0 budget allocated to securing their mobile apps and 40% of companies never

19
 The Ultimate Guide to Bubble Security

scan their apps for vulnerabilities. You’re not alone in forgetting to think about it or
mentally filing it somewhere in the back of your brain.

20
 The Ultimate Guide to Bubble Security

Terms and definitions

21
 The Ultimate Guide to Bubble Security

Authentication and authorization

Many digital security processes go through two recognizable steps:

● first, a system needs to identify who you are by verifying some sort of credentials
such as a username and password or a unique token
● When your identity is confirmed, the system then proceeds to check what
resources you are authorized to access you should have access to

This process consists of two similar words with different meanings: authentication and
authorization. For this book to make sense, we need to know the difference between
the two.

Authentication is the process of verifying who someone is. In real-life, you might
compare that to showing your passport at the airport. Just showing up is not enough,
you require some sort of identification to confirm that you are who you say you are. In a
digital process such as an API call, authentication can be done in many different ways.
Bubble uses a unique string known as a token to identify any Client that sends a
request.

Authorization is the process of determining what kind of resources a Client has access
to after it has identified itself. Going back to our travel example, showing your passport

22
 The Ultimate Guide to Bubble Security

and confirming your identity lets the airport staff proceed to determine what you are
authorized to do, such as boarding the plane and visiting the VIP lounge. In Bubble,
that's comparable to a logged-in User only being able to interact with specific data,
elements, workflows and pages.

Privacy, security and compliance

These three terms naturally come up in most conversations about app security, and
while they're certainly interconnected they don't mean the same thing.

To discuss the security and privacy features expected by your app's users and how you
can be affected by regional or industry-based regulations, we first need to have a clear
understanding of what they mean.

Privacy

Privacy is about how your Users expect and trust their data to be managed by your
software. Security is a part of this, but so is a sensible data privacy policy, clear and
understandable communication/design and respect for the User's trust. Companies
that manage private information have an ethical obligation to be transparent about
what will happen to that data, and to remain consistently true to that policy.

23
 The Ultimate Guide to Bubble Security

Security
Security is about identifying potential threats to your application and taking all the
steps necessary to ensure the data remains out of reach for any third parties, malicious
or not. A healthy security policy determines clearly what should be accessible to whom,
and your app's security is the sum of all measures taken to protect data in accordance
with that policy.

Compliance

Compliance is about knowing and following the laws and regulations that apply to your
business to avoid legal and financial costs.

All of these terms are of course in a circular relationship. You can't have privacy without
having security, no matter how good your intentions are. Investing in security is of little
worth to your Users if you have no interest in privacy and sell their data to the highest
bidder anyway. And a majority of regulations are designed to protect the interests of
Users by enforcing privacy policies and security measures.

Resources
As a User or external system interacts with your app, it offers different kinds of data and
processes such as database records, static data, and workflows. These will sometimes

24
 The Ultimate Guide to Bubble Security

be described under the collective term resources. Whenever we talk about a User’s
access to a resource, this can mean one or all of the above. This can also apply to
external systems, such as another application gaining access to your database or
workflows through an API.

Obfuscating versus securing

While the meaning of these two words may be obvious to most readers, pointing the
spotlight on them for a second provides a valuable framework for thinking about the
different measures you’re taking.

Some measures that you make (or that are made for you) are definite security
measures: encrypting data during rest and transfer and hashing passwords are both
examples of this. Obfuscation on the other hand, are all the measures that you make
that makes it more difficult and time-consuming for an intruder to access your data,
without actually adding a layer of security. Comparing it to a real-life example, security
might mean to hide your money in a safe, while obfuscation means to hide the money
somewhere in your house. While I wouldn’t consider the latter to be secure, it’s still
better than leaving the money by the front door. The best would be both: putting the
money in the safe, and hiding the safe.

What we can take away from this is that while obfuscation is not enough, it’s still worth
doing. Hackers are people too: whatever you can do to slow down, confuse and

25
 The Ultimate Guide to Bubble Security

frustrate them, you should. But keep this in mind: don’t confuse obfuscation with
security: hiding something or making it harder to understand does not equal security.

26
 The Ultimate Guide to Bubble Security

Data Compliance

27
 The Ultimate Guide to Bubble Security

Understanding data compliance

Data compliance…. Oooh, the hair in my neck stands up just hearing the expression. No
context exists in this universe in which compliance is a sexy word. But… bear with me
and let’s have a look at what it is. As the tech-savvy engineer that you are, it’s actually
pretty useful information no matter what kind of projects you’re planning.

Data Compliance is simply a set of regulations that describes what kind of security and
privacy measures are lawfully expected from a platform that handles digital data in a
specific region or sector. Some of these are directly related to the technology side
(secure data), while others are more focused on the legal and informational aspects
(always have a privacy policy).

Privacy regulations can be split into two parts:

Regional regulations

Regional regulations state that if your piece of software is to operate in this or that
region, it needs to adhere to a specific set of rules. Two of the most famous of these
regulations are GDPR (the General Data Protection Regulation in the European Union)
and the CCPA (the California Consumer Privacy Act in California). These regulations are in
place mostly to benefit the users of the technology: as we’ve seen over the last twenty
years, customer data management has been a wild west of companies pretty much

28
 The Ultimate Guide to Bubble Security

regulating themselves, often with dubious results: the GDPR and CCPA and other
regional regulations are one step towards giving users some control over how much
data is gathered and where it ultimately ends up.

While the GDPR may have gathered the most attention at least in the western world,
it’s by no means the only regional regulation. As of 2022, more than 130 jurisdictions
have data privacy laws in place, and more than 100 of them are outside of the European
Economic Area (EEA).

Data Protection and Privacy Legislation Worldwide

29
 The Ultimate Guide to Bubble Security

In the US there’s no one comprehensive federal law that governs data privacy, but all 50
states have their own data privacy laws in place. After the California Consumer Privacy
Act passed in 2018, several states started working on similar legislation to protect
consumers.

Growth of State Privacy legislation in the United States

While we don’t know what will be passed as law, the growth in Privacy legislation on a state level since 2018 is
clear. Source: iapp.org

30
 The Ultimate Guide to Bubble Security

Although many of the bills will likely not become law within the next few years, it’s still
an interesting insight that can help you plan for needed privacy measures across the
United States. Getting the right things in place early can help you avoid major changes
later.

Sector regulations

Several specific sectors also have regulations and laws in place to determine what kind
of data protection and privacy measures need to be in place. Common examples are the
storing of User’s medical data or financial records. Both of these sectors typically need
to adhere to strict regulations, as the data they manage is considered sensitive and
highly private.

Sector regulations are themselves regional, meaning that there’s no global framework
in place to regulate specific sectors. It’s again left up to the region, country or state in
which your company operates to set the local laws and regulations.

Sector regulations range from relaxed to extremely strict, sometimes to the point of not
being supported by Bubble’s technology at all. As such, using Bubble to build an app for
a specific sector/region is one of the most important pieces of research you’ll do early
on.

31
 The Ultimate Guide to Bubble Security

Working across regions

This may all sound daunting (and it can be), but keep in mind that even if there’s no
one set of regulations that applies everywhere, there’s still a major overlap in how the
laws are structured. If you’re compliant in one place, chances are that you can expand to
another region with no or minor adjustments. Still, the research is worth doing: as an
example, the GDPR is a lot stricter than most US state regulations on data protection,
and some US companies have even halted the European side of their business to avoid
the question of being compliant.

Regional case study: GDPR

We’ve already covered that GDPR is not the only data privacy law out there, but there
are still good reasons to go over it both as an isolated law and as a general case study.
It’s one of the most significant regulations ever introduced, gaining massive global
attention from the tech industry and by many seen as the ‘beginning of the end’ for the
wildly unregulated world of online privacy and the use of private user data as a saleable
commodity.

The first reason it caused such a stir even outside of the EU is the focus it has on the user
rather than the company. Even if a company is based outside of the EU, GDPR may still
apply if the user visits the site or service from the EU. Now, while each EU country in
isolation is not as highly populated as the US, India or China, the combined population

32
 The Ultimate Guide to Bubble Security

of the EU is close to 450 million - a significant user base, especially considering its close
cultural ties with the US. As non-US/EU companies are gaining traction in the western
world (like Beijing-based TikTok, which recently overtook YouTube in average watch
time), it’s easy to see how a EU-specific law has implications for companies all over the
world.

The second reason was that GDPR, being enforced by the EU, gives the ability to fine
companies up to 4% of their yearly revenue. For tech giants like Google, Amazon and
Facebook, that small percentage can amount to enormous losses. To put it into
perspective, Amazon was fined €746 million ($877 million), based on the claim that
Amazon’s advertising system doesn’t collect the user’s consent in a clear and
transparent enough way (at the time of writing, Amazon has appealed the fine).

Forgiveness vs permission

Up until this point, tech companies had largely acted on the notion that it’s easier to
ask for forgiveness than permission. They would collect, process and sometimes
sell/offer marketing based on data with no real oversight outside of their own
self-regulation and occasional media scrutiny.
One of the cornerstones of GDPR is that it turns this saying around and forces the
company to ask for permission to process personal data. The cookie warning bar (“We
care about your privacy”) and the option to adjust settings for data collection that are

33
 The Ultimate Guide to Bubble Security

now commonplace across the web are both highly visible measures put in place by
GDPR.

What does asking permission mean from a legal perspective? It means that a company is
not allowed to process personal data without a legal basis for doing so. The simplest
form of legal basis would be the user actually giving their consent for the data to be
collected and processed. This consent is usually given by clicking the OK on the cookie
warning bar without making further adjustments to the settings. In most cases, the OK
click and continued use of the app’s services means that you as a User have agreed to
the company’s data collection practices, privacy policy, cookie policy and sometimes
terms of use.
Another legal basis for collecting data and storing cookies would be that which is
needed for the service to perform at all - some functionality (like staying logged in)
requires some data collection, and GDPR considers it reasonable for a company to
process that data without the user having any choice (except to not use the service).

GDPR requirements
Let’s look at some of the other important requirements that GDPR places on online
services:

34
 The Ultimate Guide to Bubble Security

User data rights

Any User has the right to ask the company what kind of data they are storing about
them and get the full data set within reasonable time. Additionally, they can ask for
data to be corrected, stopped from processing, transfer to another service or even
deletion.

Data breaches

Companies must maintain a Breach Register, and both the data subject (User affected)
and the regulatory authorities need to be notified of the breach within 72 hours.

Privacy by design

This is the vaguest term in GDPR, but also one of the most important. It’s also one that
has led to company fines in the past. In simple terms, what it means is that companies
are expected to keep privacy and data protection a high priority in every aspect of the
design of their service. In other words, poor security can land you in trouble, even if the
case is not specifically described in GDPR.

Transparent, lawful and fair processing

That’s a legal mouthful, but it makes sense: Transparent means companies should be
transparent about their data processing (hence the use of cookie warnings and the
need for cookie and privacy policies). Lawful means they need to stick to those policies,
and not process data in any way that the User is not aware of or that serve no legitimate

35
 The Ultimate Guide to Bubble Security

purpose. Fair means that companies take responsibility and are expected to
continually provide protection and transparency as the service grows and develops.

The Data Controller and Data Processor

Don’t stop reading, I know this is a headache and you want to focus on building - but
give me just a few more minutes to lay out some more GDPR basics.

Running a tech company under GDPR requires your company to take the right
measures to be compliant. But - you may ask - what about the services that my
company uses? Services like… Bubble? Indeed, since you’re relying on the services of a
third party, you need to know that they are also compliant. This includes commonly
used tech products like Google Analytics, Mixpanel, Mailchimp and Twilio. Luckily,
most of the bigger service providers have been GDPR compliant for a long time.

What about the services they use, you may ask, imagining a never-ending staircase of
legal checks that you have to do. But keep in mind - for one of them to be compliant,
they need to know that its sub-services are compliant, so you only ever need to verify
the step connected directly to you.

These different roles are in GDPR split into three levels: The Controller, Processor and
Sub-Processor.

36
 The Ultimate Guide to Bubble Security

The Data Controller

The Data Controller is the service that the User signed up for. When you sign up for
Facebook, Facebook is the data controller, and when you as a developer sign up for
Bubble, Bubble is the data controller. However, when a User visits or signs up to your
app, you are the Controller and Bubble is a Data Processor.

The Data Processor

The Data Processor is any third-party service that the Data Controller uses to process
personal data. As mentioned above, Bubble would likely be a Data Processor to your
app, and so would something like Mixpanel or Google Analytics.

The Data Sub-Processor

As the name suggests, the Sub-Processor is any service used by a Data Processor to
process personal data, including any analytics solutions they use to understand their
business. For Bubble developers, Amazon AWS is also a Sub-Processor.

Is Bubble GDPR-compliant?
Yes and no. While Bubble as a Controller does comply with GDPR, your app is still an
isolated case that needs its own actions to be and remain compliant. As we discussed,

37
 The Ultimate Guide to Bubble Security

you are the Controller now, and that means that you need to take the necessary steps
and provide adequate documentation that you are indeed GDPR-compliant.

Transferring Data
Another cornerstone of GDPR is that it restricts the transfer of data from the EU to
outside of the EU, unless the company can legally document that the data is transferred
in accordance with GDPR’s regulations.

EU-US Privacy Shield

As a result of GDPR’s restrictions on the transfer of data, transferring data between the
E.U. and U.S. Servers became more complicated. To ease the process, the U.S.
Department of Commerce, the European Commission and Swiss Administration
collaborated and launched the EU-US Privacy Shield in 2016. The same year, the
European Commission deemed the framework to enable data transfers compliant with
E.U. law. Within this framework, companies could self-verify that they were compliant
with GDPR and register as an entity in the official Privacy Shield index.

In simpler terms - The EU-US Privacy Shield described the rules, and companies were
trusted to truthfully report their obedience to those rules in the official Privacy Shield
Index.

38
 The Ultimate Guide to Bubble Security

In July 2020 however, the story took a new turn as the Court of Justice of the European
Union issued a judgment declaring the adequacy of the protection provided by the
Privacy Shield to be invalid. As of that ruling, the EU-U.S. Privacy Shield Framework is
no longer a permissible mechanism to comply with EU data protection requirements
when transferring personal data from the European Union to the United States.

This concerned a lot of Bubble developers at the time - enough for Bubble to
investigate the matter from both a legal and technical perspective. As it turns out, the
court ruling does not rule out other mechanisms for transferring data. According to
GDPR, personal data of EU citizens can be processed by an external third party,
provided that they sign a legal agreement that regulates the processing adequately.
Adequately in this case means that the agreement needs to incorporate a set of
Standard Contractual Clauses, and the final document is what’s called a Data
Processing Agreement, often referred to as a DPA.

To ensure that the platform is compliant, Bubble set up their own Data Processing
Agreement. Effective as of August 28th 2020, Bubble’s DPA can be found here at the
time of writing. You will also find a legal document that includes a list of all of Bubble’s
sub-processors here.

39
 The Ultimate Guide to Bubble Security

Now for the part where you’ll call me crazy: reading these agreements is actually a
learning experience that can teach you quite a bit about how the inner workings of
privacy regulation works. Who the hell reads’em? you may ask. The answer is - very few.
Several surveys suggest that the number of people who actually read the Privacy Policy
of a new service is less than 1%.

But think about it this way: if you’re building a career on Bubble, reading this single set
of agreements can actually be beneficial to your understanding of your own business.
Whether you’re building your own company or working with clients, there’s just no
getting around that privacy regulations are here to stay - knowing the basic mechanics
of the regulations gives you a head start. Do it once. Should you take that advice, you’ll
find all of Bubble’s agreements here.

Now let’s move on to a sector case study.

Sector case study: HIPAA

The Health Insurance Portability and Accountability Act is another well-known
regulation, especially to readers from the United States. It’s similar in nature to what in
the UK/NHS would be called the Data Protection Act, and most countries have their
own version of this. In short, HIPAA was created for the healthcare industry with the
aim of safeguarding patient data, typically considered extremely sensitive and private
information.

40
 The Ultimate Guide to Bubble Security

Similar to GDPR, HIPAA is split into three rules:

The Privacy Rule

These standards contain both definitions and regulations. It addresses such subjects as
what Protected Health Information (PHI) is, which organizations must adhere to the
standard, how organizations can share and disclose PHI and what rights the patient
has over their own information. In principle (but not exhaustive), any kind of entity that
conducts healthcare transactions and/or stores patient information must follow the
regulations set in HIIPA.

The Security Rule

The Security Rule is aimed specifically at those who store PHI in an electronic format
(often abbreviated as ePHI). This is the more technical part of the regulation, and the
standards cover which organizations must adhere to it, what kind of information is
considered protected under the security rule and which safeguards must be
maintained to secure the data.

Organizations that fall under this umbrella must:

● Set up and maintain policies and internal processes and train employees to
ensure compliance
● Adequately secure ePHI against threats to is integrity and privacy

41
 The Ultimate Guide to Bubble Security

● Ensure the availability, integrity and confidentiality of ePHI

● Conduct risk analysis annually and create a Risk Management Plan

The breach notification rule

According to HIPAA, all usage or disclosure of PHI that the Privacy rule doesn’t permit is
considered a breach, regardless of it being a technical breach or human error. Once the
company becomes aware of a breach, it’s required to alert the affected individuals as
well as the Health and Human Services (HHS) within 60 days. If it affects more than
500 individuals, the HHS must be notified immediately, and the company needs to
publish a statement on their website.

Is Bubble HIPAA-compliant?

At the time of writing this, Bubble is not HIPAA-compliant. The framework specifically
demands that any data processor a service uses must in itself be compliant. As such, no
applications made on Bubble will meet the requirements*. This may of course change
in the future.

*Using custom code and/or compliant third-party services may help you overcome this,
but this book deals with Bubble as a standalone service

42
 The Ultimate Guide to Bubble Security

Security and Privacy Policy

43
 The Ultimate Guide to Bubble Security

Policy vs. technology

All the hardware and software technology in the world is not worth much if the
decision to protect data hasn’t been made in the first place. Planning, developing and
maintaining an app means making conscious decisions to keep certain parts of it
private and other parts public.

Some of the biggest data breaches that have occurred in the last twenty years have
happened to companies that have an ocean of resources to maintain security and still
were penetrated, sometimes easily. I’m not going to take the position of judging how
companies maintain their security, but they do raise an interesting conversation about
the difference between policy and technology.

While many breaches happen because of holes in the app’s technology, it’s also in
several cases hard to argue against the fact that a lack of security policy was the culprit.
If you’ve followed Facebook’s criticized breaches, it becomes apparent that third parties
were not given access to private data because of glitches, but because no decision to
keep the data private had been made in the first place. The data was simply there for
the taking, since no attempt was made to keep it hidden.

44
 The Ultimate Guide to Bubble Security

The process of securing an app follows the same logical path: first, deciding what kind
of security policy you plan to implement, and then lay out a plan to solve that from a
technological perspective.

Deciding on your Security and Privacy Policy

Let's spend a few seconds to change how your brain frames that header: reading it,
you're probably thinking about a dry, legal document that's been presented to you
about a thousand times. You've lazily and lyingly pretended to have read it and you
agree with every point. I accept. Click.

But you're at the other side of the table now. You're not the end-user, but the creator of
an app. The two words take on a different meaning - their actual meaning. A privacy
and security policy is not an external document, but a set of internal principles and
decisions that dictate how your app functions as a stewart of your User's private
information. The final document outlining your terms is simply the legal, textual
representation of all the decisions you’ve made during planning and development. This
is how we decided to manage your data. Do you accept it?

A policy does not provide any security on its own of course, but in many ways works as a
promise to your Users. Internally for you and your team, this translates into a set of
principles that guides your decision making: if you have promised your Users that their

45
 The Ultimate Guide to Bubble Security

data will remain safe, you have an ethical and legal obligation to set up the technology
in a way that makes it so. The policy doesn't dictate your technology point by point, but
spells out your intentions, with clarity and transparency. There's nothing inherently evil
about selling customer data to the highest bidder, as long as the Users are fully aware
and accept it (apps paying Users to fill out marketing surveys on behalf of an agency is
one example where this would be perfectly acceptable). The ethical issue arises when
you either hide that fact or it is obfuscated to the point of the majority of Users not
being aware of it happening. While your legal documents do reflect your business’s
intentions, your actual app also constantly communicates (or misses to communicate)
points that will lead your Users to make assumptions about how their data is treated.

Say for example that you have a built-in chat window in your product. I would take for
granted in most scenarios that the content of that channel remains private between
me and whoever I'm chatting with. Would I expect it to be end-to-end encrypted? No,
not necessarily, unless explicitly stated. I would expect that the app developers have
limited access to the data, and I would take for granted that they don't abuse that
access.

How about if I were talking to a medical professional? Or with the staff at a domestic
abuse crisis center? Or discussing financial matters with a bank? Or submitting a
controversial tip to a serious news publication? My expectations would change. I would
assume that the channel was more secure. And being the lazy, average human being

46
 The Ultimate Guide to Bubble Security

that I am, I would probably not go to great lengths to confirm it. I'd simply hope I was
right. In examples like these, the work that you do to provide the expected security is
not only the right thing to do for your Users, but lack of security can have very real
consequences in the offline world.

So a lot of trust is placed in the technology that we use daily; architecting a sound
privacy and security policy is about seeing your app through the eyes of the User and
asking yourself the question: would the User be negatively surprised about how we
manage their data? If the answer is yes - you don’t have the right policy.

What makes up a security and privacy policy?

Generally, a policy consists of the underlying decisions that you make strategically,
combined with what you communicate to your Users both legally and in the daily use
of your application. We can sum this up in a few points:

● Strategic decisions are made up of:

○ What you are forced to do
Legal obligations to stay compliant with regulations such as GDPR
○ What you decide to do
How you choose to manage data in addition to what regulations require
● Communication consists of:

47
 The Ultimate Guide to Bubble Security

○ Legal communication
The information you need to disclose to stay compliant with regulations,
such as your Privacy Policy, Cookie Policy and Terms of Use
○ Strategic communication
The information you choose to advertise to your Users to respond to
concerns, answer questions and build your brand

Let’s look at how we can structure a policy that makes sense. In this chapter we will not
be looking into the technical side of it just yet - we’ll be trying to see it from a strategic
perspective and get into the right mindset to make decisions about users, data and
communication.

User Types
Many Bubble apps will have different categories of Users, and you will need to set up
your technology to recognize these types. So what does that mean exactly? It means
that Users have different attributes that differentiate them from each other. You can
use these differences to grant access to data, pages, sections and workflows around
your app

For example, a User can:

● Be signed in or out

48
 The Ultimate Guide to Bubble Security

● Belong to a specific group, such as the company or team they work for
● Have different Roles, like User and Administrator
● Be members of your team (perhaps having a Role like Super Administrator)

A sound policy needs to take these different scenarios into account. A complex SaaS
may require a collection of rules for each Data Type, based on who the current User is,
and they need to be planned out before the data is set up.

User types can be planned in a wide range of different ways that provide an overarching
control over access (such as the User only being able to access a page when they’re
logged in) down to highly granular control (the User can only see and edit specific Data
Types and Fields). What’s important for you as a developer is to have a clear
understanding before the actual work begins on exactly how you want to control your
User’s access to data and features.

As a general rule, Users should not have access to anything more in your system than is
required by them to perform their jobs or for the app to complete its task. Most apps
don’t follow that rule slavishly, but don’t disregard it. From a security and compliance
standpoint, every feature and data point you give access to increases the attack surface
should an account be compromised. In other words, you should see this not only from
the perspective of a legitimate user, but what could happen if someone else gained
access to that User’s account. Limiting a User’s access also protects the User in the event

49
 The Ultimate Guide to Bubble Security

that something goes wrong: they can never be accused of wrongdoing (intentional or
accidental) if they didn’t have access to the data or features in the first place.

Let’s now go over some examples of what User Types might look like in a few different
applications. Without going into technical detail, we’ll discuss how we can think about
these roles in a human language.

Online coaching platform

CoachrTM is a platform that lets life coaches meet with students via video conferencing.
The coach can take notes, set goals and give homework to the student between each
session. The student can also take their own notes, complete their homework and rate
each session. The students pay for each session, and the coaches pay for the platform
with a monthly fee. What User Types do we need here?

Two of them we have already discussed (student and coach), but is that all we need?
What about the running of the platform itself? When coaches or students need
customer support? Managing invoices and refunds? It becomes apparent that we need
another User Type added to this that has broader access to features. Let’s discuss what
that entails.

The Student should have access to current and past sessions, where they can see their
own notes, homework and progress. They should not be able to see the coach's notes.

50
 The Ultimate Guide to Bubble Security

They can see their own session payment history but cannot refund sessions, and have
no access whatsoever to the monthly invoice system that the coaches use. They can also
see the goals that the Coach has set, but cannot make changes to it.

The Coach should also have access to all sessions, and to see their own notes, create
tasks for homework and rate the students progress by creating and updating Goals.
They need to have access to both the payment history of their students with the ability
to refund sessions, and to their own history of invoices for the platform.

Administrators are the staff working for Coachr. They need to be able to help both
coaches and students solve problems with the platform, as well as refund both sessions
and monthly invoices.

Looking at the administrator role, it’s easy to think that is it really necessary? Couldn’t we
just handle data directly in the Bubble editor and manage refunds in the Stripe or
Paypal dashboard? Technically, yes. But let’s dig a little deeper: I used the life coach
example for a reason: this is a service where the sessions can include highly personal
and sensitive conversations that both the coach and student will want to keep private.
Your app is also an extension of the Coaches promise to their Students of offering a
private and discreet channel for personal growth. Additionally, it’s a service where
there is no meaningful reason for a customer service representative to have access to
the personal notes and ratings: their job is to solve any technical or payment related

51
 The Ultimate Guide to Bubble Security

issues, not to intervene or comment in the personal discussions between the Coach and
Student.. In short: access to the database should be restricted to a select few, and the
customer service team should do their job not through the Bubble editor, but by use of
a separate administrator page that maintains the same level of security that the
coaches and students are subject to.

There could be cases where your team should have access to that data. If there’s a case
where one party is suspected of harassment and there’s reason for your company to
investigate for example, there could be mechanisms in place for the Coach or Student
to grant access. Exceptional cases that lead to selective and/or permanent access to
data can also be a part of your policy without contradicting the default security
decision.

Blogging platform

In our second example, we’re building WrtrTM, a mix between Medium.com and
Wordpress that lets publishers set up their own publications and work with a team of
writers and editors to publish articles. It has the ease of use and payment structure of
Medium.com, but the extended User management and teamwork features of
Wordpress. We’re going to need a few more roles for this one. Publications make
money by getting likes from their readers: a high number of likes means a popular
article and higher revenue. The platform makes money by charging the readers a
monthly subscription.

52
 The Ultimate Guide to Bubble Security

Users are the readers of the publication. They need to be logged in to the site to read
articles and rate them. When not logged in they can see the name and a short
description of each article and a paywall warning. They can only see an article after it
has been published, and cannot access the platform's backend page (where articles are
edited).

Writers are contributing content to the publication. They can create and edit articles,
but they cannot publish them. They can make changes to their own profile (edit their
name and other profile information), but cannot add new Users or make changes to
existing ones. They can see all their own articles, but they cannot see unpublished
articles written by other writers.

Editors can do everything that Writers can do, but they can also publish/unpublish
articles and see all articles, regardless of who wrote it. They have no access to make any
changes to registered backend Users.

Administrators have all the privileges that Editors have, but can also add, edit and
delete backend Users, including assigning them to a specific Role
(Writer/Editor/Administrator). Administrators also have access to the payment section
where they can see the history of payments from Wrtr.

53
 The Ultimate Guide to Bubble Security

Super administrators are Wrtr staff that work to keep the platform running and help
clients solve technical issues. They have access to manage registered Publishers, their
staff and registered Users (readers), and can see the payment history of all Publishers.
They cannot see unpublished articles and cannot edit articles, but they can unpublish
articles in the case of a dispute such as a copyright infringement claim.

This time we’re seeing multiple levels of administrative privileges. Publishers place a
high degree of trust in the platform to keep their writing absolutely confidential until it
is ready to be published, and again we’re in a situation where it’s not given that your
staff should have access to all data. We’re also starting to see that attributes saved on
the User (such as Role) are often combined with the attribute on a Thing (Article is
published) in order to complete the security constraint. This time we’re also touching on
a SaaS feature: which Publisher backend Users are registered to determines what kind
of data they have access to. Naturally, an editor can only see the unpublished articles
that belong to their parent Publisher.

CRM
ZeeArEmTM is a new type of CRM that combines traditional customer management and
communication (email and phone calls) with communication via social media (Tweets,
Direct Messages and comments) to manage and automate sales processes. It offers a
wide range of features that are expected to be used by an equally wide range of

54
 The Ultimate Guide to Bubble Security

different employees: sales people, team leaders, social media marketers, automation
developers. The platform focuses on small and medium-sized businesses by launch,
but plans to scale the business to enterprise level within the first few years. The
platform’s revenue comes from User licenses.

This time we need to think differently about Roles. For smaller businesses, a software
platform of this kind may get away by offering a few preset roles (Admin, Salesperson,
Marketer), but enterprise customers will have none of that: they require full control
over the Roles and Permissions. To avoid having to backtrack and make major changes
to how the database is set up, you decide to implement a flexible system that allows
companies to create their own Roles and assign permissions to them. This way, access
levels can be tailored to any kind of business and team constellation. As long as your
technology is set up correctly, your clients carry the responsibility of determining what
a specific Role should have access to and not. Still, we need some User types to be
preset in addition to the client-generated ones.

Users are the everyday Users of the app – your client’s staff members. This is a flexible
User type where Users are assigned a Role by an Administrator, and this Role
determines what the User has access to. No matter what Role they are assigned, a User
can only ever have access to data that belongs to their parent Company (your client).

55
 The Ultimate Guide to Bubble Security

Administrators can manage Users and Roles. They can assign permissions to these
roles and assign them to Users. These permissions give a highly granular control over
what each User role can do and what sections they can access. For example, a Role may
be given permissions like Can publish social media posts, Can add Clients and Can manage
invoices. Administrators can give these Roles descriptive names like Account Manager,
Team Leader and Social Media Marketer and apply these Roles to Users as they see fit.

In this case we’re getting into more advanced territory, and we can clearly see that a
system with this level of complexity needs to be carefully planned as it affects every
facet of the platform: Users, Data Types, Pages, Elements, API access and Workflows.
Building a system with this kind of granular control requires a deep understanding of
how to plan, build and maintain it from both a policy and technological perspective.
That being said, Bubble is perfectly capable of providing this level of advanced User
management as we’ll see in the later chapter on setting up Roles and Permissions.

What these three examples have in common is that they underline the importance of
planning and understanding what kind of Users your app will have. All three also
illustrate scenarios where you have three unforgiving clients: life coaches and students
who exchange highly private information, Article publishers whose competition would
love to know what they’re working on and enterprise-level SaaS clients who require
watertight security and a high level of flexibility.

56
 The Ultimate Guide to Bubble Security

Data types
Having decided what kind of User types you will have in your app, it’s time to look at
your Data Types and decide how private and secure they need to be. Each Data Type in
your app will have its own requirements and needs to be considered in isolation along
with each User type, and they'll all fall under one of three categories:

Full protection
Access to a record of the entire Data Type is prohibited except when specific
requirements are met. Typical examples are a User's shopping cart (only the User who
created it can see it), the companies saved in a SaaS CRM (you can only see companies
that are created by your parent organization) or the messages in a chat session (only
the sender and recipient can search for them).

Partial protection
Anyone can search for records of this Data Type, but certain fields are kept private. If
you run an eCommerce site, you need Users to be able to search for Products, but you
may not want to reveal the profit margin or other internal data that your staff might
need in their work.

No protection

57
 The Ultimate Guide to Bubble Security

Some data types are open for the world to see: anyone can search for them and view all
fields.

Naturally, Data Type categories can overlap. For example, a set of blog posts may be
public data, except for posts that haven't been published yet. The same could apply to a
Product that's not yet launched, canceled or sold out.

We'll think about Data Types in the same way that we think about User Types and
describe the requirements of some of them without getting too technical. Let's use the
same examples as before, but this time look at it from the perspective of the Data
rather than the User. Typical questions you can ask for each data type are:

● What User Types can see this data?

○ Are there fields that need to be more strictly protected?
● What User Types can Create, Edit and Delete this data?
○ Should only the creator be able to or other User Types as well?
● Does the data have any status changes that affects who can see or make changes
to it (such as an Article being published or not)?

Online Coaching platform

Session

58
 The Ultimate Guide to Bubble Security

Sessions can only be seen by the Coach who hosted it and the Student who attended it.
Both the Coach and the Student should be able to add notes to the session, but they
cannot read each other’s notes. Coaches can add homework, and Students can respond
to it. Administrators can see past and future sessions, but cannot read any notes or see
the details of homework assignments.

Goal
Goals can be created, edited and deleted by Coaches. They can be seen by Coaches.
Administrators have no access to Goals.

Session invoice
Session Invoices can be listed and read by the Student who paid it, the Coach who
hosted the session and all Administrators. Coaches and Administrators can click a
button to refund a payment to a Student. The Student cannot make any changes to an
Invoice.

Monthly invoice
The monthly platform fee invoices can be seen only by the Coach it belongs to and by
all Administrators. Administrators can click a button to refund an invoice.

59
 The Ultimate Guide to Bubble Security

Blogging platform
Publisher
Publishers are the parent companies of a group of Users. A Publisher's name and logo
can be seen by anyone, even unregistered Users. A Publisher’s name and logo can only
be edited by Administrators.

Articles
Articles that are published can be searched for and viewed by anyone, but unregistered
users can only see the header and introduction. Unpublished articles can be seen by the
User who created them and Users with Editor or Administrator roles. Both Articles and
Users belong to a Publisher, and no one can see unpublished Articles that belong to a
different Publisher.

Users
Users who do not belong to a Publisher can see and edit their own user data but no one
else’s. They can be seen and edited by Super Administrators. Users who belong to a
Publisher can be seen by anyone, and can be edited by themselves, Administrators and
Super Administrators. Adding Users to a Publisher can only be done by Administrators.
User Roles like Writer, Editor and Administrator can only be edited by Administrators and
Super Administrators.

60
 The Ultimate Guide to Bubble Security

CRM
All data in the CRM can only be viewed by Users who belong to the Parent Company in
which it was created.

Clients
Clients can be edited only by the User who created it, and by any User whose Role has
the Can Edit All Clients permission. Clients can only be added by Users whose Role has
the Can Create Clients permission.

Leads
Leads can only be seen by the Users who created them, and Users whose Role has the
Can see Leads permission. Leads can be created only by Users whose Role has the Can
Create Leads permission. Leads can be edited only by the User who created it.

Again we can see that the two first examples have fairly straightforward and static
needs, while the CRM requires a more complex setup (don’t worry if you struggle to
understand this now; we’ll get back to Roles and Permissions later).

It’s helpful to do these exercises exactly as we did above: before thinking about the
technical aspects of security, simply spell out on paper what kind of Users and
Permissions you envision for your app. Every future decision you make while
structuring and designing your app will be affected by the planning you do in this

61
 The Ultimate Guide to Bubble Security

stage. If you have worked with Bubble for a while, I don’t need to tell you how time
consuming it can be to go back and make changes rather than getting it right the first
time.

If you’re working with clients, it’s useful to involve them in this part of the process.
Businesses, especially large companies, tend to have internal policies that dictate
access levels for their employees across a sometimes large pool of tools that they use,
and the lack of a dynamic Role and Permission system like described in the CRM
example can be a deal breaker. Other companies and end-users may prefer a much
simpler system that doesn’t overwhelm them. Naturally, a more basic system requires
less development time and maintenance so there’s no reason to assume that the more
advanced system is always better. See it as our job to make security no more
complicated than it needs to be: more complexity only adds to the number of things
that could potentially go wrong.

Before your app goes live, privacy regulations in most parts of the world require you to
create and maintain a Privacy Policy document that describes how your data is being
managed. While you can (and often should) outsource this work to a legal professional,
you can also see what we’re getting at here: only you and your collaborators know how
the data is actually managed, and you may be surprised as to how active a role you may
have to take for your legal council to be able to accurately document your policy.

62
 The Ultimate Guide to Bubble Security

Again we can see that the privacy and security planning stage also helps you as a
company builder understand your own product.

Communication
The third part of your policy will move away from the database and focus on how you
communicate with your Users. When Users think about privacy, they are not just
concerned with data being stolen or leaked. They’ll also be curious about how that data
is being collected and used as a part of your business. As we discussed, viewing, using
or even selling customer data is not illegal or unethical by default, but if that’s part of
your business model it needs to be communicated properly. The purpose of this
communication is to be transparent in order to build trust. Lack of transparency will do
the opposite: awaken a sense of distrust and insecurity about your intentions and how
your app manages data. We’ll go over concerns that Users typically have and look at
examples on how you can communicate clearly to your Users that their concern is
unfounded. You can see this as an extension of your actual privacy policy document:
whenever it makes sense to make Users aware of a specific point without having to
actually read the whole thing, you can leave small nuggets of information in key places
of your application to answer common questions, alleviate concerns and maintain a
sense of transparency.

63
 The Ultimate Guide to Bubble Security

Let’s look at some common apprehensions that your Users might have when they start
using your service and how your communication can put their minds at ease.

Theft or leaking: Is there a risk that my data will be stolen somehow?

The degree of concern for data being stolen tends to go hand in hand with the
sensitivity of the data. If your app is indeed handling personal data and you are
confident that you have done everything in your power to secure it, you can let the
Users know.

If your app is handling sensitive data, you can increase trust by communicating that this is a major priority for
your company. In the example above, the security-focused file-sharing service Tresorit pushes this message on
their front page. Naturally, knowing Bubble’s own security standards and being confident that you have set up
your app in a secure way is a prerequisite for making promises like this.

64
 The Ultimate Guide to Bubble Security

Just like the case with Tresorit, apps sometimes communicate privacy as a feature.
WhatsApp made a decision to implement end-to-end encryption on all of their
conversations, and they’re communicating this every time you open up a new chat:

WhatsApp communicates clearly that conversations are private - that investment into encryption might not
have been worth it if that information was hidden away in a long Privacy Policy where very few would see it.
Note that they make a point that not even WhatsApp’s staff members have access.

As you can see in the example above, WhatsApp points out that not even they have
access to the conversation. In scenarios where you are managing highly personal or

65
 The Ultimate Guide to Bubble Security

sensitive data, it may be worth pointing out who has access to it, even internally in your
company. With Bubble it’s hard to claim to have no access, since someone always needs
to have access to the database where everything is stored, but you are free to set up
your platform to physically limit the access your team has to data and communicate
that to your customers.

Selling of information: Will my data be transferred/sold to a third party or be used

for purposes that I’m not aware of?
Who hasn’t experienced registering for a service using your email address, and then
tripling the amount of spam emails you receive right after? Chances are that the service
you signed up for shared that email with one or more third-party marketing companies
and suddenly you find yourself on an email list that pumps out annoying spam several
times per week. Studying their privacy policy, you see that it’s actually stated in black
and white; depending on where you are in the world, they could be within their rights
to do so after you accepted the policy and voluntarily entered your email address. Now
if it’s so legal, why does it taste so bad? Obviously, there’s a problem with
communication here: the company takes advantage of (or at the very least seems to take
advantage of) the fact that very few people actually read the privacy policy. It would be
hard to take that company seriously from then on, making it a terrible brand decision.
Turning the problem around, to ensure your potential Users that this is not going to
happen, you can consider adding this information to the sign-up form:

66
 The Ultimate Guide to Bubble Security

Predicting User’s concerns about privacy and security and communicating accordingly both builds trust, and in
cases like the above can increase your conversion rate. Don’t assume that your Privacy Policy will do that job on
its own.

Looking at Facebook (Meta) who have been criticized for years for not being
transparent about how data is shared, they too have introduced attempts at
communicating transparently, like their Privacy Checkup tool available in their security
settings:

While the tool may seem to be too little too late, it’s likely that going through the Privacy Checkup tool has
made a percentage of Facebook Users more relaxed about how their data is used, and thus has served its

67
 The Ultimate Guide to Bubble Security

purpose. To be fair, it has also made it easier for Users to make changes to their account that was previously
buried in endless, confusing privacy settings.

Keep in mind that the examples above are not “best practices” or “must-haves”; they’re
simply illustrating steps that other companies have taken to answer privacy concerns
that their Users might have. Whether your Users have pressing questions that you want
to proactively address in your app is up to you to decide.

Other User’s access: will the data I share here be visible to other Users?
When you enter information into a computer system, it’s not always clear who has
access to that information afterwards. Looking at our Online Coaching Platform
example from earlier, we agreed that both the Student and the Coach can add notes to
a session, but none of them can see each other’s notes. But the User doesn’t know that,
and it can greatly affect how actively they use this field.

68
 The Ultimate Guide to Bubble Security

A simple sentence can make Users more at ease about using one of your app’s features. Without this field, I
might be concerned that my life coach could see my notes, and it would affect what I used it for.

A very small visual change in your application puts your Users at ease about that
particular feature and instills a sense of trust that you care about their privacy. It’s also
well-documented that we behave differently when we suspect we’re being watched; if I
wasn’t sure if my life coach could see my personal notes, I would hold back on its use,
and your app would lose a little bit of its value.

Similarly, Google in its document sharing settings makes it very clear to see who has
access to what in the document:

Google has made a deliberate design decision to make it easy to see who can do what in your document.
There’s no need for the User to ask the question, as it is already answered.

This design choice leaves little room for doubt or interpretation. The checkbox saying
Notify people is not just a setting but a clever piece of communication: I don’t have to
wonder whether they will be notified (as is the case in a surprising number of other

69
 The Ultimate Guide to Bubble Security

apps). Finally, these settings also suggests that documents are completely private by
default: sharing them is an option.

Data loss: is there a chance that I might lose my data?

Like we saw in the chapter about Amazon AWS, any data that you transfer to the cloud
is safely backed up and kept safe from all kinds of physical threats. With power players
like Amazon, Google and Microsoft hosting a majority of cloud systems these days,
Users are increasingly getting used to the idea that their data is safe: still, depending
on the nature of your business, this is sometimes worth advertising. Take Bubble: they
are very much aware that their clients are putting a lot of trust in their software and
ability to maintain the integrity of their data and remain in business. They’ve taken
care to communicate on several occasions that if their business were to fail, they will
open-source the source code to make it possible for businesses to remain on the
platform and secure their investment in the case of bankruptcy. This addresses an
obvious concern that potential clients might have, and tells you something about the
integrity of Bubble’s founders.

The novel writing platform Novlr respects that their Users are worried about losing
their work (which can be both a highly personal and monumental undertaking) and
advertises their commitment to back it up securely and keep it safe:

70
 The Ultimate Guide to Bubble Security

To the developer, the constant backing up of work and the level of security offered by
major cloud providers may be obvious, but to the User it can be a critical worry. For
those who have been around before Amazon and Google took over the online world,
losing potentially years of work from a technical glitch or physical harm to your device
was a very real possibility that left bruised Users taking great care to avoid it ever
happening again. If they are your potential clients, let them know that this is one of
your features.

Maintaining a consistent identity

Just like the decisions about user types and data types, communication circles back to
your User: how do they expect you to manage their data, and how can you
communicate clearly to leave no room for misunderstandings? You might be surprised
at how much Users appreciate a sense of trust in the products that they use, and you
can use this to your fair advantage.

71
 The Ultimate Guide to Bubble Security

This is not to say that you should sprinkle these messages all over your app: too much
could have the opposite effect of what you intend. But wherever there’s room for
interpretation or misunderstanding, you can see this as a tool in your communication
toolbox to answer questions and build confidence with your Users. Don’t make the
assumption that they can read and learn from your Privacy Policy: few ever do. If Users
hesitate to leave their email address or use the Note feature in your coaching app, let
them know it’s safe to do so.

The policy you decide on makes up a big part of your company’s identity. It has the
added effect of making future decisions about security and privacy easy: as you’ve built
your brand around a specific set of rules and values, you’ll naturally work to stay
consistent with what your Users have come to expect. As a User, I don’t want surprises:
trust is built over years and ruined in seconds.

72
The Ultimate Guide to Bubble Security

Hardware

73
 The Ultimate Guide to Bubble Security

When we discuss the hardware side of internet security, we’re of course talking about
the physical devices involved in the storing, processing and displaying of data.

As a Bubble developer, you’re likely already familiar with the setup above. As your
Bubble app Creates, Reads, Updates and Deletes (CRUD) data, there is ongoing
communication between the device of the user (i.e. laptop or cell phone) and Bubble’s
servers. The distance between the devices can be vast - if you’re a Bubble user in
Australia, Bubble’s server might literally be on the other side of the planet.

The Server is the remote computer where Bubble’s database is stored, and where
Bubble’s own engine performs its operations and calculations. Whenever you ask your
Bubble app for something (such as Do a Search For), a query is sent from the Device to
the Server, and the server then performs the actual database search. When the results
are ready, it sends the resulting data back to the device. The data travels through

74
 The Ultimate Guide to Bubble Security

interoptic cables over land and under the sea at near the speed of light, and during this
phase, the data is considered to be in Transit.

What kind of threats are there to the hardware side of a Bubble app? Well, Hollywood
movies with hooded teenagers cracking nuclear access codes have made many of us
forget the most basic threat to computer security: physical access. As we talked about
earlier, great security is a lonely hero, and in today’s online landscape, getting physical
access to steal, change or erase data stored in a reputable server park is next to
impossible.

If you were running a fast-growing social networking site from a server in your office,
the threat of break-ins to steal data or sabotage your efforts would be very real and
even likely given a long enough timeline. Sending your site offline would be as easy as
cutting a power cable or the internet connection in the building. A fire, earthquake,
flood, hardware malfunction or clumsy employee with a cup of coffee could cause
irreparable damage to your business.

Centralized server parks like those created by Amazon leverage the enormous scale of
their client base to basically subsidize the needs of startup operations like your own,
giving you access to the same level of security, processing power and services that
billion dollar companies have. Offering those same services to their smaller clients

75
 The Ultimate Guide to Bubble Security

doesn’t cost them more – it’s the research & development and infrastructure that’s
costly – so they do. And we’re all better off for it.

So – servers and cables are physical things that can get broken into, damaged, burned,
and stolen just like your new iPhone or Tesla. We’ve established that because you’re
part of a bigger network, you don’t need to worry about it - it’s all taken care of. But
what exactly does that mean? How exactly do we know that the computers on which
your app runs is safe from all physical threats?

Let’s have a look.

Storage and processing: the servers

Bubble’s servers, a.k.a. Amazon AWS

Bubble’s security on the hardware side is in large part handled by its sub-processors,
and in particular AWS. Most Bubble developers are probably familiar with Amazon’s
data centers and at least some of their services, but may not be aware of just how big a
part of Bubble’s infrastructure depends on it.

76
 The Ultimate Guide to Bubble Security

Before we jump into AWS’s security, let’s first all just appreciate the mind-blowing
sheer scale of it. At the time of writing, Amazon’s server park consists of 25 regions
globally with a total of 38 data centers. Each of these centers hold somewhere between
50 and 80 thousand servers, each single rack holding up to 11 petabytes of data (that’s
11.000.000 gigabytes) that can send and receive 102 terabytes of data every second. The
idea for Amazon to set up its own hardware infrastructure was born as far back as the
year 2000 when the company started realizing that the infrastructure availability was
becoming a bottleneck for the continued development of Amazon and its subsidiaries.
It took several years for the project to see any further development, but gradually an
insight became apparent internally: if we’re struggling, so is everyone else. The internet
was growing exponentially even after the dotcom bubble, and there was no sign of it
slowing down: if Amazon needed their own server parks anyway, why not see that as a
chance to make money renting their resources out to other companies struggling to
scale?

In AWS’s early years, they were buying server equipment from third party vendors, but
as the infrastructure grew and a number of new web services were added, Amazon
gradually switched to building their own equipment. In 2015, Amazon acquired the
Israeli microelectronics company Annapurna Labs and the $350 million investment
helped Amazon in the continued development of their own hardware, resulting in the
unveiling of the AWS Graviton Processor in 2018. Why would Amazon – an online
retailer – get into the business of producing microelectronics?

77
 The Ultimate Guide to Bubble Security

It’s not just a question of economics. Think about Apple’s closed ecosystem: every part
of your Apple device - both the hardware and software - are designed to work together.
Not only do they avoid compatibility issues with a range of different hardware setups,
but they can also set up their hardware to serve the software in specific ways like the
recent release of the M1 chip has shown.

The AWS Graviton processor follows the same logic: as Amazon expands the services
they offer to clients (like machine learning, video encoding, streaming and indeed
databases) they can configure the hardware to perform microtasks directly on the chip,
saving nanoseconds of processing time that on a global scale amounts to enormous
savings for a wide range of different industries. If you’re into gaming, this is
comparable to investing in a new graphics card to get that sweet ray-tracing running in
60 fps. Ray-tracing is one of the most complex calculations in 3d graphics, requiring a
ridiculous amount of processing that your general processor simply can’t handle - but
by building hardware specifically to handle that one task, Nvidia has put that capability
into millions of home computers. This kind of hardware optimization is what makes
video/game streaming,machine learning and other specialized and
resource-demanding tasks available on a global scale.

Performance aside, producing their own hardware also allows Amazon to strengthen
the security of their servers and processes by building parts of it directly into the chips.

78
 The Ultimate Guide to Bubble Security

Not only does that provide security on a hardware level, it also means that no third
party outside of Amazon’s sphere has control over this part of the infrastructure.

AWS has grown into the largest service provider of its kind in the world (rivaling other
giants like Google and Microsoft Azure), and become a pillar in Amazon’s business,
closing in on $100 billion in revenue or 13% of Amazon’s total as of Q2 2021.
The history of AWS means that Bubble and all its apps - without the need for major
investments - is built for scaling from one to millions of Users with the click of a button.
And, as we’ll see, for maintaining the security of all those Users.

Amazon’ layers of security

Just like in your Bubble app, security means a lot of different things for Amazon. It’s not
just about keeping hackers out, but also for the data centers to remain impenetrable to
physical attacks, power outages, draughts, fires, extreme weather conditions and
whatever else humans or mother earth may decide to throw at it. Amazon’s client base
consists not only of internet giants like Adobe, Netflix, AirBnB, Disney, Lyft, Twitch and
hundreds of others, but also security-focused enterprises like The European Space
Agency, Pfizer, Moderna, The U.S. Defense Department, CIA and most recently the
NSA.

79
 The Ultimate Guide to Bubble Security

Amazon has a history of working with its biggest clients to grow its service. Netflix
offered HD streaming through AWS to a huge client base at a time when servers and
bandwidth were not thought to be able to deliver a stable viewing experience.
Amazon, knowing that video streaming was here to stay, saw it as a chance to both
make a 19 million dollar client happy and prepare their systems for the future of video.
Over the course of the last decade, as branches of government and even the
intelligence community has started moving its data storage and processing to the
cloud, Amazon has yet again recognized the chance to let a challenging client push
AWS to reach new standards in performance and security.

The end result for you as a Bubble developer is a supercomputer infrastructure that
offers the same physical and digital security, uptime, backups and power that the CIA
and NSA use.

The internet has come a long way since GeoCities.

Amazon’s security layers

Now let’s talk about the physical security that Amazon has invested in for their data
centers. Since a server park can potentially fall victim to a wide range of different
threats both humanly caused and natural, Amazon have divided the different
segments of security threats into layers.

80
 The Ultimate Guide to Bubble Security

The Perimeter Layer

The perimeter layer describes the physical security of the data center and its
surrounding area. The AWS data centers are mostly hosted in anonymous buildings.
Their perimeters are walled in with barbed-wire fences and several layers of digital
intrusion detectors that includes surveillance cameras. The area is guarded 24/7 by
security personnel and entering the building requires clearing several security
checkpoints with ID verification, metal detectors and scanning equipment similar to
what you would find at airports.

Access to the data center itself is limited to a small group of staff members that are
logged in and out to allow them access only in short intervals. Members of the staff are
subject to random checks and interviews to maintain integrity, and any signals of
unusual behavior (such as a door being held open too long) automatically triggers an
alert and log point.

Visitors are very rarely allowed entrance, and anyone who is granted access is
accompanied by an AWS staff member at all times.

The infrastructure layer

If you think your Macbook is running hot on your lap, imagine the heat produced by
80.000 supercomputers. The infrastructure layer is where crucial systems like

81
 The Ultimate Guide to Bubble Security

air-conditioning, fire suppression and backup power are maintained. Increasingly, even
this part of Amazon’s centers is self-sustained, relying on their own solutions rather
than external power and water suppliers. Amazon’s number of data centers generally
grows faster than local power companies can keep up, and server parks require a
massive amount of electricity.

This layer is also where AWS’s systems and staff constantly monitor the data center for
changes in humidity, temperature and other potential threats.

The data layer

We’re now in the running of the servers themselves. Every single server constantly
monitors itself for even the slightest signal of intrusion, digital or physical, and
instantly deactivates and shuts down if it suspects something, redirecting the workload
to another server (usually with no noticeable delay). Backups and processing is spread
out in the AWS global network through the aforementioned global network of cables,
ensuring minimal downtime even if an entire data center should be under some kind
of threat or malfunction.

The entire structure of the perimeter, employees, hardware, software and internal
processes is audited several times per year by an external security company overseeing
a list of more than 2,600 requirements. When a storage device reaches the end of its

82
 The Ultimate Guide to Bubble Security

life-cycle it’s stored in the data center until it’s been properly decommissioned and
data cannot physically be recovered.

The Environment Layer

Finally, the environment layer maintains security from extreme weather conditions,
floods, seismic activity like earthquakes and other environmental factors. Everything
from the location of the center to constant environmental monitoring makes sure that
the centers maintain their uptime even in the most unusual of environmental
circumstances.

The environment layer is also responsible for Amazon’s long-term commitment to use
100% renewable energy and other sustainability goals.

All of these perimeters and security measures may feel far-fetched from your own
reality as an app developer, but keep in mind that the stability and uptime of your
Bubble app is no coincidence. It's the end result of an almost unfathomable amount of
investment in hardware components, continually upgraded software, military-grade
physical security and rigorous auditing and testing - which you're privileged to be
blissfully unaware of.

83
 The Ultimate Guide to Bubble Security

Transit: the network of cables

As we’ve touched upon, when information is physically moving from one point to
another, we describe it as being in transit.

In the time of wi-fi, fast mobile networks and Teslas launched into space you might
think that the internet is largely wireless, traveling between the continents via
satellites, but this is actually not the case. The internet is an enormous collection of
cables criss-crossing the globe via land poles and crossing entire ocean floors to
connect the continents to each other. Each cable is about as thick as a garden hose and
can carry tens of terabits of information per second and together they carry 95-99% of
all internet data.

Many are surprised to learn that fiber optic cables are in fact a state-of-the-art
technology, and are a lot more efficient than satellite communication would be. Since
they use light to encode information and are basically closed systems with no road
blocks (as compared to how the weather and cosmic radiation can disturb wireless
signals), data can travel at incredible speeds with no loss of data. Wireless
communication is not likely to replace cables in the foreseeable future.

84
 The Ultimate Guide to Bubble Security

So who owns and maintains these cables? On land, the networks are owned by private
companies usually called ISP’s (Internet Service Providers). Historically, the undersea
cables have been owned by different companies, mainly telecom providers (who can of
course also be ISP’s).

In the last years though, the tech giants, and Google in particular, have been acquiring
or building undersea cables on their own. The result is that the cable infrastructure, the
backbone of the internet, is increasingly owned by Google, Facebook, Amazon and
Microsoft, just like everything else these days.

So how are these cables protected from physical threats?

The answer, surprisingly, is that they’re not. Considering their importance, the cables
are largely left alone, and when you think about it, the reason becomes clear: the cables
are not much thicker than a rope - the depth and vastness of the ocean provides ample
protection already. In simple terms: they’re damn hard to find. Near the shores, where
humans could pose a threat, the cables are covered in steel armor and buried beneath
the seafloor. From the perspective of those who want to protect the cables, the
challenge is the same: the ocean is too big and the cables are too long for anyone to be
able to guard them without setting up enormous protected zones that would severely
disrupt the world economy.

85
 The Ultimate Guide to Bubble Security

That being said, these points don’t suggest that there’s no risk of undersea internet
cables ever becoming a threat to the stability of the internet: the total number of cables
is only about 300, and cutting just a select few of them could theoretically disrupt the
internet service of entire countries. But as of now, there’s a capacity redundancy,
meaning that there’s more capacity than there is data: if one cable was to be damaged,
the data would simply be routed through a different one until repair could be done.

The edge networks: the CDN

When we look at how the big tech giants are buying up and building undersea cables,
you might ask yourself: why does a behemoth like Netflix not do the same? Logically, it
makes perfect sense: they have more than 200 million subscribers, $24.9 billion in
revenue in 2020 and eat up a staggering 37% of US Internet traffic. It is definitely in
their interest to secure stable bandwidth that can prioritize their own traffic over that
of a competitor. Still there’s no sign of them making that investment. Why? There’s one
more variable in this equation: Content Delivery Networks (CDN’s)

Think about it: the reason we build global cable networks that cross oceans, is to move
data from one place on earth to another. After all, the speed of light is not infinite –
there will always be a slight delay, and there's a limit to how much data one cable can
carry. Couldn’t we just move the data source (server) closer to the recipient (User’s
device)?

86
 The Ultimate Guide to Bubble Security

This is where CDN’s come in. The idea behind a Content Delivery Network is that you
duplicate the content your users need, and spread it out on servers all over the world. If
a User in Australia wants to stream video hosted by a company in California, they can
download the data stream from a server in their own country instead of sending it
across half the world. Not only does this mean the data travels a shorter distance and
reaches the User faster, it also means that we avoid putting an enormous amount of
strain on the undersea cables. If 1,000 people were streaming Netflix at the same time,
the same data would have to be transferred multiplied by 1,000, whereas syncing the
content from one server to another only needs to be done once, minimizing the global
bandwidth usage.

But this presents certain challenges: Netflix can do this because the content is static. An
episode of Stranger Things is not likely to change after its release, at least not
frequently. But what about data that’s subject to frequent changes – data that’s
dynamic? Things like…. say… the content of a database? The database is in itself a file
resting on a server, and this file is subject to change frequently: up to thousands of
times per second or more if your app is big enough. Naturally, keeping this in sync
across thousands of servers across the world is impossible - for every new update that’s
sent, hundreds of things have already changed on separate servers and would need to
be synced again. There’s just no way it could be kept reliably up to date.

87
 The Ultimate Guide to Bubble Security

This is why Bubble uses a CDN network for some things, but not others. In other words,
you are relying not only on the security of Amazon’s AWS server infrastructure, but also
on a third party called CloudFlare.

So what kind of content is on AWS, and what is on the CloudFlare CDN? Generally, it
helps to think about what we discussed earlier: dynamic content needs to be stored
with Amazon (where Bubble’s engine also runs), and static content can be synced
across the CDN.

The list below gives an idea of how this looks in real life:

The Bubble engine (which operates the Files (images, fonts, uploaded files)
database, generates page html and
makes server-side calculations)

The database (the file which contains all Bubble’s code base (the engine that runs
the data types, fields and content of your your app on the User’s device, including
app) CSS style sheets, translation texts and
Option Sets)

So when we ask the question of what kind of hardware is involved in the operation of
your app, the answer becomes: it depends on what kind of data we’re talking about.

88
 The Ultimate Guide to Bubble Security

While this may sound somewhat daunting and confusing to keep track of, it doesn’t
change things much in reality; Cloudflare, like Amazon, is one of the biggest CDN
providers worldwide. At the time of writing they own and operate all their server
equipment themselves, spread out over 23 locations globally. It’s true that Amazon has
been able to leverage their enormous scale and financial muscles to take their security
one step further (such as developing their own hardware), while Cloudflare has to rely
on third parties to manufacture the hardware components. Still, as one of the major
CDN’s and with companies like Lyft, Medium.com, Tinder and Udemy on their client
list, they cannot afford to take security lightly. The chance of a physical break-in
revealing your Bubble app’s codebase and user files is theoretically possible, but highly
unlikely. The argument could easily be made that it will be very difficult for you to
create an app at all if you can’t accept that risk.

The final stop: the User’s device

The final variable in the hardware equation is of course the User’s device. Luckily, from
a hardware point of view, this one’s out of your hands. Every measure you take to keep
your app’s data safe is based on how you build the software, not how the hardware of
the User’s device is set up.

89
 The Ultimate Guide to Bubble Security

Still, it makes sense to take a short break here and include the User’s device as an
example on how to think about security: as we discussed earlier, hacking is just one way
of gaining access to private data. How will your Users be using your app, and how can
that put them at risk?

We’ll get back to how design choices can greatly affect the security of your app in the
section about Designing for Security.

90
The Ultimate Guide to Bubble Security

Software

91
 The Ultimate Guide to Bubble Security

Ok, so we’ve picked a spot for our server where it won’t be buried in rubble after an
earthquake. We’ve connected to a self-sustaining power supply and cooling system.
We’ve hired all the guards we need and set up a perimeter of cameras, locked doors
and motion detectors. We’ve dragged cables across the oceans and clad them in armor
to protect the data before it reaches its final destination.

Now what?

Well, I know your fingers are itching to open the Bubble editor and get behind the
wheel, but we’re gonna stick with theory for just a short while longer. As we discussed
in the book opening, Bubble takes care of most of the security for you as long as you set
up your app in the right way. Let’s have a look at what that means.

Vulnerability testing
As we’ve briefly touched upon earlier in the book, security is not done once. It’s a
continuous effort as the world of technology evolves. Vulnerability testing, as the name
suggests, is an ongoing process of testing a piece of software for known vulnerabilities.

The Open Web Application Security Project (better known as OWASP) is an

international non-profit organization dedicated to web application security. They
maintain a regularly updated document called the OWASP Top 10 that aims to raise

92
 The Ultimate Guide to Bubble Security

awareness about application security by identifying the ten most critical risks and
vulnerabilities. Bubble uses this (and other sources) to run continuous testing and
patching and stay on top of current threats.

Understanding encryption
It’s hard to talk about data security for even one minute without bringing up the word
encryption. As a computer user savvy enough to take on building apps in Bubble, you
probably know a little bit about what encryption is and how it works, but in the interest
of clearing up misunderstandings, let’s have a look at it.

In simple terms, encryption is the process of converting any kind of information into a
secret code that only someone with the right key can turn back into its original form.
The original, readable information is known as plaintext, while the encrypted data is
called ciphertext.

The primary purpose of using encryption is to protect the confidentiality of digital data
both when it’s stored (at rest on the server) and when it’s traveling over a network such
as the internet (in transit). But that’s not all encryption is - it also secures data storage
and integrity in other ways.

93
 The Ultimate Guide to Bubble Security

Public and private keys

Cryptography, or any kind of encoded communication, consists of two phases:
encryption and decryption. You encrypt something before you send it, and the
recipient decrypts it before they can read it.

This is done in a process involving a public and a private key. The public key you can
safely share with anyone, but the private key needs to be kept absolutely secret if the
encryption is to remain secure. These keys are mathematically linked so that one of the
keys can be used to decrypt a message encrypted with the other, but they cannot be
derived from each other.

This is the steps of the process:

1. You provide me your public key

2. I use that key to encrypt the message I want to send you
3. You decrypt the message using your private key, which is the only way to decrypt
data encrypted with your personal public key

Using encryption with the logic of public and private keys we get a feature set that not
only scrambles data, but it means we can use the private key to sign the information as
a trusted sender and we know that its integrity remains intact until it reaches its

94
 The Ultimate Guide to Bubble Security

recipient. The list below are not really features of encryption keys and signatures, but
simply logical conclusions to be drawn from how they work:

- It encodes data to make it unreadable (as we’ve discussed)

- It can authenticate the origin of the data, confirming that it comes from the
right source (since it was signed with the private key that no one else has)
- It protects the integrity of the data, making sure that the message has not been
changed since it was sent (since that would require decrypting it, changing it
and then encrypting it again)
- It prevents senders from denying they sent the message through
nonrepudiation (again, since no one without the right key could have encrypted
it)

In other words, with encryption and signatures, you know that the information is
private, where it came from and that it hasn’t changed along the way. As a result, its
source cannot claim to not have sent it, unless they’re ready to admit that their
encryption key has been compromised.

95
 The Ultimate Guide to Bubble Security

Data in Transit: Understanding network protocols and

TLS/SSL
You’ve probably heard of this one too: SSL, or Secure Sockets Layer. Now throw SSL out
of your vocabulary, because a client focused on security will not be impressed listening
to you talk about deprecated security protocols. Let me explain.

SSL still tends to hang around in daily tech speech, but it has been replaced almost
entirely by TLS (Transport Layer Security). In your everyday work, the difference
between SSL and TLS is not noticeable. They’re both encryption protocols and TLS is
simply the newer one. Unlike SSL it’s still being updated, and SSL is known today to
have major security holes - which is why it’s more or less not used anywhere. You may
have heard about the POODLE attack vulnerability.

No, not this one.

96
 The Ultimate Guide to Bubble Security

This was (and still is in SSL) a known security hole that lets an intruder steal
confidential data like passwords and session cookies during transit, which can then be
used to impersonate the user. Interestingly, the Acunetix 2020 Web Application
Vulnerability Report revealed that as much as 3.9% of web servers are still vulnerable to
POODLE, more than twenty years after TLS was introduced. Bubble is not among them.

Before we dive into TLS, let’s clear up the term network protocol. A network protocol is
really just a fancy way of saying that we have a set of rules that determine how data is
transmitted between two devices. You can compare this to trying to connect an
old-fashioned USB Type A cable into a device that only supports USB-C. Even if they
both contain electricity and carry data, you quickly realize that the cable you have is not
going to help you out here (and you’ll need to open the dreaded drawer where you’ve
been collecting different cables since 1998 in the hope that they’d come in handy
someday. Yeah, good luck with that treasure hunt).

In any kind of data transfer, you have a sender and a receiver - and they both need to
agree on a common format for that exchange to work. In its most basic form, protocols
define exactly what type of electrical signal represents a one and what type of signal
represents a zero, which makes up the basis for all computing. In more advanced forms,
it lets you view web pages, send emails and connect Zoom calls (and lots of other
things of course). It makes sense, right? Sending video data to an email service would

97
 The Ultimate Guide to Bubble Security

result in a very weird looking email, and transferring the content of an email to Zoom
would result in a disappointing video conversation.

These formats are what’s called network protocols, and you’ll probably recognize
several abbreviations used all over the web:

- HTTP (Hypertext Transfer Protocol) - is a standard for sending information

related to web sites, such as HTML. Whenever your browser downloads a
website and renders it for you on the screen, the data has been exchanged in this
format.
- IP (Internet Protocol) - is what’s known as an addressing protocol. You know it
of course from the term IP address, which is a unique address that identifies a
specific device on the internet or a local area network. IP is often used together
with…
- TCP - you may not recognize it on its own, but it may look more familiar when
hooked up to its sibling: TCP/IP. IP is the part that obtains the address to which
data is sent. TCP is responsible for data delivery once that IP address has been
found.
- (VoIP) Voice Over Internet Protocol, as the name suggests, is used to make calls
over the internet. There are multiple protocols in this standard, such as WebRTC,
used by Google Meet, Facebook Messenger and many other apps.

98
 The Ultimate Guide to Bubble Security

This is not an exhaustive list by any means, but looking at these examples, it’s easy to
see that protocols are different ways of sending data that serve a specific purpose:
viewing a web page, sending an email, uploading files and talking to aunt Mildred on
your iPad. Now let’s return to TLS. When we mentioned HTTP, you may have
remembered that you usually see HTTPS these days. This is the same old HTTP
protocol, except that a layer of encryption has been placed on top of it. This layer is
what’s called TLS. You’ll recognize in your browser’s URL bar that the TLS layer is
applied: in all major browsers it will show a small padlock symbol next to the URL, and
the URL will contain https:// in front of it.

So, HTTPS is simply the secure version of HTTP: instead of sending the data as
plaintext, we’re sending it as ciphertext. In the earlier days of the internet, this was an
important piece of technology applied to online services such as banks, where
unencrypted data transfer was simply not an option. Over time, as the focus on privacy
and security has increased in general, you’ll rarely find websites that don’t encrypt the
connection - indeed, major search engines like Google will punish your SEO score if you
don’t use encryption because they believe it’s not in the best interest of their users to
show search results that put the user at risk.

To see the details about the kind of encryption algorithms Bubble uses for
data in transit, as well as all other details from Bubble.io’s SSL Certificate, you

99
 The Ultimate Guide to Bubble Security

can check Qualys SSL Labs report for the domain here.

TLS not only encrypts the content of the page you are viewing, but all its accompanying
assets such as images, javascript files, css and uploaded documents. Additionally, even
the URL itself is scrambled, meaning that while you visit an encrypted website, your ISP
can see which domain you are visiting (because they’ll know the IP address), but they
won’t be able to see anything coming after that, like folder/pages and URL parameters.
Visually, you can see it this way:

Your ISP can see the domain, but not the full URL or the content of what you’re viewing as illustrated with
pixelation here.

100
 The Ultimate Guide to Bubble Security

As we discussed earlier, encryption not only scrambles the content - we also use it to
authenticate that the sender is who they claim to be. If two people are communicating,
they can simply exchange the public key with each other and they’re good to go. For
servers and computers, a problem can arise: since the two devices have never
communicated before, how can you trust that the server is sending you the correct
public key? The answer lies in Certificates. This is basically a digitally signed document
that confirms that the server is really who they say they are.

Let’s go over a quick scenario to see how that process works:

1. A new User tries to access your Bubble app using a web browser
2. The Bubble server sends your computer its Certificate, which includes the
server’s public key. This certificate is digitally signed by a Certificate Authority
3. Your computer then checks the digital signature using the Certificate Authority’s
public key - remember, keys can decrypt both ways, so this let’s us safely verify
the authenticity of the signature

You can see this Authority kind of like a lawyer - a neutral third party that can act as an
intermediary and guarantor between two other parties. It’s actually not one authority,
but a list of entities that have been approved by browsers and operating systems as a
trusted issuer. In other words, the public key used to verify the SSL certificate’s
signature was already stored in the User’s browser before he ever visited your Bubble
app.

101
 The Ultimate Guide to Bubble Security

So who is the Certificate Authority for Bubble’s servers? Why, it’s an old friend of ours
from the previous chapter: Cloudflare. Small world, eh?

If you’re interested in learning more about SSL Certificate Authorities and see
an up-to-date list of the biggest providers, you can check out this Wikipedia
Article. You can learn more about Cloudflare’s SSL service here.

Applying TLS in your Bubble app

Like many of the necessary security measures you would need in a web app, Bubble
pretty much takes care of this for you out of the box.

Before you connect your app to a domain, TLS is activated whether you want to or not.
When you decide to connect a custom domain, TLS will be activated by default. You can
manage this setting under Settings -> Domain/Email after you have connected the
domain and verified that it’s working.

102
 The Ultimate Guide to Bubble Security

Data at Rest: Encrypting the database

So far, we’ve talked about how Bubble handles data in transit – when it’s moving
between devices. When the data is stored in the database, you’ll recall it’s at rest.
Encryption is applied to make sure anyone who might get access to the database can
only see scrambled data. The same encryption is applied to every backup and snapshot
of that same database, as well as when the data is in transit between different AWS
servers.

Bubble’s database uses PostgreSQL running on Amazon’s Relational Database Service

(RDS). RDS uses the industry standard AES-256 encryption. Ok, so that’s a handful of
techie sounding terms right there, let’s quickly go over them.

PostgreSQL is an open source database management system. It started out as a project

at the University of California, Berkeley and has been in development for more than 30
years, and is one of the most widely used systems on the internet. What this means in
practice is that Bubble have not invented their own database technology, but are
relying on an existing, well-tested and frequently updated framework. This also
ensures that Bubble databases are compliant with the SQL standard (which makes it
easy for your app to communicate with other SQL databases, since they speak the same
language).

103
 The Ultimate Guide to Bubble Security

Amazon RDS is the part of AWS that lets you (or Bubble in this case) set up, manage
and scale a database in the AWS cloud. It doesn’t mean that the database is fully
managed by Amazon, but that they take care of a lot of tedious tasks like server
maintenance, backups, software patching of the operating system and database,
uptime and error/failure detection.

AES-256 is an acronym for Advanced Encryption Standards (we’ll get back to the
number in a second). To understand how this algorithm has become the standard in
encryption, it’s helpful to know about its history. In the 70’s IBM developed an
encryption algorithm called Data Encryption Standards (DES) to protect information
stored on the newly invented, highly promising computers. The algorithm was
accepted as the standard and kept in development for more than 20 years, until
security experts started to recognize that hardware was getting ahead of the
encryption algorithm - faster processing made it possible to break the key. The
Electronic Frontier Foundation, in collaboration with other groups, worked in 1999 to do
exactly that, and were able to in little more than 22 hours. Clearly, DES was not enough
to keep data private anymore, and was in dire need of an upgrade.

The National Institute of Standards and Technology (Part of the U.S. Department of
Commerce) worked with security experts and organizations in developing and testing a
range of different algorithms. Security was of course a core priority, but versatility and
speed were also considered to make sure the algorithm would be met with open arms

104
 The Ultimate Guide to Bubble Security

in a wide range of industries when it was introduced. The expert panel landed on the
AES algorithm, and the US was confident enough in their decision for the NSA to start
using it to protect their highly sensitive data. Since then governments and military
organizations all over the world have embraced AES.

As of the time of writing this, the AES algorithm has never been broken in the way that
DES was broken in 1999, and experts estimate that a properly set up encryption could
take billions of years to crack using today’s technology.

The number 256 is the key length of the encryption algorithm. To simplify, the key is
similar to a password in some ways, but not others. A password is a short combination
of characters that you can remember and type in whenever you need it. An encryption
key is a collection of characters way too long to remember on your own, usually
randomly generated bits. In the case of Bubble’s database, the key is 256 bits long.
What does that tell us about how hard it is to crack? It’s actually fairly easy to calculate:
if a key is n bits long, then there are two to the nth power (2n) possible key
combinations. In other words, if the key is one single bit long, there are only two
possible keys - 0 or 1. However, with a length of 256 bits, the number of possible keys
rises to 2256 – that’s
11579208923731619542357098500868790785326998466564056403945758400791312963
9936 different possible keys, or about 1077. And yes, that number actually has a name if
you want to drop these facts into a conversation. Don’t worry, it’s easy to remember: 115

105
 The Ultimate Guide to Bubble Security

quattuorvigintillion 792 trevigintillion 89 duovigintillion 237 unvigintillion 316

vigintillion 195 novemdecillion 423 octodecillion 570 septendecillion 985 sexdecillion 8
quindecillion 687 quattuordecillion 907 tredecillion 853 duodecillion 269 undecillion
984 decillion 665 nonillion 640 octillion 564 septillion 39 sextillion 457 quintillion 584
quadrillion 7 trillion 913 billion 129 million 639 thousand 936.

You can forget about the old comparison of sand particles on earth – we’re talking
about a number that nearly matches the number of atoms in the observable universe
(1080). This number is so mind-bogglingly enormous that any randomly generated
sequence of bits of this length having been seen by anyone before is a statistical
impossibility, and the minute you delete it, no one will ever see it again. Now
remember, we’re not talking about the length of the actual key here: we’re talking
about the total number of possible combinations of bits (one’s and zero’s) that a key of
256 characters gives us. If not, the key itself would be too big to store on any hard drive.

We’re seeing a similar pattern here from previous chapters: a lot of decisions have been
made for you before you ever open up the Bubble editor, and they are on par with what
NSA, world governments and the world’s most secretive organizations are using. Much
more secure in fact, than what your app would likely ever need.

What about quantum computers and all the rumors of cryptography being worthless in
the future? Well, as of now, that future isn’t here yet - and the good thing about being

106
 The Ultimate Guide to Bubble Security

signed up to an enormous business like Amazon AWS is that the arm’s race goes both
ways. As new ways to crack existing algorithms come up, so do new ways of keeping the
data safe. As you probably have guessed by now, both the hardware and software parts
of hosting your Bubble app are taken care of.

Data is stolen not because of the encryption not holding up, but because of human
error in some part of the system. Of course, data has to be decrypted at some point to
be useful, and it’s in these instances that data gets stolen - not while at rest on the AWS
hard drive.

This is where you come in. The security weaknesses in your app are likely not caused by
hardware being stolen and weak encryption algorithms - they’re caused by apps not
being set up to keep the data secure.

Backups and recovery

All data that goes into your Bubble application is continually backed up on AWS
servers. Backups are split into two sections: the content of your database and the app
itself (changes that you make in the Bubble editor). The two are handled separately,
meaning you can restore the content of one of them without affecting the other.

107
 The Ultimate Guide to Bubble Security

Database backups
Your database is split into two completely independent and separate instances: the
development version and the live version. Making changes or restoring one of them
does not affect the other.

Continuous backups and point-in-time recovery (PITR)

For every change that happens in your database your work is backed up.
Point-in-time-recovery means that you can revert its data to any point in time in the
past, going back as far as 365 days if your Bubble plan allows it.

Using the point-in-time-recovery method, you choose which database to recover

(development or live) and also whether to restore all data types or just one.

108
 The Ultimate Guide to Bubble Security

The Copy and Restore Database found in the Data Tab of the Bubble editor also lets you
copy the contents of one database to the other.

Application backups
Backups of your application works much in the same way as the database, but offers an
additional option to make it easier to set a specific point you want to return to.

Continuous backups and point-in-time recovery (PITR)

Just like the database, any change that you make to your app is backed up, down to
moving an element just a single pixel.

109
 The Ultimate Guide to Bubble Security

Simply select a date and time to go back to, and Bubble will spend a few seconds
restoring to that version. After a page reload, you’ll find your app exactly as it was at
that point in time.

Snapshot backups

To make it easier to stay on top of exactly what version you want to revert to, Bubble
also offers Snapshot backups. Technically, these are the same as the point-in-time
backup, but it lets you save the state of your app at a given time and name it. This is
useful in cases where you start working on something that you may have to revert back
to later. Simply set up the save point, make any changes that you want, and if you find
yourself going in the wrong direction you can simply revert back to the starting point.

Setting up a save point lets you easily revert the state of your app back to the starting point.

110
 The Ultimate Guide to Bubble Security

Passwords
Bubble uses one-way hashing and salting to store passwords. What this means in
practice is that if someone should gain access to the Bubble database somehow, the
hashed password cannot be reversed back to its original state: it remains safe no
matter who gets ahold of it.

Passwords are checked by taking the password the User types upon login, hashing it
and see if that matches the hashed password stored in the database. You can see it in
this way: Bubble only cares that the password matches: not what the password is. This
means that even the Bubble team has no access to the original string. One-way hashing
is considered the best practice for password storage.

111
The Ultimate Guide to Bubble Security

Bubble

112
 The Ultimate Guide to Bubble Security

Ok, so we know a great deal more now about how Bubble’s security works behind the
stage. Both the hardware and software side are set up to be secure in ways that would
be almost impossible to rival even for bigger companies. The centralization of security,
hardware and services has put incredible resources into the world at a low cost, and
Bubble is in many ways the final part of the equation - it's a doorway to leverage that
power in your own ambitious projects.

It's also where your decisions start to matter - everything we've talked about so far is out
of your hands. You can't choose to soften security at AWS's server parks or shorten the
TLS encryption key - those decisions are made on your behalf. But you do get to choose
what information leaves that server, and who can make changes to it.

Let's first look at the single biggest vulnerable point.

Securing your Bubble account

Basic as it may feel, let me first give you a stern reminder: there’s no bigger threat to
your app than direct access to your Bubble account. This is the one point that can
render every other security measure worthless.

A lost/cracked password means someone can freely make changes to any app
associated with your account. They can read, download, change and delete the

113
 The Ultimate Guide to Bubble Security

database. Re-route Stripe payments. Delete the app entirely and permanently. And
Bubble being what it is, it's not even hard. It will take mere minutes to do enough
damage to ruin your business. Armed guards, encryption passphrases with possible key
combinations in the quattuorvigintillions and iron-clad cables can’t keep you safe if you
give intruders the key to the front door.

If you're running your own app business, that risk is something you need to take
seriously. If you're working with clients, a lack of thoughtful security on this point is
unprofessional bordering on reckless.

Access to your account needs to be protected with a long, strong password and
two-factor authentication.

Setting a password

You wouldn't be alone in forgetting to adhere to a strict password policy. While

ransomware is the biggest threat to companies in today's online landscape, weak or
compromised passwords are the primary means of accessing a system to deploy that
malware. System admins, managers and staff set weak passwords, type them out
visibly in a public place, share them in insecure channels and yell them to each other
over the phone.

114
 The Ultimate Guide to Bubble Security

37% of intrusions and malware in the US involved a stolen or breached

password. The dark web contains a whopping 15 billion sets of user ID’s and
passwords stolen from more than 100,000 separate data breaches.

Passwords are the best and worst invention to date to protect your privacy: best
because they do work. They’re usually easily remembered and you don’t need to know
anything about encryption and algorithms for them to keep your stuff private. They just
do the job. They’re the worst because we’re inherently very bad at being creative when
we come up with a passphrase. We tend to use short phrases, spiced up with easily
identifiable details like the names and birth dates of our loved ones or even more
general things like 123456, password or querty.

What makes a good password? Well, there’s the technical standpoint and the
psychological standpoint.

From a technical standpoint, longer passwords are better. A long, generic passphrase is
harder to crack than a short, complex one. Remember the numbers we talked about in
the section about TLS: adding a few more characters to your password drastically
increases the number of possible combinations.

115
 The Ultimate Guide to Bubble Security

The psychological part needs to be taken into consideration when you set a password
policy both for yourself and for other users.
● If forced to come up with a complex password, we tend to take an easy password
and simply add some characters to it, like our birthday or 1234, and we end up
with a horrible password like password1234.
○ The same happens when we’re forced to come up with a new password at
regular intervals: we make slight changes to the one we already have with
well-used strategies that hackers are very much aware of. Avoid
dictionary words, names and non-random number sequences.
● Original words and phrases we come up with are usually not as unique as we
think: you’ll find a list of the 100,000 most used passwords on Github. Use that
as a deny list. You’ll probably find several of your old passwords there – don’t
ever use them again.
● We also tend to re-use the same password across multiple sites and services -
your Bubble account is way too important for that - you need it to be unique

You can’t really blame people for being horrible password managers: we have simply
not evolved to come up with and remember long lists of complex phrases. Every service
under the sun requires a password these days, and all of us juggle up to hundreds of
these, ranging from online accounts to debit card and phone pin codes.

116
 The Ultimate Guide to Bubble Security

Optimally, all of your passwords should be random and unique, but in real life, this is
more or less impossible even to consider without a system to keep track of it. A
password vault like 1Password is your best option. 1Password will help you generate
long, complex, random strings that you can store encrypted and sync between devices,
lowering the number of passwords you need to remember to one. A 12, 16 or even 24
character password – it makes no difference if you don’t need to remember it.

To stay on the safe side, your password should be a minimum of 12 characters long,
containing letters, numbers and characters. That gives you a little over three sextillion
possible combinations (that’s a three followed by 21 zeros).

To again illustrate the difference password length makes, let’s assume you set an
8-character password. That gives you roughly 221 trillion possible combinations, which
may sound like a lot. But for a hacker assisted by a botnet (using thousands of hacked
computers all over the web to provide computing power), getting through 10 billion
password combinations per second is not impossible. This means your password could
theoretically be cracked in the span of a few hours. Adding just 4 characters to it
extends that time to several hundred years using today’s technology.

You'll probably find voices on Twitter basking in the feeling of superior intelligence as
they throw numbers at you pointing out the ridiculous computation needed to crack
even a 10-character password, and the superfluousness of going to 16 or 24 characters.

117
 The Ultimate Guide to Bubble Security

Ignore them. The logic is simple: is a 24-character phrase harder to break than a
10-character phrase? Of course it is. Is a 24-character password more cumbersome to
paste or autofill from a password manager than a 10-character one? Of course not. So
just go ahead and set it - why waste time discussing it when the answer to a sound
password policy is right in front of you.

Two-factor authentication

Repeat after me: there’s no reason not to not to use two-factor authentication. The
simple method of using more than just a password to access your account drastically
reduces the risk of someone gaining access to it.

Two-factor authentication, in case you don't know, is the method of requiring an

additional piece of evidence before you're given access to your account. After providing
your password, you will be asked to use the Google Authenticator or Authy app to
provide an additional key. Since this key is only available on a device that you control
(usually your cell phone), it adds an extra, important layer of security on top of your
password. Enable it today.

Set a policy for your team and clients

OK, so your account is set up and secure. Keep in mind that your new policy needs to be
applied to everyone who has access. Get your team members on board and enforce a

118
 The Ultimate Guide to Bubble Security

password strategy and two-factor authentication for everyone. Your chain is only as
strong as its weakest link.

If you're working with clients, see it as part of your job to ensure that they maintain the
same level of security as you do. They hired you for a reason, don't take for granted that
they're aware of how much damage can be done with a single lost or weak password.
Be a good consultant. Advice them to use a password manager and long, randomly
generated strings.

Application rights

One single setting can make your application viewable and even editable by every
person on the planet with an internet connection: your application rights.

This setting is found under Settings/General and is disabled by default, but is sometimes
activated when a developer needs help from someone to debug their application or
solve a problem. You should strongly consider adding any outside developer as a

119
 The Ultimate Guide to Bubble Security

collaborator instead of opening up the app for the whole world, and make sure to have
a very strict policy for deactivating this setting as soon as it’s no longer needed.

Keep track of collaborators

Adding collaborators is the second point where an action that takes mere seconds to
perform can render every other security measure useless. Adding the wrong person is
usually not the issue - it's the keeping them around that puts apps at unnecessary risk.

Usually, you're very much aware of why and when you're adding a person to the app. It
could be a freelancer hired to solve a specific problem, a coach who needs to know the
app to help you out in some way or a client's staff member.

There are three things you need to keep track of here:

● Only add Collaborators that actually need access to your app. Don't add them
like CC's to an email. Keep in mind the level of control you're actually potentially
giving them.
● Take Collaboration settings seriously: don't give them more control than they
need to solve your problem. If a freelancer makes changes to your app, you
should still consider being the one to review the changes and prepare the app
for deployment.

120
 The Ultimate Guide to Bubble Security

● There is usually no reason whatsoever that more than one person should have
access to your live database. Unless there is a very specific reason a Collaborator
can’t solve a problem without access to the live data, consider setting up a legal
arrangement like a Non-Disclosure Agreement to reduce the chance of data
misuse
● Have a system in place for keeping track of them afterwards: forgetting to
remove collaborators is incredibly common and opens up your platform to
completely unnecessary risk

The Bubble database editor

Many apps that manage sensitive User data have a full section in their Privacy Policy
about what kind of access the app’s creators have. It’s not unusual that direct access to
the database is available only to a very limited number of staff members, and
sometimes even stricter protocols are in place, such as access logs, legal agreements
and access only with a verifier present.
Bubble comes with a built-in database editor that overrides privacy rules and any other
kind of security you’ve developed in your app. Many new developers quickly get used to
the idea that this is the fastest way to make changes. At least one user needs this access
of course; but if you are serious about maintaining your User’s privacy, you don’t want
to keep adding Users that have full database access to solve customer service issues or
perform some other administrative duty.

121
 The Ultimate Guide to Bubble Security

If you are indeed handling sensitive data, then your team members should be counted
amongst the different User types that you plan for the rest of your Users. Don’t allow
them to work directly with the Bubble editor, but set up administrative pages that only
they can access, just like you would for end-users with special access rights.

Respect your staff members just like you respect your end-users: no one can ever be
accused of mishandling data that they have no access to in the first place. In principle,
no one – including your own team – should have access to a byte more than they need
to keep the gears of your app running smoothly.

Naming your applications

Most developers when they create a new application, they’ll name it after the brand
they’re hoping to build, as long as that name is available. By doing this, you’re providing
a potential intruder with a small piece of information they can use: the URL of the
Bubble editor. While obfuscating this obviously shouldn’t count as an actual security
measure, let’s stick with the principle of not making it any easier than it needs to be to
obtain information that could potentially be used against you. A quick fix is to simply
assign some random characters to your app name, such as mybrand7381.

122
 The Ultimate Guide to Bubble Security

Protecting version-test
While access to the version-test of your app doesn’t necessarily constitute a major
security breach, it does come off as unprofessional. Imagine if you were able to access
the developer’s test version of a popular SaaS application complete with random
dummy data. Even if your data was not in there, it would erode the trust you have in
their ability to maintain their security.

You get the point. Your version-test should not be public.

Don’t forget to check the box marked in red to avoid locking your public app.

Protecting it is easy: simply set a username and password and check the box Only apply
in Development mode. You’ll find this under Settings and General. Bubble encourages a
very weak protection here, suggesting username and password as credentials. As earlier, I
recommend going with a password manager like 1Password: generate a random,
cryptographically secure string, save it there and never think about entering it again.

123
The Ultimate Guide to Bubble Security

Privacy Rules

124
 The Ultimate Guide to Bubble Security

Let’s open up this chapter with the most important point: Privacy Rules are the
foundation of your app’s security. As long as you use the database, your app is not
secure until Privacy Rules have been properly set up.

What are Privacy Rules?

Privacy rules are settings that you apply to specific Data Types in your database to
restrict who has access to it. A typical use case (but by no means the only one) is for
Users to only be able to see things that they themselves have created. If you create a
document in Google Drive or a note in Evernote for example, you’ll naturally assume
that not every other user of those products has access to your data. If they were Bubble
apps, privacy rules would be essential to keep that data private.

125
 The Ultimate Guide to Bubble Security

Using cloud-based software like Google Drive, we take it for granted that our documents are private and secure. Your users
expect the same from your app if you make that promise.

Privacy Rules are applied to all data server-side, meaning that the protected data never
leaves Bubble’s servers. They’re also applied across your entire app, ruling out the
possibility of data breaches because of human error.

Privacy Rules are also the way you protect your data from being accessed via your Data
API or API workflows: processes in which you may not have control over how the search
is constrained and Privacy Rules are your only way to protect your data.

As obvious as it may seem that these Rules are needed, no, required for all apps, it’s
alarming how often they’re simply overlooked. Even agency-built apps with live Users

126
 The Ultimate Guide to Bubble Security

sometimes expose everything from user data to Stripe secret keys in their User’s
browser - probably unbeknownst to both the developer and the client. If your Privacy
Rules have not been set up and properly tested, you have no business clicking the
Deploy button.

Why search constraints are not enough

Bubble’s Do a search for works behind the scenes as an API call. It authenticates the User
by checking the identity of the User making the search, and then authorizes that User
to have access to whatever the Privacy Rules allow.

What exactly does that mean from a security standpoint? It means that while a search
in isolation is secure (Bubble never sends more data than is specified in the search) the
database is not. If a hacker is able to place an API call with that User’s authentication to
the Bubble server without the constraints you have included, they will get access to
whatever data is available. In other words, without Privacy Rules, all data in your
database is public: it can't be said much clearer than this.

The basic editor structure

The basic structure of Privacy Rules consists of two questions:

1. How should this data be made available to see and edit for Users matching

specific criteria?

127
 The Ultimate Guide to Bubble Security

2. How should this data be made available to see and edit for everyone else?

Note here the words be made available to see and edit: the easiest way to think of
Privacy Rules is that they don’t restrict access – they grant it. In other words, you are
setting up your Rules in order to allow your users to see and edit data under specific
conditions.

A simple rule to keep in mind to avoid conflicting rules is that checked boxes override
unchecked ones. A checked checkbox grants access to anyone matching the criteria, but
an unchecked one doesn’t ungrant it. If that same box is checked on any other rule that
matches the current User, then that User will have access.

128
 The Ultimate Guide to Bubble Security

Setting up a Privacy Rule

After clicking the Define new Rule button, we’ll get to work on the different sections of
the rule in the order they’re listed on the screen. You’ll notice that adding the first rule
also creates the second one (everyone else) automatically.

Name

The name of the Privacy Rule is just for your own reference – give it any name you want.

When

This is where you set the condition for the rule. Conditions are built using Bubble’s
expression editor just like everywhere else, but you’ll notice that you can only access
two data points: the Thing you are adding the Privacy Rule to, and the Current User.

When setting up Privacy Rule conditions, you only have access to the Thing in question and the Current User.

Rather than thinking about the condition on the full list of Things you are protecting
(all users), think of it as a rule that’s applied to one User at a time. That way, Bubble’s

129
 The Ultimate Guide to Bubble Security

choice of words make perfect sense. Let’s set up a rule that specifies that This User is
the same as the currently logged in User. Take a look at the highlighted image below,
and how the editor is set up to be read as an easily understandable English sentence:

When This user is Current user, Users who match this rule can view all fields. It may not be
Shakespeare, but Bubble’s focus on humanly readable expressions make the privacy
rules easy to understand.

View all fields

This checkbox, as we explored earlier, determines whether all fields (name, email, etc)
on this User should be visible to Users who match our When criteria. If you uncheck this
box, you can select which fields are visible.

Find this in searches

This checkbox being checked tells Bubble that whenever a Do a search for is performed,
records that match the criteria will be included in the result. Note that unchecking this
box doesn’t hide the record in every other circumstance: as the name suggests it only
applies to searches. If you reference the record in some other way, it will still load.

130
 The Ultimate Guide to Bubble Security

View attached file

Let’s spend a little bit of time on this point, because it’s easy to misunderstand. Many
assume that if you set up a field on a User that contains an uploaded file, that file will
be protected by the View attached file setting. This is not the case.
This setting protects files that have been deliberately set to private when it was
uploaded with one of Bubble’s uploading plugins. It does not protect files that didn’t
have that box checked or were uploaded directly in the Bubble editor. For this setting to
work, you need to adjust some settings on the upload element. In the case below, we’re
using a PictureUploader element

131
 The Ultimate Guide to Bubble Security

The
View attached files rule only works if you’ve specifically set the file to private when it was uploaded – a
common misunderstanding.

Keep in mind that this setting protects the file – not the saved URL. The URL of the file
can still be exposed in DevTools, and potentially expose information that your users
don’t want it to. If you want to hide this information, you should also uncheck this field
by unchecking the View all fields and the field in question.

132
 The Ultimate Guide to Bubble Security

If anyone with the URL tries to view the uploaded file, they’ll see this error messag:

Allow auto-binding

This box determines whether Bubble allows for a field to be saved using the
Auto-binding feature. The rule is fairly self-explanatory, but it’s still important to read
exactly what it’s saying: it specifically allows or disallows auto-binding, not writing to
the Thing in general. This setting is one of the reasons we consider auto-binding as the
best practice way to save data: just like exposing data unintentionally in searches is
avoided app-wide by unchecking private fields, disallowing auto-binding makes you
completely sure that no one can edit a specific field without the right credentials.

Checking the box lets you pick which fields you want Users to be able to edit. If you
check a field to allow auto-binding, but uncheck it in the View fields settings, the User
will be able to edit that field, but not see it. In fact, any input field that is auto-bound
will accept the edit and then immediately hide the content after it’s saved.

Everyone else

When you set up a Privacy Rule, always go over the Everyone Else section to verify that
you don’t have any conflicting rules. Keep in mind that a checked checkbox overrides an
unchecked one: any box you have unchecked with a specific condition in the rule above
has no effect if that same box is checked under the Everyone else section.

133
 The Ultimate Guide to Bubble Security

Privacy Rules and workflows

Now you might ask: how are workflows affected by our new Privacy Rules? In general,
they aren’t. Any change that you make to a Thing in a workflow, even if the Current User
doesn’t have access to that field, will still be made.

Any change that you make to a Thing in a workflow will still be made, even if that field is not viewable by the
Current User.

134
 The Ultimate Guide to Bubble Security

Workflows are still affected in some ways, as they are run with the current logged in
User’s credentials. Again, keep an eye on the language that Bubble uses in the Privacy
Rule section: it’s saying that a User can’t see a field – it doesn’t say anywhere that he
can’t make changes to it (outside of auto-binding). In other words, if a workflow tries to
see a field or search for a Thing the Current User doesn’t have access to, the result will
turn up empty, which might affect the workflow.

This also applies the other way: if you limit a User's access to search for specific Things,
that rule will apply everywhere: even in workflows.

Security during submitting data via a workflow

Let’s say on page load that you’d like to Create a new Thing that is invisible to the
current User by use of Privacy Rules. You may for example be logging a timestamp for
when the user visits the page for analytical purposes. Remember that Privacy Rules
protect database records – not Workflows. The workflow will run on the client-side
page, and any data along with it will be available on the User’s device if they know
where to look for it.
In most cases this is not a problem – but if that information is somehow sensitive (like a
workflow generating a pin code or a password), then using an on-page workflow is not
secure. We’ll look into this in a later chapter.

135
 The Ultimate Guide to Bubble Security

Privacy Rules and APIs

Activating the Data API (we’ll get back to that one too in a later chapter) will open up
some new settings in the Privacy Rule editor.

As you can see in the above screenshot, Bubble provides granular settings for the Data
API, and they are self-explanatory. What is not as obvious is that these settings apply to
the Data API exclusively: any database modifications that you do in an API Workflow
will not be affected by these checkboxes.

Privacy Rules and refreshing page content

Bubble is very quick to update information on the screen as data changes in the
database, even if those changes were unrelated to the User currently viewing the page.
Privacy Rules are a bit different: they require a page reload before changes are visible. If
you are showing information in your app where you’d like changes to be visible
immediately, you can apply a separate condition on the search as well, basically
repeating the condition on the Privacy Rules. If changes are made in the database
affecting the User (such as changing the User’s Role), you can have those changes
reflected immediately.

136
 The Ultimate Guide to Bubble Security

Note that this does not suggest you should leave out the Privacy Rule: the on-page
condition is an additional filter. It does not actually add any extra security either, since
the original information has already been downloaded to the browser.

137
 The Ultimate Guide to Bubble Security

Page, Element and Workflow

Security

138
 The Ultimate Guide to Bubble Security

How to think about your UX and security

Before we start looking at specifics, let’s take one step back and try to get a general
understanding of app security. We’ll begin by digging a bit deeper into the relationship
between the server and the client.

Let's return to the illustration from earlier. Your app is an ongoing exchange of
commands and data between the server and the User's device. Generally, we've talked
about your data being safe during rest (when it's stored on the AWS servers) and during
transit (when it moves from the server to the User's device encrypted by TLS) - but how
safe is it once it reaches your user's device?

The answer is: not safe at all. But in most cases, this is exactly what we need. We of
course no longer want the information to be encrypted when viewed in the browser - it

139
 The Ultimate Guide to Bubble Security

would make it impossible to work with. We want all the information to be visible in
plaintext - what use would LinkedIn be if it displayed all your contacts as encrypted
strings of text or if you had to manually unencrypt every Gmail you received? Unless
you’re Edward Snowden, not much.

What's important for you as a developer to understand is that everything that happens
on your User's devices is potentially insecure, and you need to control the flow of
information and commands that go both ways. Many developers make the mistake of
assuming that as long as you're not showing something on screen, it's securely hidden -
it's not. Your browser downloads all the data, decrypts it and stores it as plaintext until
it's needed - and it's easily accessible through the browser's web tools.

To visualize what parts of your app are truly secure, and which are not, it helps to think
about it as illustrated below:

140
 The Ultimate Guide to Bubble Security

As you can see, everything that makes up a static part of your app - elements,
workflows, actions, conditions - are potentially viewable and manipulable by a User
who knows his way around DevTools and code. Everything stored in your database is
well-protected, provided you’ve secured it with Privacy Rules. In simple terms: your
database data is safe, your page data is not.

141
 The Ultimate Guide to Bubble Security

So what we need to build here is an understanding of when exactly data leaves the
server and reaches the browser - because once it reaches this point, it’s no longer
encrypted. As long as you're only downloading the data the current User should have
access to you're good to go. But there are many possible scenarios where you'll be
unknowingly instructing Bubble to send more data than you need and should. It looks
fine in your app’s design, but the information rests unencrypted just under the surface
and is easily accessible.

So, sending data to your User’s device can mean many things. Most readers will probably
jump straight to database searches, but keep in mind that Bubble is sending a lot of
other stuff to your device as well. Let’s have a look at what that includes:

The Bubble code base

It’s helpful to think of Bubble’s app engine as existing in two places: one is on the AWS
server, handling all your server requests. The other one is a set of JavaScript files
downloaded to your device that takes care of everything happening there (like
registering button clicks, hiding/showing stuff on the page and sending commands to
its twin on the server) These two are constantly communicating with each other to
keep your app running.

142
 The Ultimate Guide to Bubble Security

Bubble’s engine is two siblings managing the client and server and the communication
between the two. This is far from an exhaustive list.

The engine on your device consists of a set of core features that’s downloaded for every
app no matter how it’s designed - it’s simply needed for the app to function. In
principle, this code base doesn’t contain any sensitive information, but as you keep
adding data to your app, Bubble adds this info to the Javascript.

Option Sets

Option Sets are used in a range of different ways to store options and information. It's
also one of the most common ways for Bubble developers to inadvertently reveal secret
information. The most basic and important thing you need to know about Option Sets
is that they are not secure, and are not meant to be. Not only is all information stored in
Option Sets unencrypted, but it is also part of the code base that Bubble downloads on

143
 The Ultimate Guide to Bubble Security

all pages. In other words - all info saved in all Option Sets are downloaded on all pages
as plaintext JSON even if they're not used on that particular page.

Option Sets should never, under any circumstances be used to store information that
you're not comfortable sharing with every one of your app's Users. Do not use it for
storing important information like API keys, passwords or other private data.

Translation texts

The Translation texts (or app texts as they're referred to in the editor) that you find
under Settings - Languages are similar to Option Sets in that way: every string of text you
add is downloaded along with the Bubble code base and is available unencrypted. Few
developers store sensitive information here, but I have seen examples of developers
using translation text as a clever solution to store static data values to avoid using the
database (mostly before the Option Set feature was added). Don’t store anything in
these strings that’s not supposed to be public.

Elements

Static information stored in elements becomes a part of that page's code, even if the
element is not visible on screen during page load. This could be text in text elements,
button labels, tooltips, image URLs, links, YouTube video ID's - whatever's on the page
you should assume will be downloaded to the browser when the page is loaded - even
the names of the Elements themselves in the editor. It’s also worth noting that

144
 The Ultimate Guide to Bubble Security

Database Things that you set as a Group’s Data Source will be loaded on page load
(every field that’s not protected by Database Rules) – even if that group is hidden and
under the fold.

Workflows

Static information saved in workflows also becomes part of the Bubble Javascript
codebase and is visible in plaintext. Information generated in workflows can also be
exposed on the device as that information is passed to the server. In most cases this is
not a problem, but you need to be careful about what kind of information you store
there. We explore how this fact can open up a security hole in the section on Chrome
Developer Tools.

Page names

The list of all the pages in your app is also downloaded on page load. This is important
for two reasons: any information you store in the name of the page itself is visible - don't
give your pages any kind of sensitive name even if they're not meant to be seen by
Users. Secondly, don't assume that pages are hidden as long as you don't link to them -
since all page names are downloaded to the browser, a User can quickly identify URLs
that you intended to keep private or temporary. During development it's not unusual to
add temporary pages for testing or storing design elements - make sure to delete them
or convert them into reusable elements before deploying.

145
 The Ultimate Guide to Bubble Security

Data Type names

The names of your Data Types (i.e. User, Company, Project, etc) are also stored in the
Bubble code base, along with field names, type (text, number, etc) and default values.
While this doesn’t reveal the actual data stored in the database it does give a complete
overview of its structure. Every piece of information that a hacker has access to can
potentially open up for vulnerabilities, so be mindful of this. The fact that default
values are visible is especially important - don’t use this for anything that you don’t
want every User to have access to.

Current User information

Information about the current User is also downloaded. On page load, Bubble transfers
all the fields saved on the current User, within the constraints of your Privacy Rules.
There are many scenarios where a User shouldn’t be able to see all fields even on his
own profile, so don’t forget that it’s all loaded along with the page unless you tell
Bubble to hide it.

API Connector Calls

The API Calls that you set up in the API connector are stored in Bubble’s JavaScript files
and reveal the name of the call, the URL and the key name and value of all parameters
(unless they are set to Private). We’ll get back to how you set up the API Connector
securely in the chapter about API’s.

146
 The Ultimate Guide to Bubble Security

Optimize Application
Somewhat anonymously hidden under Settings/General and by scrolling all the way
down to the bottom of the page, you’ll find the Optimize Application button. On the
surface, this is a performance tool: get rid of unused data in your application and things
will become less clogged. And they do.

But - this is also an important part of preparing your application for deployment.
Whenever you delete certain things in your application – Data Types, fields, Option
Sets, Styles – you’ll notice that the information is not gone for good. By clicking Show
deleted types you can see a list of all your deleted Data Types and restore them as
needed. Mostly this is useful: it lets you work with data in your app safely, as you can
undo the changes later.

But this ghost data never leaves the codebase that Bubble deploys. In other words,
deleted data still carries over onto live applications when you deploy, hidden away in
Bubble’s Javascript files. Not only does that increase the size of the total download, it
can potentially still house information that you should not be sharing, such as data
stored in Option Sets.

Using the Application Optimizer button you can get rid of all remaining ghost data
from your editing process in one quick swipe. You may want to set up a Save point

147
 The Ultimate Guide to Bubble Security

before running it and test the app afterwards, as the optimizer is not 100% failsafe. But
make it part of your deployment routine to get rid of information that’s no longer
relevant for your application.

Searches
With the page download covered, let's dig into the part of the page that usually
handles the most sensitive information: database queries.

What exactly do we mean by Searches? Anytime you need some information to be

retrieved from the database, you'll perform what's called a query. The Bubble engine in
your browser sends this query to the server, which then performs the search and sends
the results back. This tells us an important thing: the server only ever sends you the
exact information that you asked for - not more. In other words, if you use the Do a
Search For command to search for Users with a specific last name, Bubble will only
return a list of the Users that match your constraint. Since we already know that data
saved on the server is safe and encrypted, this means we know that any results that
don't match our constraints are kept hidden away from sight and never reach the
browser.

You also get to pick the exact type of response that Bubble sends back. Whenever your
search is set up, the final part of your expression determines what kind of data the

148
 The Ultimate Guide to Bubble Security

server returns. As an example, let's tweak our search a little bit and add the :count
operator to it:

In this case you are not actually asking Bubble to return the list of Users - you're asking
for an integer (or a number). If that number is 5, then Bubble will simply return that
number - not the full list of all the five Users. So that count is made on the server, not on
your User’s device. Bubble has a handy tool that quickly tells you what kind of data any
given expression will return. Simply hover your mouse over any part of the expression,
and you'll see the resulting data format:

149
 The Ultimate Guide to Bubble Security

Hovering any part of an expression reveals what it evaluates to.

Knowing these two points, we can 1) set constraints for how Bubble filters our search
before the result is sent to the browser, and 2) pick the format of the response. In other
words, you as a developer have a high level of control over the data that reaches the
insecure state of resting in your User's device.

That being said, it’s easy to get misled at this point: since search constraints are indeed
applied on the server and Bubble only ever sends you the data you asked for – isn’t the
data then secure? In that particular search? Yes. But overall? No.

Data is secured by using Privacy Rules, and everything else is simply obfuscation. When
Bubble performs a database search, it sends an API call to the server. The call includes
the constraints you’ve picked and the response you want. Bubble only ever returns what
you ask for. But - you have an authenticated User on your hands. What if that User

150
 The Ultimate Guide to Bubble Security

places an API call to that same server, but without the constraints? The User will have
access to all data not protected by Privacy Rules. Search constraints are a feature
designed to let you download the exact data you need: it is not a security measure. As
long as the User is authorized in the Privacy Rules to access a piece of data in the
database, even if no searches you’ve set up makes that possible, a determined User will
be able to do so.

Searches vs lookups (and how the Unique ID is different from other

constraints)
To dig further into how searches work from a security perspective, we’ll pop the hood
for a few moments and look at what’s going on there. Whenever Bubble searches for
some data, it performs either a search or a lookup. Let’s see what the difference between
the two is:

A search is a query to the database in an attempt to find a list of records that match a
set of constraints, such as all Users that have the last name Amlie. You’ll always get a list
(or array) in return, even if that list contains only one record.

A lookup is the fetching of one specific record based on its unique identifier: in Bubble
this is the Unique ID field.As the name suggests and you probably know, the number is
truly unique: no other record in your database (even across data types) will ever have

151
 The Ultimate Guide to Bubble Security

the same number As such, a lookup will only ever return one result, and it will always be
the right one.

Why is this important to understand? Because not knowing it, you can unwittingly set
up vulnerabilities in your application, especially related to the writing of data.

When is a search used?

As you might have guessed, a search is used whenever…. Well, whenever you set up a
search. Even if you apply the :first item or another operator that technically returns only
one record, Bubble performs the search, gets a list of returns and then simply hands
you the first one - but under the hood, it’s still a search.

When is a lookup used?

A lookup is used in any scenario where Bubble knows an item’s unique ID. Since the
database is indexed by the Unique ID, a lookup is faster than a regular search and thus
this is the quickest way for Bubble to load data. In practice, this is what happens
whenever you reference a Thing directly by its ID (although you may not be aware of it),
such as saving a Thing in the field of another Thing (i.e. Current User’s Company), when
you use the Page Thing or when you reference a Thing in a URL parameter. If you are
saving a list of Things, technically you are simply saving a list of texts: the Thing’s
Unique ID’s.

152
 The Ultimate Guide to Bubble Security

What may surprise you is that if you set up a search (using the Do a Search for command)
and use a Unique ID as a constraint, Bubble automatically switches from a search to a
lookup.
Why is that important to know? Think about it for a couple of seconds before we go on…

The Unique ID trap

It all comes down to two simple details that are easily overlooked:

1) A search and a lookup is not the same thing: Privacy Rules protect searches
specifically – not lookups
2) All fields on a Thing can be protected by Privacy Rules; except for the Unique ID

Knowing that, what kind of consequences can we start to outline? Well, what this
actually means is that if you search for something by its Unique ID, you will always get a
result, even if the record is normally protected by Privacy Rules. Now that result may of
course just be a record with no visible fields: other privacy rules still apply after all. But
it opens up for some vulnerabilities that you as a developer need to be aware of.

153
 The Ultimate Guide to Bubble Security

The above search will always produce a result and thus the action will be successfully completed, unbeknownst
to many Bubble developers. Never rely on a Thing to be empty to keep it from being changed.

What happens, for example, if you set up an action that writes something to that
database record? Because you have set up your Privacy Rules to keep the record from
being found in a search, you may have a false sense of security that this is sufficient: the
action will not write anything, because there’s no record to be found. The pen is there,
but there’s no paper to write on, so to speak.

As we just saw, that’s not always the case though: if you reference a Thing directly by its
ID, Bubble will always find it, and any actions that are applied to that database record
will successfully complete. Setting up a search by Unique ID is a corner case of course –
but it’s not unheard of. And of course, any kind of lookup (Page Thing, URL Parameter,
Field on a Thing) will also produce a result regardless of privacy rules.

154
 The Ultimate Guide to Bubble Security

Let’s look at an example. Using URL parameters is a common way to both navigate an
app and load data. Take a look at the URL below:

https://www.myapp.com/admin?nav=edit-article&article=1645888439991x75946751622
0714101

If you want to learn more about using URL Parameters, you may be interested
in this guide. We also cover the different pros and cons of using URL
parameters vs custom states for navigation in this article.

From the logic of this step, we’re looking at a form to edit articles, and we’re loading the
article by its Unique ID. But what happens when a User that should not (according to
Privacy Rules) have access to that article pastes that URL into their browser? Well, the
form will seem empty (since the Privacy Rules are hiding all its field), but the record is
still loaded. Any condition that references the Thing (such as Parent Group’s article is
empty) will return a value that confirms the record is there, and any action (such as
Make changes to a Thing) will successfully write to the article.

So just how sensitive is the Unique ID? Does it open up to all kinds of shenanigans and
should be protected at all costs? Well, yes and no. This is a chicken-egg problem: any

155
 The Ultimate Guide to Bubble Security

User that shouldn’t have access to a Thing should in principle not know that the Thing
exists at all. The Do a search for protects things from being discovered, but it does not stop
them from being loaded if a hacker knows its direct index key (Unique ID).

What’s the solution then? Well, as long as your Privacy Rules are set up correctly, no one
should know that Unique ID to begin with, But there are cases where this could
happen: a User could share a URL with another User who doesn’t have the same access
level, or a User’s own access level could be downgraded (their role or permissions
changed). In that case, the solution is of course to protect your workflows just as
adamantly as Privacy Rules. While a User should never be able to see the Unique ID of
anything that they’re not supposed to have access to in the first place (never give a
hacker information to work on), there’s strictly speaking no security risk for Bubble to
load a Thing where all fields are empty: they’ll be able to confirm that a Thing with that
ID exists, but that’s it. Except if you’re not protecting your actions: if you place the right
condition on them, Bubble will check that condition on the server and stop the writing
from taking place.

156
 The Ultimate Guide to Bubble Security

Protecting the action with a condition like the one above properly protects it from unauthorized changes.

In the next section we’ll look closer into how these conditions work.

Workflows

Client-side vs server-side workflows

Workflows running on the page are visible to any User on that page and any kind of
data and server communication involved in the running of its actions are potentially
insecure. Like many other points in the book, this is not meant to say that you can never
use on-page workflows: mostly, exposing data on the User’s device is harmless, since
the information is often available anyway. If you set up a workflow to change the first

157
 The Ultimate Guide to Bubble Security

name of the Current Logged-in User, there’s of course no harm in the information
exchange between the client and the server being visible to that same User: as soon as
the information leaves their device, it’s encrypted securely. In fact, most on-page
workflows are completely safe to use, and the security concern only surfaces in the
edge cases where you do need to hide certain pieces of information from even the
person using the device. Secondly, for your app to function properly, you may
sometimes need to override your privacy rules during the running of a workflow.
Instead of relaxing your Privacy Rules in general, setting up your database to be
insecure, you can override the rules in just that one workflow.

Both scenarios require moving your workflows from the front-end (page) to the
back-end (server) by use of API workflows.

Scenario 1: hiding information in workflows

The first scenario where this may be a cause for concern is when a workflow includes or
generates information that the device User should never see. A classic example of this
is to generate a one-time password that is sent to the User via email or text message. If
this code is generated on the page a tech savvy User will be able to reveal it and enter
the correct passcode even without access to the communication the code is sent to.

158
 The Ultimate Guide to Bubble Security

By generating the passphrase in a backend workflow, the User has no access to how it is
generated. Setting up an API workflow to generate and send the code to the User hides
the whole process from the device.

We’re exploring this scenario more closely in the chapter on Chrome

Developer tools. Click here to read this section now.

Scenario 2: overriding Privacy Rules

The second scenario where on-page workflows can open up serious security holes is
whenever you need to override Privacy Rules. Setting up that Workflow in the backend
lets you use the Ignore privacy rules when running the workflow option to temporarily
override the rules in order to make the needed changes.

159
 The Ultimate Guide to Bubble Security

The setting above lets you override Privacy Rules in a single workflow on the server, where it is invisible to the
User. Instead of setting up insecure, relaxed privacy rules, you can use this setting to keep information secure
while still having the flexibility to work with secure data in specific workflows – and the User never even knows
it’s happening.

This is a relevant technique to use whenever you want to edit information that the
current User should not have access to (such as fields on another User). It can also be
used to save and read information even on the User itself. In scenario 1, we generated a
one-time code for the User. Naturally we need to store that code somewhere to be able
to verify it. Storing it on the User is perfectly acceptable - as long as that User cannot see
the field. It has to be protected by Privacy Rules.

To then actually verify the code, we need to use a backend workflow to override Privacy
Rules and check the code against what’s saved on the User’s hidden field. That way, we
both generate, save and verify the code on the server, completely hidden from the User.

Making changes to database data

All of Bubble’s core features revolve around its database: no matter how they look and
behave. All apps are essentially the same thing: clever ways to make a database look
pretty. Database operations are often described with the abbreviation CRUD: Create,
Read, Update, Delete.

160
 The Ultimate Guide to Bubble Security

In principle, these four words describe everything that you can do with a database, and
it’s up to you to make sure you protect each of these points from misuse. Let’s first look
at the tools we have at our disposal:

CRUD Bubble method Protect with

Create Action Condition

Read Search Privacy Rules

Update Auto-bind Privacy Rules

Update Action Condition

Delete Action Condition

As you can see, only Read and Update are possible to protect with Privacy Rules, for the
rest we need to rely on Conditions to ensure our Users are not able to Create or Delete
something they’re not authorized to.

Privacy Rules and actions

Editing records without read/auto-bind access

So here’s a question for you: if a Privacy Rule prohibits the Current User from viewing a
specific field on a Thing – will that User still be able to make changes to that field? The
answer is yes. Again, Privacy Rules do exactly what they say they do: they can stop a
field from being viewed, but you can manipulate that field with an action as much as

161
 The Ultimate Guide to Bubble Security

you like. The same goes for auto-binding: it will prohibit an auto-bound field from ever
sending the changes to the server, but it will not stop an action from making a change
to that same field.

Creating or deleting records without read/auto-bind access

Just like Making Changes to a Thing, Privacy Rules do not affect an Action’s ability to
Create or Delete a new Thing. To ensure unauthorized Users can’t take this action, you’ll
need to use Conditions on the Workflow or Action itself to stop it from running
altogether.

Using Privacy Rules-protected search results in an Action

Ok, so what if an action needs to perform a search in order to finish? Again, expect the
Privacy Rule to behave exactly like it says: it doesn’t matter where the Do a Search For is
performed (in an Action, Condition or Data Source) – if you’ve set up your Privacy Rules
to stop that from happening, it applies everywhere.

Why you should use auto-binding to edit data

You have likely guessed the reason by now: Input Elements that are auto-bound are
protected by Privacy Rules. Anyone who tries to edit a protected field will simply get an
error message (Sorry, you do not have permission to modify this), and the action is stopped
on a server level. Input fields can be protected in other ways but that opens up for the
developer to make a mistake or forget something during the creation or maintenance

162
 The Ultimate Guide to Bubble Security

of the app. As long as Privacy Rules are in place, mistakes can’t be made. It gives you a
lot less to look over before deploying the app to Live.

Does this mean that a Save button should never be used? No, a condition on the
Workflow or Action of a button will also safely stop it from running. There can be
perfectly valid reasons for why you don’t want all input fields to make changes to a
Thing immediately and your UX decisions can overrule the best practice of using
auto-bind. But if you’re not sure which method you want to use; go with auto-bind.

Conditions
As part of your app’s UX, you’ll often want to hide/show or disable elements based on
specific conditions such as the User’s Role/Permission. Usually this is done with the use
of Conditions placed directly on an Element that leads to a change in the Element’s
attributes, like setting it to invisible or disabling it. Let’s say that you have a Save button
that only logged-in users can click: you can hide this button with a Condition like the
one below:

163
 The Ultimate Guide to Bubble Security

It’s good practice to invert the conditions like above, and make the secure attribute default (in this case, the
Element will be invisible until the condition equals true). You’ll need to remember to set the Element to not
visible on Page load.

Or if it makes more sense to disable it but keep it visible, a similar Condition would do
the trick:

164
 The Ultimate Guide to Bubble Security

While design choices like this can be useful from a UX perspective, they’re not a secure
way to keep data private or actions from running. As long as the Button is on the page
(even if invisible), it’s not secure.

The same goes for elements that have the This element isn’t clickable attribute. It will
stop most Users from triggering any action by clicking the button, but it won’t stop
someone determined to circumvent that obstacle.

So keep in mind the distinction between obfuscation and security. Disabling a button is
a necessary design choice that serves a clear purpose: but it cannot be considered a
secure way of stopping the workflow from running.

165
 The Ultimate Guide to Bubble Security

The same logic can apply to Conditions that are placed on Actions. There are ways to set
up conditional expressions to stop actions from running that are secure, but there are
more ways to set it up in an insecure way. Many assume that conditions are always
checked server-side, but this is not necessarily the case. Many conditions are checked
on the page itself, and the action that it restrains can also be vulnerable to
manipulation even if the condition is processed on the server.

Client-side vs server-side conditions: it’s all about the action

This doesn’t mean that conditions are altogether insecure, but it does mean that using
them securely requires some knowledge about what happens server-side and what
happens client-side.

Conditions are the rules that tell Bubble how to behave in a given scenario. Since we’ve
established that everything that happens on the client is insecure, and everything that
happens on the server is secure – how does that affect conditions? To answer that, we’ll
have to ask ourselves if the action happens on the server or not. Conditions that are
placed on a server-side action will be checked server-side, while actions running on the
page will be checked on the page.

What does that tell us? A few things - and it opens up a few questions too. Let’s go over
what it reveals first:

166
 The Ultimate Guide to Bubble Security

● Actions that make changes to the database (such as Make changes to a Thing will
be sent to the server, and its condition will be checked there), making it secure
● Actions that happen on the page (such as Show an element) will have their
conditions checked on the page, making them insecure

So what if we mix the two? What if the action happens on the server but the condition
relies on the page or vice versa? In that case, we’re dealing with a weakest link situation:
if one link in that two-step chain is weak, the whole process must be considered
insecure. Let’s see what exactly that means by going over the four different scenarios
that this gives us:

A server-side action with a client-side condition

Let’s first look at a server-side action (Make changes to a Thing) that relies on a client-side
condition (Element is visible).

167
 The Ultimate Guide to Bubble Security

In this case, there’s no way for the server to actually check the condition: it relies
completely on stuff happening on the page, and as we know the page can be tampered
with.

168
 The Ultimate Guide to Bubble Security

A process is never more secure than its weakest link. In this case, the condition can be tampered with, making
the action insecure even if it’s processed on the server.

This is potentially insecure since one link in the chain is weak.

A client-side action with a server-side condition

Now let’s turn that around and look at a client-side action that relies on a condition
requiring server-side processing. Since we can trust the server to respond with accurate
data, the action is secure, right?

In this case the vulnerability is switched, but the conclusion remains the same.

169
 The Ultimate Guide to Bubble Security

No, again we’re dealing with a chain with two links where one is weak: it’s true that the
server will accurately validate the condition without any possible tampering but the
action itself is one the page and is manipulable.

A determined hacker can circumvent the condition altogether and run the action
anyway, since it’s all based on code resting on the User’s device. This makes it insecure.

170
 The Ultimate Guide to Bubble Security

A client-side action with a client-side condition

Ok, you’ve probably guessed the outcome of this one: a client-side action (Show
element) combined with a client-side Condition (Element is visible) doesn’t touch the
server at all. It’s fast, it consumes none of your capacity but in the end: it’s insecure.

Sometimes in life two wrongs make a right, but alas it’s not the case with Bubble. This process is not secure.

A server-side action with a server-side condition

For the final example, we’ll look at an action that is performed on the server (Make
changes to a Thing) and that also relies on a condition that relies on database
information (Current User’s field X is Y).

171
 The Ultimate Guide to Bubble Security

In this case, the whole operation, including the condition, is sent to the server, and is
only processed if the condition can be verified there.

As long as the action is processed on the server and the condition is verifiable on the server, it’s a secure
workflow.

172
 The Ultimate Guide to Bubble Security

This is the secure way of restricting on-page actions.

What can we take away from this? Well, mostly the same thing that we’ve concluded
several times over already: things that happen on the page, whether they are actions,
conditions or something else are vulnerable to tampering and your pages and
workflows should be planned accordingly. For conditions that apply specific properties
to an element on the page, you need to assume that it’s insecure no matter what the
condition is, since the element itself is of course on the page. For actions, you need to
see it as a two-link chain where one weak link is enough to render the whole process
insecure. Only when Bubble can both process the conditional expression and the action
on the server can it be considered secure.

Setting up secure pages

Secure pages in this case means any page where there’s any kind of restriction on what
Users should be able to see. The most common example of this is your app's backend:
your front page is probably accessible to everyone, but your backend (or admin
dashboard) is only accessible to logged-in users.

In most setups, pages like these are protected by a Workflow that Triggers when the
page is loaded and/or whenever the Condition for seeing the page no longer equals
true (such as the user no longer being logged in):

173
 The Ultimate Guide to Bubble Security

The User is logged out event will trigger at any point in time when the Users isn’t logged in, not just on page load.

There are several security precautions that we need to take into account for this, and
the first thing we need to understand is the kind of redirect that’s applied as the Bubble
server receives the request to load the page.

174
 The Ultimate Guide to Bubble Security

Understanding redirect types

A page redirect is as you would guess simply a command that sends the User from one
page to another page. Doing this in Bubble is simple: simply use the Go to page action
and specify which page to send the User to, and voilà, you have yourself a redirect.

But… it’s not that simple. Let me explain.

As with nearly anything having to do with security, redirects too are affected by what’s
happening on the server versus what’s happening on the client. Some redirects can be
applied server-side, while others need to be applied on the page itself. That may sound
difficult to wrap your head around at first, but it’s pretty logical – it all has to do with
whether the page has loaded at the time of the redirect or whether it needs to load
before it can redirect.

Let’s talk for a few seconds about http requests again. When an http request is sent to
the server, the server sends a response, as we’ve explored. Looking at the raw content of
the response, the first thing you will find is a HTTP response status code that tells the
device what the status of the call is. As long as the page is loading as expected, it will
return a success status in the number range 200-299 – usually 200. The response codes
are grouped in five classes:

1. Informational (100–199)

175
 The Ultimate Guide to Bubble Security

2. Successful (200–299)
3. Redirection (300–399)
4. Client error (400–499)
5. Server error (500–599)

As you can see from category 3, there is a separate category for redirects. If you have
ever worked with Search Engine Optimization you may already be familiar with
category 3 and the code 302: this tells the browser (or search engine crawler) that a
page has moved temporarily to a new URL and should be redirected there (301 reports
a permanent move).

The plot thickens. We start to see the difference between client-side and server-side
redirects. Let’s dig into the details.

If you want to learn more about http status codes and see a list of all current
codes, you can check out this article on Mozilla’s developer portal.

Server-side redirects (3xx)

If we get a 3xx redirect response already with the http call, what does that tell us? It
tells us that the browser will move on to the next page before any content is loaded.

176
 The Ultimate Guide to Bubble Security

Because we’re able to redirect the User even before a single byte is downloaded, we
skip the whole issue of hiding elements on the page altogether. A server-side redirect
will also be faster than a client-side redirect, since there’s no need to download the
page data and fewer steps to process before landing on the final page.

Client-side redirects

Client-side redirects are different in that they rely on Javascript that runs on the page. It
doesn’t leave a trace in the http response at all, since the page is already loaded – the
http raw response will simply show a 200 (successful).

177
 The Ultimate Guide to Bubble Security

In this case, all the page data that Bubble sends with the initial server response will be
downloaded to the browser before the redirect is applied, opening up for
vulnerabilities. Additionally, a client-side redirect, like everything happening on the
device, can be tampered with: it can be slowed down or stopped altogether, allowing
the User to explore your page for as long as they want.
Any Go to page action that you trigger by something happening on the page (like the
click of a button) will obviously be performed client-side. But you may inadvertently
force Bubble to perform it this way even on page load if not set up correctly.

Setting up different redirect types

Like many Bubble actions, how exactly a redirection is applied is invisible to you as a
developer unless you make an effort to look for it, making this one of the lesser known
potential security issues.

Basically, Bubble will try to apply a server-side redirection whenever it’s possible to do,
but there are multiple scenarios where this might fail. To know whether it’s successful
or not, we need to be able to test it. To do that, we can check the http response code as
we explored in the previous section, using a tool like SureOak’s 301 Redirect Checker.
Now let’s look at a few different scenarios and how they behave.

For the examples below, I’ve set up two pages:

178
 The Ultimate Guide to Bubble Security

● page1 (redirected from)

● page2 (redirected to)

Page is loaded event

The most obvious thing to do is to set up a Page is loaded event and place a Go to Page
action inside of it. Makes sense, right? As long as this is handled immediately when the
page is loaded, we should get a server-side redirect.

179
 The Ultimate Guide to Bubble Security

Checking that in the 301 redirect checker, we can see that the server uses a 301 redirect
and then successfully loads page2:

Ok, so that gave the result we wanted. Let’s try a different approach.

User is logged out event

Now we’ll set up the exact same thing, but use the User is logged out event instead.

180
 The Ultimate Guide to Bubble Security

And we get the same result:

181
 The Ultimate Guide to Bubble Security

Ok, so Bubble does indeed mostly user server-side redirection as long as it suspects we
want it to kick off before the page loads anything else. Let’s give it something more
challenging.

Do when Condition is True event

This looks almost identical to the last example, but this time we’re using the Do when
Condition is true event and setting Only when to Current User is logged out.

182
 The Ultimate Guide to Bubble Security

Upon testing it in the browser, I can already see this behaving differently: elements are
appearing on the screen before it redirects to page2. Checking it in the 301 redirect
checker we can confirm our suspicion:

183
 The Ultimate Guide to Bubble Security

No redirect has taken place during the http request, and the page reports as having
loaded successfully, showing the status code 200.

Conclusion

We could of course go over a myriad of different examples here, but still not cover every
possible one: the important thing is to emphasize the difference between client-side
and server-side redirection and the tools needed to test it. A successful 3xx redirect will
send your Users moving along quickly without loading any of the content on the page
and is the definite best practice for redirecting unauthorized Users.

A quick reminder and word of caution: this doesn’t get you off the hook in designing
your app to be truly secure. A redirect is an obfuscation: it stops Users from visiting a
Page they shouldn't be able to. Still, even if that is the only page where you are able to
view specific data, that doesn’t mean the data is secure, and I’m happy to echo that

184
 The Ultimate Guide to Bubble Security

reminder as many times as I need to: only data hidden behind Privacy Rules is truly
secure, regardless of whether a User can see a specific page or not.

What we can also read from the examples above is that the User is logged out event is
the best way to secure your page: this will trigger a 301 redirect on page load, and it will
trigger at any time the User logs out or clears their cookies.

That being said, always check that secure pages registers with a 301 redirect and make
this part of your deployment routine. Adding new actions, making changes on the page
and updates in the Bubble engine can change the behavior of the redirect, so make
sure you stay on top of it.

On-page security

Not knowing about the difference between a server-side and client-side redirect, a lot
of developers assume that a redirect can be circumvented, and add additional security
on their page to further obfuscate data. While some of these make sense, it’s important
still to not let them lull you into a false sense of security.

Hiding and showing groups based on User attributes (basically double-checking the
same condition as on the redirect) is a typical added security measure that, while it
won’t do any damage, it won’t add much protection either, so don’t assume that it does.

185
 The Ultimate Guide to Bubble Security

But we can’t always redirect a User away from your page. You could have different levels
of administrative access on the same page for example, where a User with a low-level
clearance should not be redirected to another page, but should not have access to all
sections either.

In that case, from a UX perspective, you need to build this logic into the conditions that
show and hide the elements on your page. But – this is obfuscation, and not security.
It’s important that you stick with the mantra that your UX is never 100% secure. As
soon as data reaches your page, hackers can find a way to reveal hidden Elements, find
sensitive information hidden in Bubble’s Javascript code or snap up data from network
transfers happening behind the scenes. Keep in mind our illustration from earlier:

186
 The Ultimate Guide to Bubble Security

What we can now conclude, knowing what the last section has told us, is that the outer
layer (the app’s user interface/design) can never really be secured 100% - but it doesn’t
have to matter, as long as you design it right:

● A hacker might be able to expose a section of your page that shows the result of
a search: such as a list of Users, Tasks or Messages - but it doesn’t matter, because
you’ve protected the data with Privacy Rules (Find this in searches). All Bubble
will render is a user interface with an empty Repeating Group. We can live with
that.

187
 The Ultimate Guide to Bubble Security

● The hacker might also be able to show a form that lets you create or edit a
database Thing - but it’s ok, because the Groups Data Source is protected by
Privacy Rules (view fields) the input fields are protected by Auto-bind Privacy
Rules (Allow auto-binding) and Workflows by Server-side Conditions. The hacker
may be able to see your beautifully designed form, but he won’t be able to use it
for anything.

This makes the illustration clearer: while unauthorized access to restricted parts of
your app can still happen, you can view this as just a “shell” - an outer layer that a
hacker can view all they want, and all they’ll be able to see are Repeating Groups with
no records, empty forms that don’t react to editing and buttons that don’t react to
clicks. Your app, if your data is protected correctly, is the equivalent of a ghost town -
the walls are still standing, but no one’s there.

188
 The Ultimate Guide to Bubble Security

Your app’s user interface for unauthorized users should be like an abandoned building. Someone may be able
to break the door in - but there’s nothing to find but the structure itself. Hopefully with a more appealing
design than this.

Let’s sum up our learnings from this chapter one more time to simplify:

● Ensure that you are redirecting your Users with a server-side redirect by
checking it with the redirect checker
● Protect all data with Privacy Rules
● If the page has workflows that should be restricted, add conditions to them and
ensure that both the condition and the action are performed on the server

189
 The Ultimate Guide to Bubble Security

Designing with security in mind

Your app as soon as it’s public will leave the safe haven of your office and go out in the
world like a teenage son or daughter leaving the warm nest of their parent’s home to
explore faraway places. Just like any parent would worry about the situations their
children might encounter over the next month of traveling in a strange continent, you
need to worry where your app is going and the dubious situations it needs to be
prepared for.

Ok, enough with the clever metaphors. The content on our screens has become
increasingly mobile over the last years, and the covid pandemic has accelerated the
change: people spend less time at the office, and indeed many don’t consider
themselves to have an office at all. Their work is done at home, at the nearest
Starbucks, the local library or at a co-working space. This has forced software designers
to change how they think about security: if the User of my app rises from his seat and
walks over to the counter to get a refill on their coffee– what kind of information is
displayed on the unlocked screen for those 90 seconds?

«I would never do such a thing» you might argue: and that’s good. A wise decision. But
people do do such things and worse, and as an app designer who cares about security,
you should always keep in mind that the choice you make can have drastic

190
 The Ultimate Guide to Bubble Security

consequences for Users, regardless of who you consider to carry the actual
responsibility for it.

Let’s illustrate with a well-known example: why does your browser show a star symbol
(****) instead of the actual password when a User is typing? The answer is of course that
we don’t want our Users to inadvertently reveal their password to someone looking
over their shoulder.

Hacking is not the only way to gain access to User Data - passwords are masked to avoid someone looking over
your shoulder to steal your login information

We’re so used to this, we don’t really think about it, but it is after all a security
consideration that’s made in direct relation to the User’s hardware: the User accesses

191
 The Ultimate Guide to Bubble Security

your app using some sort of screen (laptop, monitor, tablet or phone), and we basically
force the User to keep their password hidden - protecting them from themselves.

Your app takes on its own life on computers and phones in open office landscapes,
airports, cafés, meeting rooms and private homes, and devices are lost and stolen all
the time. Put yourself in the shoes of the User and base your policy and design strategy
on that.

Let’s look at some examples of how your app’s design can prevent data from falling into
the wrong hands:

What do we show on page load?

Whenever you log in to an app, you’ll likely be redirected to some sort of information
displayed on screen. What kind of consequences might arise from the decision we
make here? Think about it: we’re giving the User no choice at this point: whatever they
do, having logged in, they’ll be taken to this screen. They could have people looking
over their shoulder at the airport. They could have a colleague or client sitting next to
them. They could be connected to a projector in a meeting room. If the first screen they
see after logging in exposes sensitive information, you may want to re-think that
decision, or give your Users a choice to pick their own default screen.

Should a piece of data be hidden by default?

192
 The Ultimate Guide to Bubble Security

Certain information is only needed once or rarely, and should be hidden at other times.
Imagine a middle manager opens up the company’s Bubble-made HR app to check
something with a colleague sitting next to her. The last window she had open before
she closed the laptop was the employee profile of another person: listed on that profile
is the employee’s salary information. Most would agree of course that the manager is to
blame for allowing their colleague to watch the screen: but by keeping privacy in mind
during the design process we could have limited the exposure. Instead of blaming the
manager, we acknowledge that situations like these do occur, and we can help make
them less likely to cause any damage. It can be as simple as requiring one click of the
mouse to reveal the information - as long as it’s not staring you in the face the second
you turn on the screen.

Should a piece of data require re-authentication?

Authentication (checking the correct identity of the User) usually happens on login: as
long as the User can provide their credentials there, we trust them to be who they say
they are. But given enough time situations will arise when the computer is left
unattended, even if for less than two minutes (while the owner is getting a cup of
coffee). Just enough for a dubious individual to click a few buttons on the screen and
reveal important information. How can we avoid it? If information is so sensitive that its
leakage can cause serious damage (such as the social security number of a person or
the API Key of a payment gateway), we can require an extra round of authentication

193
 The Ultimate Guide to Bubble Security

before showing it - and make sure to not load it into the device before that
authentication has taken place.

Should I log the User out after a while?

Your online bank is most likely logging you out within a few minutes of inactivity, while
most apps will keep you logged in for weeks or more. Logging the User out after a while
is an added security measure that you can consider if your app needs a higher level of
security, You can also use the Log out other user's sessions action to log out on all devices
except the one the User is currently on: keep in mind that you need a separate Log the
User out action to log out that device too.

Also keep in mind that the Log out other user's sessions action will not automatically
refresh the pages of the logged out sessions. Expired sessions will only redirect after a
user takes some sort of action on that device.

Are you giving potential intruders valuable information?

Every hacking attempt starts out with a search for vulnerabilities. Imagine that you’re
standing in the supermarket talking to your spouse on the phone: «Yes, I always leave a
spare key outside.» you say absentmindedly, but you don’t specify where it is. A random
person in the queue behind you lifts his head with interest. Silently he follows you
home to see where you live, and that same night he probes your plot for the key that he
knows to be hidden somewhere. A burglary might take place that wouldn’t have

194
 The Ultimate Guide to Bubble Security

happened if a key piece of information hadn’t been accidentally exposed. Think of your
app in the same way: any kind of information that you give a potential intruder can
help them in their search for vulnerabilities and even encourage an attack that
otherwise wouldn’t have occurred. Keep information close to your chest.

Are you insinuating that there’s value to be found?

Same scenario. You’re standing in the supermarket, talking to your spouse on the
phone: «Yes, I left the diamonds in the safe, don’t worry.» A random person in the queue
behind you lifts his head with interest. Silently he follows you home to see where you
live, and that same night he probes your house for an open window or unlocked door.
You really need to re-think your phone habits.
Similarly to the above scenario, we have potentially triggered an attack in this example
by insinuating that there is something of value to be found. The same can happen in
the software world: if your app holds sensitive data of some kind, the best way to stop
an attack is for it to never take place. If an intruder is not aware that your app holds
such data, they are less likely to get the idea to break in in the first place.

How am I naming my pages?

Admin, login and dashboard are all typical page names that hackers will go to first in an
attempt to hack your site. If they single out your site specifically, they’ll be able to find
these pages whatever you name them (remember, all page names are mentioned in
Bubble’s JS files), but if you simply happen to be targeted by a botnet attack that tries

195
 The Ultimate Guide to Bubble Security

its luck with millions of sites, going with a less traditional name for your secure pages
can be enough to keep them out.

Where am I redirecting Users?

If a User happens upon your administrator page to which they should have no access,
where do you redirect them? In many cases to the admin section’s login page. In this
case we’re again providing that User with information they wouldn’t otherwise have:
we’ve made them aware that there is a login page and that the administrator page URL
was likely correct. Two pieces of information that can encourage an attempt to break in.
Redirecting them to the front page, or even better, to a 404 page gives the impression
that they visited an unused URL.

Am I using popups for logging in?

A common way to use the Popup group is to apply an overlay color or blur to hide the
information underneath to keep it secure. In many cases, this method is used when a
User is logged out on a secure page: a popup will show up asking the User to login in.
Given the right credentials, the popup goes away and the page is revealed as normal.

Using DevTools or an Ad Blocker, a hacker can easily hide the popup and reveal the
content below. If a User is viewing a page they’re not supposed to see, hide the content
and redirect the User away from the page.

196
 The Ultimate Guide to Bubble Security

Conclusion
Just like we’ve discussed in earlier chapters, don’t see the above examples as some sort
of exhaustive list: the main idea to take in from the scenarios above is that privacy and
security goes hand in hand with design decisions. While planning your app, take a look
at all your page wireframes and ask yourself some questions:

● Does this page reveal more information than needed by default?

● Am I giving away information to potential intruders?
● Are there parts of this page that require extra security measures such as
repeated authentication or being logged out automatically?

197
The Ultimate Guide to Bubble Security

APIs

198
 The Ultimate Guide to Bubble Security

Introduction
One of the incredible strengths that Bubble offers is the ability to set up both incoming
and outgoing connections to other applications. While it is one of the more complex
and code-like parts of building with Bubble, most developers in learning find that it
actually looks more difficult than it is. For those who come from a non-development
background to Bubble, making that first successful API can feel like you just gained a
new superpower.

But here’s the catch: setting up API connections can open up for security vulnerabilities
in a range of different ways - some of which can be critical, confusing and very hard to
identify on your own. You simply have to be told or it’s very unlikely you’ll find out until
someone else finds out for you. Bubble’s product design does give you all the
information you need to audit your own security, but they don’t make it very clear what
exactly the consequences for some of these settings are.

But we’re getting ahead of ourselves. Let’s take a look at the basics first.

What is an API?

Whenever two machines need to exchange information, they don’t need a fancy visual
interface like you and me do. The nice design, buttons, icons and images that we like so
much would be a hindrance for a machine trying to interpret the data. No, a machine

199
 The Ultimate Guide to Bubble Security

prefers it straight up – as raw, predictably formatted data with no bells and whistles.
On today’s internet, many of the apps that you use daily increasingly rely on REST APIs
to deliver their services. It’s so common in fact, that it has become a big part of the
foundation of how the internet works. Apps constantly communicate with each other
to make things easier for you, serving up everything from your own calendar
appointments and files to news articles, weather predictions and secure payment
methods.

So how does your weather app actually know what the weather will be like? How does
Calendly know that you’re busy on Thursday at 1:30 pm? And how does Zapier let you
automate tasks between more than 3000 different applications?

The answer, as you of course already knew, is the use of an API. An API (or Application
Programming Interface) is a way for applications to talk to each other, but within
strictly defined rules. APIs don’t give access to how an external application actually
works - but it gives a line of communication where you can ask the application for
specific information or to execute a command within its own internal system. Bubble’s
own Do a Search for is an API call, and can illustrate our point: you know that you can ask
Bubble for information and get something in return, like a list of Things or a count of
those Things. But you don’t know, and can’t affect how the search is actually performed.
That process happens behind closed walls on a server far, far away.

200
 The Ultimate Guide to Bubble Security

Asking a weather API is the same: you’ll get a neat, readable response on what the
weather will look like for a given time and place, but you have no control over the
weather stations, algorithms and staff members who helped make the information
available in the first place.

The API is often called a layer, since you’re not actually peeking into the actual inner
workings of the application, but only standing on the outside talking to a very strict
guard who only allows you to ask a predefined list of questions. The communication
happens between a client (the computer that makes the API call) and a server (the
computer that offers the API as a resource). We’ll be using the term client and server in
this way throughout this section of the book.

For a Bubble app, APIs let you connect to other apps and query data or send them
instructions, but it also works vice versa. You can set Bubble up to accept incoming
queries and commands from other apps to share data, keep things in sync and
automate processes.

What is an API endpoint?

So an API is a line of communication between two systems and often allows access to a
range of different resources. For example, Twitter’s API may let clients download
tweets and user names, but it also lets Users authenticate (log in) to another app using

201
 The Ultimate Guide to Bubble Security

Twitter credentials without revealing their username and password (called Single
Sign-on or SSO).

API endpoints are any point of entry into your application when communicating with
an external system, typically a URL. The endpoint is the means from which the API can
access the resources they need from a server to perform their task. APIs and endpoints
are not the same thing - rather an endpoint is a part of an API system.

In Bubble, this means that every public API workflow gets a unique URL that a client
can visit in order to trigger that workflow, and every exposed Data Type gets the same.
All endpoints in your app start with a base path (Bubble calls this API root URL), which
identifies your app’s URL, and then a subfolder and path that points to the right
endpoint. You’ll find the base path under Settings - API when you activate the different
sections of your app’s API:

Base path

No domain connected:
https://appname.bubbleapps.io/version-test/api/1.1
https://appname.bubbleapps.io/api/1.1

202
 The Ultimate Guide to Bubble Security

Domain connected:
https://yourdomain.com/version-test/api/1.1
https://yourdomain.com/api/1.1

Swagger: how all your endpoints are published online

By default, Bubble generates a JSON file containing all your API endpoints (public API
Workflows and Data Types that are enabled in the Data API settings) and publishes it
on the web. You can find this file and view it in your browser using the URL below:

Swagger URLs

No domain connected:
https://appname.bubbleapps.io/version-test/api/1.1/meta/swagger.json
https://appname.bubbleapps.io/api/1.1/meta/swagger.json

Domain connected:
https://yourdomain.com/version-test/api/1.1/meta/swagger.json
https://yourdomain.com/api/1.1/meta/swagger.json

203
 The Ultimate Guide to Bubble Security

Note that this file too consists of version-test and live. Replace the text in bold with your relevant app or
domain name.

What is Swagger?

Swagger is the pet name of the OpenAPI Specification version 2, and you’ll find both terms
used around the web (technically Open API 3.1 is currently the most up-to-date version,
but Bubble still uses version 2).

An OpenAPI Specification is a structured way to describe REST APIs, and contains:

- The base path of your application:

/version-test/api/1.1 or /api/1.1

- All your available endpoints and their operations, plus parameters

- Security definition (describing the API token method that Bubble uses).
Does not reveal the token, only the method.

- The different responses that the client gets after a call

Whether the call was successful or not, and what kind of error may have
occurred

204
 The Ultimate Guide to Bubble Security

All the information is saved in a JSON file, which is designed to be easily readable both
by humans and machines. Swagger’s (or Open API’s) purpose is both to standardize
API practices (how to document parameters, paths, responses, authentication, etc) and
to encourage the use of this kind of machine-readable JSON that Bubble offers out of
the box.

Why is this shared?

If you’re not experienced working with API’s, revealing all this info might seem crazy,
but it actually makes good sense. The purpose of any API is to accept connections - why
else would you set it up? By offering this documentation, you’re inviting external
services to easily connect to your app because you have your technical documentation
in order. In most cases you will be requiring authentication from any Client that tries to
place a call, making the public list perfectly safe.

So as you can see, sharing the Swagger documentation is in itself not high-risk, but the
whole premise rests on two important points:
- That your endpoints (Data Types and Workflows) are properly protected by
Privacy Rules and authentication requirements (we’ll get back to that later)
- That you as a developer are aware what the JSON file is exposing and make the
needed adjustments if it reveals more than you are comfortable with

205
 The Ultimate Guide to Bubble Security

Swagger is a feature - not a bug. But it’s also one of the most surprising learnings of
developers getting into app security. It is enabled by default, and combined with
enabling the Data API and ignoring Privacy Rules, it reduces your application’s
database security to basically zero, leaving it wide open.

Checking just one box in your app settings and having no Privacy Rules not only gives anyone full access to your
database, you’re also offering instructions on how to access it.

Using Swagger as a tool

Of course, the fact that anyone can view your API documentation means that you can
view it too. Using the links above to access the JSON is a good way to get an external
view on what exactly your app reveals.

Any workflow or data endpoint that shows up in the Swagger documentation is public
because your settings made it so: not because Bubble’s security is weak or buggy. Get to
know it - if you are horrified by what you see, you should get to work on your Privacy
Rules and unpublish API workflows and Data Types you don’t want to expose. You can
also instruct Bubble to not generate the Swagger file in the API settings of your app.

206
 The Ultimate Guide to Bubble Security

Keep in mind though, that there are plenty of other ways to identify weakly protected
API endpoints: Swagger just makes it easier. So while disabling it can make sense if you
have no need to keep that information public, don’t let it give you a false sense of
protection. Obfuscation is not security.

How does Bubble connect to APIs?

Bubble let’s you use to outgoing or incoming API connections in a few different ways:

The Data API lets external services connect to your application’s database and Create,
Read, Update and Delete records (CRUD). Each public Data Type in your database
generates and endpoint in a subfolder called obj:
https://appname.bubbleapps.io/version-test/api/1.1/obj/data-type-name

API Workflows let you create custom workflows that can be triggered by an external
service through an API call. Each API workflow you publish generates an endpoint in a
subfolder called wf:
https://appname.bubbleapps.io/version-test/api/1.1/wf/workflow-name

The API Connector plugin lets you authenticate and connect to an external service to
use as a Data Source or Action. In this case you are using someone else’s API, so this

207
 The Ultimate Guide to Bubble Security

doesn’t add any endpoints to your app. Instead, you are accessing one of their
endpoints.

If you’re interested in learning more about what API Calls actually look like,
you can check out our in-depth article on How API Calls Are Structured.

We’ll go over each of the three methods outlined above and explore how they can
potentially put your data at risk, as well as how you can secure them.

Plugins can add Actions and Data Sources to your app that you may or may
not be aware are API calls, but these are outside of the scope of this book.

Authentication
As you’ll remember from earlier in the book, authentication refers to proving the
identity of the Client, not to what that client can actually do when access is granted. So
let’s first talk about that. Keep in mind that the Client in this case is any system that
connects to your API.

208
 The Ultimate Guide to Bubble Security

What is a token?

REST APIs generally use one of four different authentication methods (Basic, Bearer,
API Keys, oAuth) of which Bubble’s Data Api uses a Bearer Token. The token is a unique,
cryptic string of characters that the client must send in the Authorization header when
making a request to authenticate their identity. It follows that one Client normally
equals one token - they’re unique and not shared.

So what exactly is the difference between a token and the User’s username and
password? If API calls are made over an encrypted HTTPS protocol, can’t we simply send
the Username and Password every time to authenticate? There are multiple reasons
why this is not a good idea:

● Passwords are semi-permanent, meaning that they are often in use for a long
time
Tokens are temporary and can be revoked
● Passwords are often used in multiple places
A token is unique for every relationship between a Client and a Server
● Humanly generated passwords are often weak
A compromised password can give wide access to your platform; tokens are long,
random strings that are not easily guessed
● The password needs to be stored on the Client (unless the User wants to type it
in for every single call)

209
 The Ultimate Guide to Bubble Security

This opens up a wide area of potential risks and you will be relying on a
third-party system to keep it safe
● SSL/TLS is occasionally compromised
Security is a constant race: sometimes holes are found and need to be patched.
In the meantime, a hacker could be able to intercept data in an API call, even if
it’s encrypted. Think about it this way: the chances are slim that a hacker could
access a call containing a password during the small window before SSL/TLS is
patched: but they could be recording encrypted traffic now, store it and decrypt it
later. If all they get is a temporary token, it doesn’t pose that much risk: but if
they get a password (which is at the least semi-permanent), there’s a big chance
that it is still in use.

Authentication levels

With Bubble’s API, we have three levels of authentication (who the Client is) that each
provide their own set of authorizations (what that Client has access to). Each of them
access the app with a specific type of token or no token:

Unauthenticated Clients are Clients that have access to your API without any
authentication. What this means in practice is that all API workflows and Data Types
are left wide open: anyone who knows its endpoint can execute, view and change
anything. Data can be protected with Privacy Rules, but those rules are not dynamic:

210
 The Ultimate Guide to Bubble Security

you either give full access or no access, with no further Conditions possible.
Token: None

Authenticated User Clients are Clients that have a User set up in your database, and
have received a unique token to access the API as that User. The Client is accessing your
workflows and database in the same way that a regular User in your app does. Privacy
Rules are dynamic: you can set Conditions based on fields on the User the Client is
“logged in” as.
Token: Temporary User token

Authenticated Admin Clients are Clients that are accessing your API by use of an API
Token generated in the API settings in the Bubble editor. They’re not affiliated with any
registered User in your database, and have full, unrestricted access to your database
and workflows, unaffected by Privacy Rules.
Token: API token

Authenticating as a User Client

There are two different ways in which you can authenticate a Client as a specific User in
Bubble:

211
 The Ultimate Guide to Bubble Security

● You can place a Log the User in action inside of an API Workflow, and Bubble will
return a token to the Client when the call is made. This token can then be used to
authenticate as the User in subsequent calls and is valid for 12 months
● You can set up Bubble as a Single Sign-on provider and let your Users sign up or
in via a form in your own app and redirect back to the Client app.

Let’s first talk about how these methods differ from a security perspective.

Log in a User with their Username and Password

This method places an API call to your application that contains the credentials of the
User (the email address and password). The API workflow proceeds to log the User in
using these credentials, and returns a token that can be used for future communication
without logging in. The external application will stay logged in for 12 months, after
which they will have to log in again.

This method is fairly simple to set up; create an API call with one parameter for the
email and another for the password. Run the Log the user in workflow, and Bubble
automatically returns the token to the client.

212
 The Ultimate Guide to Bubble Security

From a security standpoint, the method is not inherently too risky to ever be used, but
should still not be used without some consideration:

● The User’s credentials will be entered into the external application

○ You need to trust that application to be both trustworthy and capable of
maintaining their own security. The external application could easily save
the information or otherwise compromise it.
○ Users with some knowledge of computer security might react negatively
to the idea of entering their credentials into an external application

To conclude, sending the email and password along once in an API call to get a token in
return does not necessarily introduce an unacceptable risk, but should not be
considered best practice either. It is easy to set up, but places a lot of trust in the
external application where the User will enter their credentials.

213
 The Ultimate Guide to Bubble Security

Log in using Bubble as a Single Sign-On provider (SSO)

The second option is to use your Bubble application as a Single Sign-On provider. This is
the most widely used method for authentications of this kind, and you have likely used
it time and time again with other platforms and maybe even with Bubble. If you have
set up your Bubble application to allow Users to create an account using Google or
Facebook, you’ve been using them as an SSO provider. You’ll have noticed that your
Users will not be entering their Google credentials into your app – they will be
redirected to a login page hosted by Google, and then returned to your site. This time
we’re turning the tables around, and allowing other systems to use your app to
authenticate a User. This in turn will provide them with an access token that gives the
external system access to your APP as that User until the token expires.

The actual process is a bit more complex, but this is how it looks from the User’s perspective.

As you may have guessed, the detail that makes this the more secure solution is the
fact that your Users don’t need to enter their credentials in another system: instead,
they are redirected to a page in your app where they can sign in, and then sent back to
the system where they came from. No User credentials are ever saved in the external

214
 The Ultimate Guide to Bubble Security

system: the only things Bubble returns are the access token, the token’s expiration date
and the Unique ID of the User.

API workflows

Backend Workflows vs API Workflows

To make sure we use the correct terminology, let’s first make the distinction between a
Backend Workflow and an API Workflow, since they tend to cause some confusion.

Anything that you edit in the Backend Workflows editor (whether it’s an API Workflow,
a Custom workflow, a Backend Trigger Event or a Recurring Event) is a Backend
Workflow. API Workflows are workflows that can be triggered by an API request (either
internally in your own app or from an outside client). They get their own API Endpoint
URL and you can decide what kind of authorization and Privacy Rule protection you
want to apply to them.

So, an API Workflow is a Backend Workflow, but a Backend Workflow is not necessarily
an API workflow.

215
 The Ultimate Guide to Bubble Security

All workflows in the backend are technically backend workflows, but what we’re discussing is the one named API
workflow, marked in red.

Setting up an API workflow means that you are setting up a workflow that can be
executed from somewhere else. This way you can invite a third party to run a workflow
in your application. As we discussed previously, this doesn’t give the third party any
insight into how the job is actually done or access to change anything in your app. All
they will see is a confirmation on whether the call was successful or not, and you can
choose to return any kind of extra data that you want. The call runs on Bubble’s server,
meaning that anything that happens in it is invisible to the device of the User who
initiated it, even if that call was made inside of your Bubble app.

The main security concern here is obvious: naturally, you need to be in control of who
can actually run those workflows.

216
 The Ultimate Guide to Bubble Security

If you’re interested in learning more about how Backend Workflows work,

we have an article on that here.

API Workflow settings

As long as Enable API and backend workflows is activated in your app’s API settings, all
API Workflows you create will be set up to be public, but requiring authentication to
run. When you first create one, you will be presented with the following settings:

API workflow name

The name you provide here will be the final part of the endpoint for this workflow. In
the example above, that endpoint would be
https://securitybook.bubbleapps.io/version-test/api/1.1/wf/my-api-workflow.

217
 The Ultimate Guide to Bubble Security

Expose as a public API workflow

This setting is what allows this workflow to be triggered from outside of your app. If
this box is checked, Bubble generates the endpoint above and will list it in the Swagger
documentation. If you are only using the workflow internally, there’s no reason for this
box to be checked.

This workflow can be run without authentication

This setting determines whether the API client needs to provide authentication to be
able to trigger the workflow. The authentication can either be a Temporary User Token
or an API Token like we discussed under Authentication Levels.

Ignore Privacy Rules when running the Workflow

API Workflows will automatically adhere to the Privacy Rules that the authenticated
User who triggered the workflow is subject to. In other words, if you schedule an API
workflow from within your own application, the workflow will run as the User that was
logged in when it was scheduled. If you are making the call from outside of your app,
the workflow will run with the authentication you have provided: if this is a Temporary
User Token it will adhere to the Privacy Rules that apply to that User. If you are
authenticating with an API Token it will access your app with full administrative access
(and no Privacy Rules will apply). There are many scenarios where it’s useful to disable
the Privacy Rules for a given workflow (if that workflow depends on a search or

218
 The Ultimate Guide to Bubble Security

checking fields that the User does not have access to for example). When needed, you
can check this box to override the Privacy Rules in that specific workflow.

Parameters

For many API workflows you will want to add one or more Parameters, and an obvious
question is whether these are secure or not: can you include secret information in those
parameters? The answer is yes and no. Let’s explore.

Yes, because API requests are sent over the HTTPS protocol and thus protected by
SSL/TLS encryption. Any hacker who manages to record the data during transit will only
be able to see the ciphertext (the encrypted data). Sending data in the parameters of
an API call is considered safe: and indeed, is often the reason the calls are set up in the
first place. We need to be able to pass information along.

Still, there’s a no in there, but it has less to do with the actual technical side of it, and
more to do with general best practices: as we saw in the section about authentication,
no system is ever 100% secure. Whenever an API call is made, two parties are involved:
the Client and the Server. Whatever data you send will be decrypted once it reaches the
other party, and what happens to it after that depends on the recipient. It’s worth
thinking about what would happen if this specific data were to end up in the wrong
hands: this is why for most API calls we use tokens instead of passwords for example.

219
 The Ultimate Guide to Bubble Security

Even though they work much in the same way and provide the same level of access, a
token is safer to send repeatedly since it can be revoked. A password in the wrong
hands can do a lot more damage. So while you can rest assured that the encryption is
most likely to hold up, it’s still worth considering what kind of information you want to
voluntarily share with a third party – especially if your User is unaware of the potential
risk.

Data API
The Data API is a direct path into the database of your application. This opens up to
exciting possibilities like sharing database information across different applications
and allowing other apps to execute database operations. A Data Type with no Privacy
Rules allows any external system to:

- See one or all of the records and all of their data

- Create new records
- Delete records
- Edit records

It goes without saying that this can lead to potential critical vulnerabilities. Just like in
the user interface of your own app, you need to know that you’re only sharing the
information that you planned on sharing, and not a byte more. You also need to be in

220
 The Ultimate Guide to Bubble Security

full control of what database operations you allow a client to perform. As usual, those
settings rely on your Privacy Rules, but this is where Bubble’s manual is fuzzy at the
time of writing this: understanding the levels of access that you are providing API
clients is confusing and somewhat poorly documented. So let’s try and unravel it.

Exposing Data Types

To expose a Data Types to API Clients at all, they need to be activated in your app’s API
settings. When Enable Data API is checked, Bubble will display a list of all your Data
Types with a checkbox next to it.

In this example, all Data Types except for User are exposed.

Checking a Data Type means that:

- The Data Type can be accessed through an API call
- An endpoint has been generated at
https://app-name.bubbleapps.io/version-test/api/1.1/obj/data-type-name

221
 The Ultimate Guide to Bubble Security

If the Data Type is not checked, it will not be exposed, regardless of how an API Client
authenticates itself.

The Data API and Authentication levels

The part that can be confusing is how the different levels of authentication can affect
access to data: it’s fairly easy to give a lot broader access than what you intended to do,
so let’s look at each one again in detail.

Unauthenticated Clients will have access to all Data Types that are not protected with
Privacy Rules. The Privacy Rules are not dynamic: you either give full access or no access
to a Data Type.
Token: None

Authenticated User Clients adhere to the Privacy Rules that apply to the User they are
authenticated as. This means that you can apply dynamic Privacy Rules that allow
different kinds of access to Data Types and Fields based on the User.
Token: Temporary User token

222
 The Ultimate Guide to Bubble Security

Authenticated Admin Clients that access your Data API with an API Token created in
the API section of the Bubble Editor’s settings have full, unrestricted access to all your
Data Types, regardless of Privacy Rules.
Token: API token

If we set this up in a table, it looks like this:

No token Temporary User Token API Token
Privacy Rules set Selected data exposed Selected data exposed All Data exposed
No Privacy Rules All Data exposed All Data Exposed All Data exposed

No token (Unauthenticated Clients)

The easiest way to share your app’s data with the world is by giving full access to
everyone. While there are many public API’s on the internet, most will still require you
to authenticate in some way: keep in mind that you’re not only exposing all your data,
you’re also giving the whole world access to spend your server’s capacity by placing
endless calls to your API.

If you want to allow this access level, three things need to be in place:

API Settings

First, whichever Data Types you want to share need to be checked in your App’s API
settings:

223
 The Ultimate Guide to Bubble Security

Privacy Rules

Secondly, you need to set Everyone else’s access to Find this in searches and View all fields.
You’ll notice when the Data API is activated that you also have access to limit access to
database operations (Create, Modify, Delete).

That’s it. No tokens need to be generated and no authorization is required.

Temporary User Token

A User token is used to access the database via an API “as” a User in your database,
applying the same Privacy Rules that would apply to that User in your regular app. This
not only means that you can emulate the access level of a registered User (giving that
User access to their data in external systems), but you can also set up Users with

224
 The Ultimate Guide to Bubble Security

specific Roles/Permissions to use for API calls, giving you granular control over the
access level of a specific authenticated API Client.

API Settings

As with other authentication methods, the Data Type needs to be active in the Data API
settings.

Privacy Rules

The Privacy Rules for the API client User work exactly as a regular User. Referencing the
Current User will apply to the client, as will any other Rules applied to the Data Type in
question. As we talked about in the chapter on Privacy Rules, activating the Data API
and selecting Data Types will add some more options to the Privacy Rule editor, giving
direct control of the operations that an authenticated Client can perform.

As always with Privacy Rules, remember that the Everyone else (default permissions)
setting will override other Rules and give more access than you intended. Keep all
checkboxes here unchecked to avoid unauthenticated Users to be able to access the
data.

225
 The Ultimate Guide to Bubble Security

API token

Using the API key generated in the Bubble editor gives the Client administrative access.
In other words, the Client will be unrestricted by Privacy Rules, but will still only have
access to the Data Types that are exposed in your Application’s API Settings. This still
potentially gives the Client a very broad access to your database, including operations
like Creating, Modifying and Deleting records: if you don’t need a Client to have
unrestricted access, you should consider using a Temporary User Token instead.

The API Connector

We’ve now covered the ways that a Client can reach your Bubble app: API Workflows
and the Data API waits for incoming connections and sends a response to whatever the
Client asks for. With the API Connector, we’re turning that around. Your app is now the
Client, and the API Connector initiates an outgoing connection with an external Server.

The principles at work are very much the same: since we are working with REST API’s,
the calls follow a generally predictable pattern and the same SSL/TLS encryption is
applied to the parameters you send. Since the API Connector (being outgoing) doesn’t
expose your application on its own, this section is fairly short. That being said, we’re
going to go over some important things to note.

226
 The Ultimate Guide to Bubble Security

If you want to learn more about using the API Connector, Bubble has released
a Youtube webinar that goes through this in detail. You can find that here.

API Keys
For Bubble developers in learning, API calls can be a new world. As such, even after
reading the first part of this chapter, it may not be obvious just how important it is to
keep API Keys secure. So first - what are they?

Whenever you get an API Key from an external system (such as Stripe or Google), you
are doing the opposite of what we did in the last section when we created a token. The
API key is their token, used to authenticate you as a valid User and authorize access to
various API resources without having to provide your login credentials to that platform.
As we explored earlier, the token is as good as a username and password, but it’s
randomly generated (stronger than most humanly generated passwords) and
temporary (it can be revoked at any time). Still, the access it provides while it is active is
as real and potentially compromising as the real password would be – and the key as
such should be kept just as confidential as the password to your most private accounts.

You may have experienced that some API providers even refuse to show you the API
key more than once: this way they both underline the importance of keeping the key

227
 The Ultimate Guide to Bubble Security

secret, and provide themselves with a minimal area of responsibility should the key
ever be misused. If no one can access it through their platform after the first time, it’s
hard to blame them for its misplacement.

In some ways, the API key can serve as a culmination of many of the lessons we have
gone over in the book: since we’ve learned that your browser's Developer Tools can
reveal a lot of information that you would otherwise think is secret, this can affect
where you store important information such as the API keys.

Countless times during coaching sessions and security audits, I’ve seen the keys stored
in Option Sets, for example. Developers assume that the Option Sets are encrypted, or
that Bubble at least downloads only what’s needed on a specific page. As we now know,
Option Sets are stored in plaintext on in full on all pages: an API key stored there would
be visible even on the front page.

As we’ve also seen, hiding important information in elements, custom states and inside
of an on-page workflow is not safe either: everything that is downloaded to the
browser rests on the User’s device and is potentially vulnerable to (sometimes fairly
easy) hacking methods.

We’ll look into how to safely use authentication tokens and other private information
with the API Connector shortly, but in the meantime; keep in mind that API tokens, and

228
 The Ultimate Guide to Bubble Security

all other private pieces of data, should never be stored anywhere on a page, as that will
leave visible traces in the downloaded source code. If you need to store important data
outside of the API Connector itself, you store it in – you guessed it – the database,
hidden by Privacy Rules.

How the calls are made

Any API calls that you make from the API Connector are passed through Bubble’s server
before they reach the Server specified in the call’s URL.

Bubble by default passes all API calls through its server – both the request and response.

In 2021, Bubble introduced the possibility of running an API call directly from the page
you are on, instead of passing it through Bubble’s server. The upside to this is
performance: since we’re getting rid of one step the call can finish faster. You can

229
 The Ultimate Guide to Bubble Security

probably already see where this is going by now: since it is happening on the page, it’s
not secure.

This is why Bubble has disabled in most situations: it is only available for public API
calls (that have no authentication whatsoever), and with no Headers or Parameters set
to Private. Also, if you are using information obtained from the call (such as using the
response data to Make changes to a Thing in the database, the entire call will be moved
server-side, even if the other criteria are filled.

Even with these precautions, Bubble does not stop you from sending sensitive data this
way: you are still free to add information like API keys to a call as a non-Private
parameter. Always be mindful of what kind of information you decide to send and
double-check that you are securing it in the right way.

Checking the box will let Bubble attempt to run the API call directly from the browser instead of passing it
through the Bubble server: this is ok for public API’s but not for passing any kind of sensitive information.

230
 The Ultimate Guide to Bubble Security

Sending the API call from the browser is an active choice: it’s never activated by default.

API endpoints and parameters

So let’s dig a little deeper into security measures you need to take when setting up the
API Connector. Explaining how to set up calls is outside of the scope of this book, and if
this is currently new for you I recommend that you get to know the API Connector first,
and then return to this section to learn more about its potential vulnerabilities.

Initializing calls

If you have set up API calls, you’ve learned that Bubble needs to initialize the call the
first time it is run. This serves two purposes: 1) it lets you as the developer test that the
call is working and returning the expected response, and 2) it teaches Bubble what the
response will look like, so that it can be implemented into your Data Sources and
Actions around the Bubble editor.

When you initialize the call you will need to provide an endpoint and usually some
valid parameters for the call to return a valid response. What’s not made clear is that
these values (just like default values on Data Type fields) are stored unencrypted in
Bubble’s javascript files unless specific settings are set. In other words, they’re
downloaded to the browser along with everything else.

231
 The Ultimate Guide to Bubble Security

Let’s have a look at an example call set up in the API Connector:

If you’re interested in learning more about how API calls are structured into
the Header, Parameters and Body, you can check out our in-depth article on
How API Calls Are Structured.

The header

Before initializing a call, you need to set up the authorization. This is part of the API’s
Header, and is all kept safely on the server-side: the information below never reaches
the browser.

232
 The Ultimate Guide to Bubble Security

The information stored in the authorization section of the API call is stored server-side, and is invisible to your
Users, even if they were to inspect the source code.

As we saw in the previous section about running API calls directly from the browser,
this option is no longer available when any of the fields below are filled, since that
would constitute a significant security risk, so Bubble strongly nudges you towards
keeping it all within the Header settings.

The Call

Now let’s look at the call itself. Have a look at the image below: all the fields marked in
red are exposed in the User’s browser and can potentially reveal sensitive information.

The fields marked in red are not secure and can reveal sensitive information.

Two questions naturally arise:

233
 The Ultimate Guide to Bubble Security

● Why is parameter-one secure and note parameter-two?

● How do we know that this data is exposed?

First question first: if you look closely at the image, you’ll see that the Private checkbox
is checked. This keeps both the key and the parameter hidden.

For the second question, we come back to Bubble’s JavaScript source code: the engine
that rests on the User’s device. This contains a lot of static information related to your
application, and data from the API Connector is among it. Looking through the code,
we can find the following:

234
 The Ultimate Guide to Bubble Security

Looking at Bubble’s JavaScript files, we see several fields are exposed.

As you can see, not only are we exposing our second parameter; we’re also showing the
name of the API Call and the full URL. In this example, you can see that the parameter
key added to the URL might have been sensitive information.

Now, to reiterate: it’s important to understand that while this information is available
on the User’s device, it’s still secure during transit. At this point it is encrypted with
SSL/TLS and no information can be identified. Parameters sent via an API can sometimes

235
 The Ultimate Guide to Bubble Security

contain sensitive information, but other times it makes perfect sense that they are
managed client-side. Indeed, many API calls rely on User input to function at all, at
which point the User of course already knows their content. So as we’ve seen multiple
times throughout the book, this is not a bug nor a feature: it’s simply how it works. The
important thing is to be aware and keep track of what information you’re potentially
exposing, not to keep all possible information secret and encrypted at all times.

Hiding key information

Ok, so now that we know that information about the call becomes part of the source
code available on the device, what do we do about it?

URL

Let’s take it from the top. A main concern from the image above is that we are revealing
the full URL of the API call. The URL could potentially contain secret information like
the parameter illustrated in the example, so how do you hide it?
Notice the text next to the URL input field that says (user [] for params). This lets you
place parameters at any place inside of the URL, and this parameter can be set to
Private. This way, you can hide that specific parameter from the URL:

But wait… there’s more. If we can insert parameters inside of the URL, does that mean
we can wrap the entire URL inside of a square bracket? Indeed it does:

236
 The Ultimate Guide to Bubble Security

By placing the entire URL inside of a parameter and checking Private, the source code
doesn’t even reveal to which server the call is being made. Now, do we need to hide the
entire URL? Not necessarily. But why give a potential hacker any more information than
we have to? Hiding the URL is a very quick fix, and puts a potential hacker ever so
slightly more in the dark as to what your application does. Giving your API a neutral
name and hiding the URL also hides that API resource from your competitors: those
five seconds of invested time could pay off.

Parameters and initialization

Why do we fill out the values of an API Call’s parameters if we want them to be dynamic
anyway? There’s really only one reason: to initialize the call. Once Bubble has
successfully made the call, there’s no reason to keep the values around anymore

If you’re relying on dynamic values, there’s no reason to keep the default value in non-private parameters.

We refer to this as Initialization clearing and it’s a natural part of our deployment
routine. Keep in mind that the value can also be used as the default value for the call: in

237
 The Ultimate Guide to Bubble Security

those cases you’ll want to keep it around. But in most cases, having strong security
means to build strong habits as a developer. Initialization clearing is one of them. If you
don’t do it, make it a conscious decision, not something you forgot.

238
 The Ultimate Guide to Bubble Security

User accounts
While Bubble gives a fair amount of flexibility also when it comes to security, there’s an
area where they do set some limits even on your powers as developers. User accounts
are a Data Type, sure, but it comes with its own set of rules that sets it apart from other
Types. You can’t delete the Data Type, for one, and there’s a whole collection of Actions
and Conditions in the Bubble editor that are only directed to this one Type.

As the most integral part of your app’s security, Bubble doesn’t give you much flexibility
to manipulate how User authentication is done. While there may be edge cases where
this can limit your development freedom, it’s another plus in most cases: one more
thing that’s managed and continually updated by a professional third party that you
don’t need to spend any of your time and resources on.

User stages
If you have an app where Users can log in, you will have two types:

● Users who are not logged in (anonymous users)

● Users who are logged in (authenticated users)

239
 The Ultimate Guide to Bubble Security

Sessions
A User’s engagement with an app is usually known as a session. The exact definition of
that word is not set in stone, so we’re free to use it as we want: in this book we’ll talk
about sessions as the full range of time where we can identify one specific user in one
specific state (not logged in or logged in). This leaves us with a session looking like this:
● The time a User spends with an anonymous, but recognizable profile (not
logged in, but staying on the same device)
● The time User spends logged into a Bubble app account

Anonymous Users

Whenever a new, anonymous User visits a Bubble page, Bubble creates a temporary
User profile, allowing you to make changes to that User. This is how you can save
information like settings, selected language or cart items on a User even though they
haven’t signed up yet. Some web applications store information in the cookie itself: a
typical example is the products that an anonymous user might add to a cart on an
e-commerce site. Bubble doesn’t do it this way: instead, there’s an actual User profile
set up in the database for every User, and the cookie simply contains the Unique ID of
that temporary User. Viewing this in Chrome Developer Tools, you can see:

1. The actual session cookie (Application -> Storage -> Cookies) containing the
Unique ID of the anonymous User’s database record

240
 The Ultimate Guide to Bubble Security

2. The network activity needed for Bubble to fetch that User’s data from the
database
Let’s have a look:

We can have a look at the session ID in the Application tab in DevTools. As you can see, it matches the unique ID
of the network activity below. Notice that you can separate the session cookie from other cookies in the Expires /
Max-Age column, where it’s identified as Session.

Since even anonymous Users are stored in the database, we can track that network activity in DevTools and see
what data Bubble pulls from the database. Notice that only the built-in fields are displayed, even if Privacy

241
 The Ultimate Guide to Bubble Security

Rules allow viewing of other fields. If you save something to a custom field (like a name), it will show up here
along with the built-in ones. Naturally, the email field is also missing.

So as you can see, a User always technically has a database record attached to their
session, even if you can’t find it in the database. If they were to access the app from five
different devices, they would have five different database records each with their own
Unique ID. As a result, the Current User field in Bubble never returns an empty value:
there’s always technically a User there.

Signing up
As soon as you sign the User up using the Sign the user up action, the profile is completed
with authentication in the form of an email address and a password and the
information stored on the temporary profile is saved permanently in the database.
From this point on, the User can log in from any computer and find their data there,
and you will see the record in the database along with other registered Users.

242
 The Ultimate Guide to Bubble Security

User attributes
We’re moving into the territory of User Roles and Permissions shortly: what we do to
allow specific Users to see and make changes to specific resources while others can’t.

Earlier in the book we talked about User types, and the way these different types are
separated is by user attributes – some kind of information about the User that your app
can use to determine their access level. While Bubble handles User registration at the
most basic level (setting up an account and signing in/out), there’s no built-in handling
of Roles and Permissions, which gives you full control over this aspect of the app’s
security. From your perspective as the developer, the User Attributes are the fields that
you use to set up Conditions in Privacy Rules, on Elements and in Workflows/Actions to
tell Bubble what the User can and cannot do.

243
 The Ultimate Guide to Bubble Security

The workflow above will only run if the User is logged in - one of the built-in User attributes

You can use any sort of attribute saved on the User to control their access to data and
actions:

244
 The Ultimate Guide to Bubble Security

Setting up rules like this can be done on Elements, in Workflows and in Privacy Rules -
basically giving you any kind of security that you would need. But at some point, these
kinds of granular rules need to be organized in a more manageable system. This is
where User Roles and Permissions come into play.

245
 The Ultimate Guide to Bubble Security

User roles
What are User Roles
What exactly a User Role is depends on the app being built, but let’s look at what User
Roles mean from a security perspective.

As we move on to Permissions and Roles, it’s useful to note that these are not Bubble
terms or features: they’re computer science terms that can be applied to any framework
that deals with logged-in Users and permission levels. So don’t look for them in the
Bubble documentation.

Permissions
Permissions govern a User’s ability to perform specific actions in your app. Typical
examples include:

● Reading specific content

● Making changes to specific content
● Creating, editing and/or deleting other Users
● Access specific sections or pages

246
 The Ultimate Guide to Bubble Security

Let’s close in a bit and look at what that actually means for a Bubble app. As you
develop your application, you’ll use Permissions to:

● Set up Privacy Rules for viewing and editing data

● Use Conditions on page elements to control who can see them
● Use Conditions on workflows and actions to control who can run them
● Use Custom Events to navigate Users away from pages they don’t have access to

Roles

Rather than assigning Permissions to each user individually, Permissions are often
grouped into Roles. In this way, you can see Roles as a container for Permission settings
that can then be assigned to one or more Users more efficiently.

Roles are containers for different Permissions that your Users can have. They can be as overarching or as
granular as you need for your particular project.

247
 The Ultimate Guide to Bubble Security

Across a wide range of applications you’ll recognize similar Role structures with names
like Super Administrator, Administrator and User. While you may choose to use similar
naming conventions in your own application, there’s no set rules or best practices to
adhere to here, apart from the fact that using well-known terms can help avoid
confusion. Some applications have pre-set Roles that Users can’t change. Others have
more complex systems that prepare you as a developer for your app’s future needs or
that allow for your end-users to set up Roles and Permissions for themselves.

Since there’s a fairly wide gap between the simpler and the more complex permission
structure, we’re going to look at scenarios for both of them. As always, I use examples
with a caveat: first, don’t assume that any given example exactly describes the perfect
solution for your app. Add it to your toolbox and set up a structure that makes sense for
your app's needs. Secondly, overengineering is a very real thing: the latter example
gives you a lot of flexibility, but is also a lot more work to implement and maintain. In
the words of E. F. Schumacher: “Any fool can make things complicated. It requires a
genius to make things simple.”

Ok, so with the brainy quotes out of the way, let’s look at how the two methods differ:

248
 The Ultimate Guide to Bubble Security

Simple Role Structure Complex Role Structure

+ Quick and easy to set up Highly flexible
Doesn't use the database (faster) Can allow end-users to configure Roles
Granular Permission levels
– Can only be changed by a developer Slightly less performance-friendly
Static Permissions More time-consuming to set up/maintain

Example 1: Simple Role Structure

In our first example, we’re in some ways simplifying the Permissions and Roles into one
term simply called Roles. Technically we’re doing the same thing, but instead of setting
up Roles and Permissions in two different places and dynamically connecting them,
we’re simply attaching specific static permissions to a Role directly in the Bubble editor
instead.

This method is great for apps where Roles and Permissions remain fairly static over
time and you’re ok with having to rely on deploying new changes to your app as
needed. You can set up granular permissions with the simpler structure as well, but it
may force you to keep track of those permissions in a lot of different places around your
app.

249
 The Ultimate Guide to Bubble Security

Scenario

In this app, we’re setting up a simple blogging platform where we only need one Data
Type in addition to User called Article. We have four different Roles in mind for our
Users, each with different static permissions. The roles are not going to change
significantly in the time ahead. Let’s look at our Roles:

Admin
- Access backend
- See all Users
- Edit all Users
- See all Articles
- Edit all Articles
- Publish Articles

Publisher
- Access backend
- See all Users
- See all Articles
- Edit all Articles
- Publish Articles

250
 The Ultimate Guide to Bubble Security

Author
- Access backend
- See own Articles
- Edit own Articles

Everyone else
- See published Articles

The roles make intuitive sense, right? We have a few different levels of backend Users
in a hierarchy, and then we have Everyone else (which is not a Role, but everyone who
doesn’t have one). In this scenario, this covers both authenticated and anonymous
users.

Setting up our Roles

In this scenario, we’ll be using Option Sets to store our Roles, and then manually set up
conditions in our Privacy Rules, Elements and Workflows to enforce the permissions.

If you want to learn more about how Option Sets work, you can find an
in-depth guide on the URL below:
https://www.amliesolutions.com/bubble/basic-features/option-sets

251
 The Ultimate Guide to Bubble Security

First, we’re going to create a new Option Set called Role. Then add the four Options that
we named earlier like in the image below:

After just 20 seconds of work we can already see the outline of our Roles in the Option Set editor.

Next, we need to store the Option in a field saved on each User. Set one up called Role,
and connect it to the newly created Option Set:

252
 The Ultimate Guide to Bubble Security

Create a field called Role on the User type and assign the newly created Option Set.

With this, we’re ready to connect a Role to each User. Set up a new field called Role, and
set the Type to the Role Option Set. Now it’s time for a word of caution: you might be
tempted at this point to set a default value on each User. This way, you can make sure
that all new registered Users are assigned the lowest Role in the hierarchy (Author),
right? But keep in mind our lesson from earlier that Bubble creates a temporary User
for each and every visitor to your app. The default value you provide in any User field
will be saved even on that temporary User, and you may inadvertently give every User
who sees your app Author privileges – that’s probably not what you intended! So
remember: Current User never returns an empty value.

253
 The Ultimate Guide to Bubble Security

Next, we’re going to set up our Article type. We’ll add three fields to it:
● articleText contains the actual Article and is of type text.
● articleHeader is the header of the Article and is of type text.
● Author is the User who wrote the Article and is of type User. We don’t want to use
the Created by field, because we want Admins to be able to change the Author if
necessary.
● published determines whether the article is published or not, and is of type yes /
no. We’ll set the default value to no for this one.

The Data Type should look like this:

254
 The Ultimate Guide to Bubble Security

Setting up the Privacy Rules

Remember from the chapter on Privacy Rules that we are granting access – not
prohibiting it. In our blogging platform, we have two Data Types to take into
consideration: Users and Articles. We now need to set the access level for each Role on
each Data Type in correspondence with what we decided earlier in each Role
description.

The logic of our Privacy Rules is simple: on each User, we save a Role, and that Role has
access to some things and not others. The Privacy Rule Structure looks like this:

By making a direct connection between the User and the Role in the form of an Option Set, we get a lightweight
permission system that’s easy to set up.

First, let’s have a look at the Articles.

255
 The Ultimate Guide to Bubble Security

Admins and Publishers have the same permissions for our Articles. Both can find all
Articles and Edit them as they please, including Publishing them. Now let’s look at
Authors, that are a bit more constrained:

256
 The Ultimate Guide to Bubble Security

We can see some key differences here, highlighted in red.

1. Note how we have an extra condition: Authors can only see their own
unpublished Articles.
2. Authors cannot publish an Article, so we’ve blocked that field from auto-binding
3. Authors cannot change the Author of their own Article, so we’ve blocked that
from auto-binding too

If we want anyone to be able to see our Articles in the front-end, we’ll also need top
open up for Published Articles to be visible:

257
 The Ultimate Guide to Bubble Security

Note that we’re not mentioning the User and their Role at all – as long as the Article’s
published is “yes”, anyone can find it in searches and view it. We do have some
restrictions: not all fields are visible, and editing is completely disabled.

Now, for the Everyone else field:

We leave all fields blank here, since we’ve already granted viewing permission to all
Users in the last step, provided that the Article is Published. If we opened up for
searches and viewing fields here, even unpublished Articles would be visible.

258
 The Ultimate Guide to Bubble Security

Setting up the Actions

Now, we’ve assumed in our Privacy Rules that we’ll use auto-binding for all our Fields.
As we’ve been through, this is the most secure and most lightweight way to make
changes to our database, and I strongly encourage its use. Still, there are of course
plenty of situations where design decisions nudge you away from auto-binding, and in
these cases it’s important to know exactly how secure your setup is.

First off, let’s remind ourselves that Privacy Rules do not stop data from being edited
altogether - it only prohibits auto-binding. Even a field that’s set in Privacy Rules to be
invisible to the Current User can still be manipulated with a Bubble action. As we’ve
also discussed in the previous chapter , simply hiding or disabling an element does not
provide sufficient protection as any User with knowledge about DevTools can show
those elements again fairly easily.

So what’s the solution?

We need to place the condition on the Workflow or Action itself. This way, even if a User
gets access to a page, section or element that they’re not supposed to (either by intent
or by a glitch), Bubble will still stop the Workflow/Action from running.

259
 The Ultimate Guide to Bubble Security

For our Article website, let’s assume that we don’t want the Publish field to be changed
by auto-binding a checkbox, but instead with a big button in the editor that says
Publish. Something like this:

In this case, we want Users with the Role Admin or Publisher to be able to run the
workflow and publish the Article. We’ll set the condition on the Workflow, looking like
this:

260
 The Ultimate Guide to Bubble Security

A simple condition placed on the Workflow or Action stops it from running if the User doesn’t have the right
Role.

261
 The Ultimate Guide to Bubble Security

You can still of course make the button unclickable with a Condition placed on the
Element itself for UX purposes (in order to hide it or change its appearance for
example) - just don’t rely on it for security.

Setting up the admin page

Now for the admin page, we return to our previous discussion about how to keep
unauthorized users out of the page. As you’ll remember, everything that happens on a
page once it’s downloaded is technically under the control of the User, including
client-side actions. If a non-logged in User wants to access the admin page, you’ll need
to assume that every bit of static data on the page is downloaded and stored
unencrypted. Keep in mind our image from earlier: the app is a shell that should
contain no sensitive information and is only there to serve the secret data in your
database.

Of course, it would only be visible to a User who really tried to get access - for everyone
else, we’ll implement several safeguards to stop them from seeing any content on the
page at all. On the page level, there are only two things we need to implement. We
need to:

- hide all the content (elements) on the page until we know that the User is
logged in and has the right permissions

262
 The Ultimate Guide to Bubble Security

- redirect the User to another page

We’re going to use an Action for both of these, since Actions are more secure than
element Conditions. First, let’s set up the Page redirect:

Since we only provide a Role to admin Users, we can simply check whether this field is empty and redirect to
another page if it is

Since the content of the page can load and display before Bubble has time to redirect
the User, we’ll need to keep all Groups hidden and then show them with an Action if the
User’s credentials are ok. Again we are relying on a very simple conditional Workflow
that checks if the User’s Role is not empty. With some planning, we’ve placed all the
content on the page in one group called content, which is set to invisible on page load.

263
 The Ultimate Guide to Bubble Security

Using an Action to display a group is more secure than using Conditions.

Case conclusion

Ok, so we have a simple Role system in place that takes care of permissions on a
general level. As you can see, we’re relying on you as a developer to set up and maintain
it, but for a lot of applications this will work out just fine. For our blog platform,
permissions are not likely to change substantially, and introducing a new role is still
fairly easy to set up. Our page relies on a redirect and hidden groups to keep the
content safe, but as we learned in an earlier chapter, our main security lies in Privacy
Rules - if hackers get access to a page or section they’re not supposed to, our data still
rests safely on the server, well out of sight. All they’ll be able to see is the page UX.

264
 The Ultimate Guide to Bubble Security

Example 2: Complex Role Structure

For our more complex Role structure, we’re going to be diving into the use of
Permissions on a more granular level. In the first example, we didn’t really use
Permissions by name at all, although we’re still of course handling them in practice.

The keyword for the more complex Role structure is flexibility. While you don’t have to
give your end-users access to set up custom Roles and Permissions, the method allows
for it, and you can choose to control a User's access level down to single Fields. Let’s
move away from our blog platform and onto SaaS platform that requires more control
over each User’s security level.

Scenario

We’re now building CustomrTM a CRM platform that stores information about
Companies and Contacts within those companies. If you’re unfamiliar with Customer
Relationship Management (CRM) software, this is simply a platform for keeping track
of all the business contacts and sales processes of a Company, and they range from
highly complex and expensive to simpler products tailored to a specific niche industry.

In our example, we’re just going to include basic features (company/contact

management), but the methods we’ll use can be extended to as many different data
types as you need. One key difference from our last example is that we’re also going to
take into account that this is a multi-user system: several clients from different

265
 The Ultimate Guide to Bubble Security

companies can log in, and should only have access to data that belongs to their own
company.

We’ll be working with the following Data Types in this app:

● User: You know this one

● Role: A named role with a list of Permissions
● ParentCompany: The Company that any User in the app belongs to
● Company: External organizations that are saved in the CRM
● Contact: External contacts that are saved in the CRM (that usually belong to a
Company)

Setting up our Permissions

In our last scenario we used Option Sets to set up Roles. We’re going to tweak that setup
a little bit for this one: the Role is going to be a Data Type, and the Permission is going to
be an Option Set. That leaves us with a logic that looks like this:

266
 The Ultimate Guide to Bubble Security

The Role Data Type contains a list of Permissions, and we’ll use that to populate the
field on the User as needed. There are two reasons that the Role type is a Data Type and
not an Option Set:
1) We can’t reference a sub-Option Set in a Privacy Rule (such as User’s Option Set’s
Option set) - Bubble doesn’t allow this at the time of writing.
2) On the bright side, leaving the Role a Data Type also means you can set it up as a
dynamic field, allowing your Users to tailor Roles and Permissions as they see fit

Ok, back to our actual setup. First, we’ll set up the Option Set called Permissions. You can
of course follow any naming convention you feel comfortable with, but for the example,
we’ll use the structure Thing: Permission, such as Company: See all (meaning this
Permission gives the User access to see all Companies and not just their own).

267
 The Ultimate Guide to Bubble Security

Using a set convention on how we name our Permissions makes it easy to identify exactly what each one does
and search for them by name.

Setting up the Data Types

Before we look at the details, we’re going to keep our Data Types very simple for the
sake of example: obviously a Contact Data Type would contain a lot of information (first
name, last name, phone, email, etc), but we’ll just include a few basic fields to avoid
confusion for now.

268
 The Ultimate Guide to Bubble Security

ParentCompany
Ok, remember that we’re building a multi-client platform here, so we’ll first need to set
up a Data Type to separate groups of Clients from each other: the ParentCompany type.
We’ll keep this one really simple for now. All it needs is a name:

To maintain our Privacy Rules, the ParentCompany Data Type needs to be stored as a
field on every other Data Type we create to make sure we can keep all of our client’s
data safe on a server level.

Company and Contact

Companies and Contacts are fairly similar. We’ll add the fields we need for our Privacy
Rules, and an extra informational field (Phone) to illustrate how we’ll manage editing
rights. Any Rules or Conditions we use on that field can be extended to as many other
fields as you need.

269
 The Ultimate Guide to Bubble Security

Note that we’re connecting Contacts to Companies with a field on the Contact, and that
both have the ParentCompany field to secure our multi-client environment.

Role
Our Role Data Type is also very simple: just a name, and a list of the Permissions (that
Option Set we created earlier) that the Role includes:

270
 The Ultimate Guide to Bubble Security

User
And then finally, we’ll save the Role as a Field on the User:

A real User would probably have more fields, but take note of the important ones: ParentCompany and Role.

271
 The Ultimate Guide to Bubble Security

Setting up the Privacy Rules

Our Privacy Rules are not going to behave that differently from our last scenario, except
for two key points:

● We’re now working with a list of Permissions instead of just one Role
● We have to take into account that our User belongs to a ParentCompany - which
needs to be present in every Privacy Rule that we set up
I’m re-using the naming convention from our Permissions Option Set here to make them
easily recognizable:

Allow Auto-binding is disabled since this Permission doesn’t give any editing rights.

Now, we also want to set up the scenario for Users who have editing rights:

272
 The Ultimate Guide to Bubble Security

Note that ParentCompany is not an editable field, since we don’t want end-users to be able to make any changes
to it.

The Owner field on the other hand is open for editing, so that a Contact Owner can transfer the Contact to a
colleague.

Lastly, don’t forget the most important rule: what we show everyone else. Nothing in
this case.

273
 The Ultimate Guide to Bubble Security

For our second Data Type, Company, the setup will be more or less identical, so there’s
no need to illustrate it, so let’s move on to the User:

First, we’ll assume that a User can see all their colleagues, so we haven’t included that as a separate Permission.

Note that we don’t allow editing another User’s Role here: this is a pretty significant security privilege, so we’ve
set up a separate Permission for that.

274
 The Ultimate Guide to Bubble Security

Again, we can only edit the Roles of Users in our own company. Note also that we’re only granting that one
permission. Editing the User’s name is already covered by another Permission.

We’re also assuming (without a separate Permission) that Users are allowed to edit their own basic info, but not
their ParentCompany or Role.

Everyone else have no access to anything: making this a completely closed system.

275
 The Ultimate Guide to Bubble Security

The separate Permission we set up for the Roles field on the User illustrates the
important point that we can use Permissions and Privacy Rules in combination to
control what our Users can make changes to, all the way down to single fields.

Editing Roles

This last part is not directly related to security, but included to show the usefulness of
using Option Sets to Store our Permissions. Since we’ve added our Permissions as a list
of Options in an Option Set, we can display those Options in a Repeating Group and
easily let end-users view and toggle Permissions for a given Role.

276
 The Ultimate Guide to Bubble Security

In the illustration above you can see how this works: The Repeating Group is contained
within a Group that has a Role as its Data Source. Note that we’re displaying All
Permissions – not just the ones contained in the currently loaded Role. That should leave
the Data Source of the Repeating Group looking like this:

Now select the Checkbox inside of the Repeating Group cell. Our logic here is that if the
currently loaded Role contains this Permission, this box should be checked. We can set
a dynamic value on its status to return a yes / no response, like below:

277
 The Ultimate Guide to Bubble Security

To quickly set up a Workflow when the checkbox changes value, right-click it and select
the bottom option:

278
 The Ultimate Guide to Bubble Security

Right-clicking any kind of input element and selecting Start/edit workflow gives you a shortcut to set up a
trigger when that input’s value changes

279
 The Ultimate Guide to Bubble Security

To toggle the Permission’s presence in the Role’s list of Permissions, set up the actions
as below. The first action adds the Permission if the checkbox is checked, and the
second removes it if the checkbox is unchecked.

280
 The Ultimate Guide to Bubble Security

If you prefer that the results are not immediately saved, you can pass the list of
Permissions through a Custom State instead by loading the included Permissions into a
State when the Role is loaded, adding and removing Permissions to that State’s list,
and then saving the entire list from the State to the Role with a Save button when
editing is done.

Case conclusion

With some still fairly easy steps, we can add a lot of flexibility to our Role and
Permission system. This approach even opens up for editing Permissions on a User
level (and override or remove the Role if a User is customized).

Talking to your Clients about their specific needs is useful, but in some cases setting up
this kind of flexibility by default can save you a lot of work later as your app scales and
needs change.

281
 The Ultimate Guide to Bubble Security

Chrome Developer Tools

So one of the main premises of this book is that what you see on the page of your
Bubble app is not all there is. We’ve looked at how there’s a lot of data downloaded into
the browser even if it’s not displayed on the screen, and that both static data, network
activity and workflows can be snapped up somehow. But the question remains… How
do we know?

Surprisingly, for a majority of security questions, the answer is pretty straightforward:

Chrome Developer Tools

What is DevTools?
Chrome DevTools, short for Development Tools, is a suite of handy developer tools built
right into the Chrome browser. For Bubble builders, it may not feel that familiar, but
traditional web developers use it routinely to experiment with and debug their work.
DevTools lets you record and investigate network traffic, manipulate the design of the
page (changing Elements, Conditions and CSS) and debug JavaScript by setting
breakpoints on specific lines or events, or going step-by-step (just like Bubble). It also
features something called the Console, which lets you type in JavaScript and see the
results immediately in the open browser tab.

282
 The Ultimate Guide to Bubble Security

All of this means that this is not just a tool to understand your app’s security – it’s the
tool. Indeed, many hacking attempts likely begin with using DevTools to scan the page
for vulnerabilities.

If you don’t have any experience with it, DevTools can look somewhat intimidating at
first. It’s not a sexy interface and is likely to drop you right into a bunch of code the
second it opens – the exact thing we tried to avoid when we picked Bubble, right? But
don’t worry; we will be looking at code, but you won’t need to know exactly what the
code means. We’re not looking at how the code runs, but what it exposes: what details
from our app can we find in there that a hacker might have an interest in?

Opening DevTools

The easiest way to find DevTools is to click ⌥ ⌘ I on Mac or Control+Shift+I on

Windows. Make sure you have the page you want to analyze open when you do so. You
can also right-click and select Inspect on any Element on the page:

283
 The Ultimate Guide to Bubble Security

Right-clicking anywhere on the Bubble page you want to analyze and click Inspect to open up Chrome
Developer Tools.

This will take you directly to that Element’s line of code in the page’s HTML. Note that
DevTools doesn’t record activity until it’s open. You may need to reload the page to see
any information.

Ensuring a fresh download

284
 The Ultimate Guide to Bubble Security

Chrome (and all other major browser) keeps a lot of downloaded content from
different websites cached in a folder to avoid having to download it again. This can
skew your analysis, since different assets on your page have already been downloaded.
To avoid this, you can open up the application in Incognito mode. This way, you’re
testing the page with a completely blank slate and you avoid browser extensions that
may pollute your results.

If you prefer not to use Incognito mode, you can also delete the browser data for the
page, but this is pretty cumbersome in the long run. Do this by clicking the lock in the
URL bar, then click Site settings and finally Clear data. This only clears data for that
specific page.

Using Site settings, you can clear cookies and other data for a single page at a time in Chrome.

285
 The Ultimate Guide to Bubble Security

Understanding network activity

A key part of understanding how Bubble or indeed any web application or page
operates is to understand the network activity. We probably don’t need to repeat the
basics again: network traffic is any activity that happens between a Client (your device)
and a Server. In the case of a Bubble app, that can be the Bubble server, but it’s not only
that: all the different stuff in your app (fonts, images, plugin code, JavaScript files like
Tag Manager and Google Analytics and other resources) are downloaded from
multiple servers across the world; it’s not that unusual that more than a hundred
different requests are made on a single page. It’s hard to take in the technological
complexity of showing a single web page.

The Network tab is what we’ll be looking at.

Clicking on the Network tab takes you to the Network log, which by default shows all
the activity chronologically.

Network activity consists of a request and a response, both of them are encrypted while
in transit, but decrypted both before they leave and as they arrive on the User’s device.
This means that your browser is the innocent bystander catching every word of
dialogue between the Client and the Server – and boy is he taking notes. Every byte of
data that travels between your device and a server is recorded in the browser and can

286
 The Ultimate Guide to Bubble Security

be investigated in DevTools. If you don’t have a web development background, the term
“network activity” can be kind of a put-off - isn’t this outside of the cozy realm of
no-code? But network traffic is actually not that hard to decipher: it’s just a bunch of
commands and responses sent back and forth to make something happen on the
screen. Parts of it look complicated, but other parts look neat and totally humanly
readable. They’re also predictable. When the page loads, there will be loads of activity.
Then silence. You click a button with some workflow actions. Boom, lots of traffic for
half a second, and then crickets. Learning that fact and actually being able to pinpoint
and recognize how the network operates is strangely empowering. Move over Neo,
we’re taking over The Matrix

Isolating activity

The network log can end up being fairly long, especially on bigger pages. If you want to
isolate a specific part, such as viewing only the network activity that takes place when
you click a specific button, you can clear the list first to remove everything left over
from the page load and other activity:

287
 The Ultimate Guide to Bubble Security

Clearing the log can make it easier to isolate specific activity, such as inspecting what happens as you run a
workflow.

Filtering network activity

Network activity can be filtered to show only specific types of requests. Most of the
detective work you’ll be doing in DevTools is related to two kinds, marked below:

The filtering tools available are marked in the red rectangle, with the two we’ll be discussing are numbered.

288
 The Ultimate Guide to Bubble Security

Fetch/XHR

This tab shows activity generated by XMLHttpRequest and the newer Fetch API
requests. The easiest way to think about these terms is that they allow the exchange of
data between the website and the server. While the CSS and Image tabs show the
requests for CSS and image files respectively, the Fetch/XHR tab shows requests that
your browser makes to a server – in many cases the Bubble server – to fulfill a process
such as updating the database, fetching data from the database and completing
expressions and workflows that rely on the server to finish. By isolating this tab, you
can view only activity related to this exchange of data.

As you get to know this tab, you will start recognizing some of the different requests
that Bubble makes to the server:

Request Purpose

search Do a Search for in the database (single)

msearch Do a Search for in the database (multiple)

mget Get a specific database record, such as the Current User

maggregate Aggregate data from the server, such as Do a Search

for:count

start Execute a workflow on the server

doapicallfromserver Run an API call from the API Connector through

Bubble’s server

289
 The Ultimate Guide to Bubble Security

This is not an exhaustive list, but can help you identify and investigate how different
requests are made by your on-device Bubble engine and what kind of data they reveal.

In the example above, we’re looking at an mget request and clicking the Response tab to
see what the server sent back. Here we can see all the information saved on the User
that’s available with the current Privacy Rules. It becomes obvious that mget is a way to
fetch data from the database, and that Bubble downloads the entire record even if I’m
not showing all this information on the page.

JS

JS, short for JavaScript, shows all the JavaScript files downloaded to the browser. As we
explored earlier, Bubble’s on-device “engine” is a Javascript library that contains the
code needed for your app to run, as well as a lot of information stored in the app itself

290
 The Ultimate Guide to Bubble Security

(Translation texts, Option Sets, Static content, API setup). By isolating this tab, you can
view each file and their content to inspect what kind of data you are revealing in the
code.

291
 The Ultimate Guide to Bubble Security

Opening up a JS file and clicking the Preview tab you can view the contents of the file. If
you want to find some specific string of text, you can click Ctrl/Cmnd + F to do a regular
text search. In the example above I’m searching for a Translation string (app text) that’s
indeed present in plaintext in the file. You can use this to find specific data, such as to
verify whether you’re correctly protecting the parameters in an API call.

Case: generating a one-time code

Ok, so let’s have a look at how DevTools can help us identify vulnerabilities in our app.
We’ll look at a common scenario: a User signs up to your platform. To provide an extra
layer of security, you send a randomly generated code to the User’s email address. The
User then has to enter that code into an input field to verify their account.

So by simple logic, we should do the following:

- We save a randomly generated code on the User (to be able to verify it later)
- We send that code to the User

That workflow might look something like this:

292
 The Ultimate Guide to Bubble Security

First, we generate a random code and save it in a field on the User. Then we send the
email based on the previous step:

293
 The Ultimate Guide to Bubble Security

Good! All taken care of! The User has no idea what the code is, and will need to check
their email - thus confirming the ownership of that email account. But wait. Let’s see
what DevTools has picked up:

Sending the action to the Server

As you can see in the screenshot above, Bubble has communicated twice with the
server when we pushed the button:

294
 The Ultimate Guide to Bubble Security

The first contact with the server is the start request. As we saw earlier, this request kicks
off a workflow, just like we would expect. Looking in the preview tab - *gasp!* - what
have we here? Our randomly generated string. In this case, the string was generated on
the device and passed to the server via the start request. As you’ll remember, as soon as
the traffic hits the network, it’s encrypted with SSL/TLS and quite safe: but in the User’s
browser it’s visible. This is usually not a problem, but in this case, even the User
shouldn’t know its value: but here it is, and it took a mere five seconds to find it. But
wait, there’s more.

Fetching updated User information

Bubble keeps a live connection to any loaded database Things. This is how you can
make a change in the database and see the result instantly on the screen. Since we’re
making a change to the User, Bubble re-downloads the updated database record using
the mget request, and you can preview the content of the network activity:

295
 The Ultimate Guide to Bubble Security

Looking at the User record, we can see the code saved there in plaintext. We could have
avoided this by hiding it with Privacy Rules, but we would still have seen the initial
workflow in the start request.

Pseudorandomness

A third point, that we won’t dig too deeply into since it’s outside of the scope of the
book, is the generation of the string itself: Bubble is generating the random string
using a JavaScript function called math.random. This function uses a method called
pseudorandom number generation (PRNG). While the text looks completely random to
the human eye, it is in fact not truly random, since it’s based on an initial value called a
seed. This makes it a deterministic generation method, and its outcome can be
predicted. This means the outcome is not considered cryptographically secure.

296
 The Ultimate Guide to Bubble Security

Lessons learned
So what we discovered here simply with a few seconds of investigation in DevTools is
that the method we chose is not secure at all: it would in fact be very easy to
circumvent. We didn’t expose the secret string once, but twice and our attempt at
looking like we take security seriously would be turned against us. Bummer.

So how should we have done this? As we’ve discussed throughout the book, anything
that happens on the page should be considered insecure. The whole process of
generating the string, storing the value somewhere and emailing it to the User should
have happened in a backend workflow, where the User cannot see it. If you do save the
random string on the User, it should have been protected by Privacy Rules so that the
User can’t see it - again relying on backend workflows where you can override Privacy
Rules to confirm it. DevTools can help you identify problems like this quickly: you don’t
need to know much code to recognize your own data in there somewhere: but the even
more important lesson to repeat is this: what goes on on the page is not secure – move
it to the server. This is how we know.

DevTools can also be used to great effect to speed up your application by

identifying requests that slow down your page. You can read a lot more about
performance in our book The Ultimate Guide to Bubble Performance and

297
 The Ultimate Guide to Bubble Security

about DevTools and performance specifically in this article:

https://www.amliesolutions.com/bubble/bubble-and-devtools/

298
The Ultimate Guide to Bubble Security

Conclusion

299
 The Ultimate Guide to Bubble Security

You made it this far in a book focused on the most technical and procrastinated topics
in all of software development: security. No one will ever applaud your app for
maintaining expected privacy standards or avoiding a hacking scandal, and as humans
we don’t tend to focus on the bad things not happening to us: not having a fever is rarely
appreciated as much as having one gives you discomfort. Not being robbed on your
way home is great, but you’d be considered somewhat strange if you had a smile on
your face throughout every minute of your life where you were not being held at
gunpoint. It’s just a truth of life that we mostly assume that bad things are not going to
happen to us. Of course they do happen to someone all the time. It’s statistically
unlikely that it’s you at this very moment - but given a long enough timeline,
something’s bound to mess things up for the app you worked so hard to set up.

Some things are drilled into us from childhood: you pay for insurance on your house,
car and perhaps your health. You save money for a rainy day. You leave your expensive
belongings in the hotel safe before venturing into a strange city and you lock the door
to your house when you leave it. We do these boring, repetitive things because we
know that the consequences can be severe if we don’t. You need to have the same
approach to the security of your application.

App security is the private User data that’s never lost. The lawsuit that never takes
place. The PR nightmare that never happens. It’s about respecting the Users that place
their trust in you to properly manage their private data and the quality of sleep you get

300
 The Ultimate Guide to Bubble Security

from knowing that no one will expose an embarrassing vulnerability on Twitter

tomorrow morning.

Developing a secure, privacy-focused app doesn’t take any longer. In fact, developing an
app without those qualities and then going back and fixing it is a much slower process:
the most sensible route you can take is to learn what you need to know before you start
working, because security and privacy starts at the planning stage.

A challenge working with security is that it’s hard to know the unknowns. Things are
not obvious: indeed the whole purpose of building an application in the first place is to
make complex things seem easy to your Users by hiding most of what’s technically
actually going on. But as the developer, you need to know these things. Hopefully this
book has been able to shed light on some of the unknowns to set you up for a sensible
development process.

Let’s go over what we’ve explored in the book.

Many decisions are made for you

Bubble and their hardware and service partners are making a lot of the decisions
related to security for you, and that’s a good thing. They’ve had decades to learn how to
protect important and sensitive information from everything from digital theft to fires
and earthquakes. By working with clients that have extreme security requirements, the

301
 The Ultimate Guide to Bubble Security

app that you create in Bubble is held to that same standard. You can offer the same
security as the big boys, because the big boys have paved the way for you. The
centralized nature of enormous server networks like Amazon AWS means that you
have access to the same protection as every other member of the network, but you only
have to pay for the capacity you actually need and scale from there, lowering the
threshold of entry to the point where everyone can afford it.

But Bubble, being a flexible platform, doesn’t force your app to be secure: while
no-code is faster and easier than traditional development, you’re still a developer. It’s up
to you to learn and implement what’s needed to keep data safe during all phases of its
management. Bubble offers the tools, but you need to learn how to use them yourself.

Actually thinking about security and being aware that a part of your application’s
development is to decide on a sensible security and privacy policy is a prerequisite for
ending up with a secure Product. No data will ever be private if you never made the
decision to secure it in the first place. Security considerations need to be with you
through all stages: planning, development and maintenance.

What you see isn’t all there is

To quote the great Daniel Kahneman in his book “Thinking, Fast and Slow”, humans
have a cognitive bias to assume that What You See Is All There Is. While he presumably
wasn’t reflecting on the nature of web development when he coined the term, it’s still

302
 The Ultimate Guide to Bubble Security

helpful: setting up a Bubble app and making it do something is pretty easy, but from a
security standpoint, what you see on the screen is not all there is.

A lot of data is being exchanged between the data and the server as your Users
navigate their way around your app, and stopping them from accessing information
they’re not supposed to have access to is a conscious effort that takes planning, a
well-structured database, an understanding of what goes on in Bubble’s JavaScript files
and in the network tab of your browser’s Developer Tools.

Security is about habits

I hope I’ve been able to instill the message that security is about habits. You don’t lock
the door to your house or turn off the stove only when you happen to remember it:
you’ve built a habit out of it because you know it’s important. In this final section of the
book, let’s go over some of the most important lessons learned that can form a basis for
good habits as you continue to develop awesome applications:

Plan. Always.
Don’t jump right into the editor and start structuring your database without a plan:
write User stories, Data stories, base your structure on the needed Privacy Rules and
think about performance.

Always move sensitive workflows to the backend

303
 The Ultimate Guide to Bubble Security

What happens on the page should not be considered secure, and Bubble has a whole
backend processing editor that lets you move these workflows over to the server.

Always stay on top of your Privacy Rules

They are the backbone of your security. Some searches don’t even need constraints if
the Privacy Rules are set up correctly. If you only pick up one lesson in this book, it’s this:
teach yourself how to use Privacy Rules. Your database is not secure if they are not set
up properly.

Never give anyone more access than they need

Whether we’re discussing End-Users or Bubble Collaborators, never give anyone more
access than they need to finish their job or for the app to complete its tasks. It makes
sense from the perspective of the User too: no one can be held responsible for
tampering with data they don’t have access to in the first place.

Secure your Bubble account

It’s the biggest security threat to your app and can potentially render every other
security measure worthless. Use a long, unique, randomly generated password and
activate 2FA. Enforce that policy on all registered Uses and teach it to your Clients.

Never keep Collaborators around when they’re no longer needed

304
 The Ultimate Guide to Bubble Security

Give them only the access they need and remove them from the app as soon as they’re
finished.

Have a deployment checklist

No change that you make in your app makes up a threat to your security until it is
deployed: have a checklist in place before deployment for things like:
● Checking all Privacy Rules
● Removing temporary data like test pages, elements and workflows
● Running the app as all User types to see how it works with different Roles and
Permissions
● Performing Initialization Clearing on API Calls
● Use the app optimizer to get rid of old data and unused fields

Solve one problem at a time

Whether you’re squashing bugs or adding new features, always focus on one thing at a
time. Jumping between tasks and then deploying them is the fastest way to lose
control of the process and forget about unfinished tasks, temporary elements and lack
of testing.

Use Save Points

Let’s face it: sometimes we mess up. We spend hours working on something only to
realize we chose the wrong solution. Use Save points to be able to go back to where you

305
 The Ultimate Guide to Bubble Security

started without having to guess the exact time or click Undo hundreds of times.
Knowing that you can go back to a state where everything was working gives you the
confidence to experiment without the fear of losing control of the app actually
working.

Hide information in your API Calls

Even the URL of the call can and should be hidden by replacing it with a private
parameter: not because showing it necessarily constitutes a security vulnerability, but
because doing it every time stops you from forgetting it the one time it’s important.
While exposing the URL or initialization data may not be a threat to your application, it
certainly has no value keeping it there unless you use those default values as fallback.

306
 The Ultimate Guide to Bubble Security

Checking your security

The Bubble agency Tinkso (formerly Ideable) have developed and are offering a free
tool that will check your Bubble app for many known vulnerability issues and reveal
what kind of data you are exposing.

Their tool is available here: https://check.tinkso.com/

307
 The Ultimate Guide to Bubble Security

Thank you for buying!

A lot of work goes into researching and writing these books, and I appreciate every
purchase and every piece of feedback.

I would love to hear your thoughts: if you’d like to give me some feedback, feel free to
use this form to share your suggestions on how this or future books can be improved.
You can follow me on Twitter to get updates on new articles and guides, and you’ll find
a growing archive of tutorials on www.amliesolutions.com.

Lastly, if you found this book useful, please consider giving it a rating on Gumroad - it
really does help me out!

Happy Bubbling!

308