Bubble security tips

Bubble security is a natural early concern as you approach the platform for the first time. So just how secure is Bubble? We’ll find that out – and how you can set up your app to be as secure as possible – in this article.

Most of the applications that we use every day have moved from your computer to the cloud. We no longer store our contacts, recipes, diary pages, projects, tasks and workout logs in files on hard drives in our home office, but in centralised server parks that are optimised for performance, uptime and security.

As that revolution in computing is nearing completion, we’re starting to see the shape of another one: no-code makes app development so easy that more and more people are moving away from off-the-shelf software and developing their own tools instead. 

It makes sense – why go for one-size-fits-all when you can have a tailored fit for the same or lower price?

While no-code platforms like Bubble.io are easy to learn, there’s still a question that many new users ask: just how secure is the data that my app manages?

The question naturally branches out to the choice of framework: Is Bubble as a platform secure? The short answer is yes, Bubble has great security in place that your app inherits (you can read our in-depth guide on Bubble security if you are interested).

But to truly understand what Bubble security is all about we need to dive a little deeper. Are JavaScript, Python, PHP and Ruby secure languages? Most would say the question doesn’t really make sense. The language itself is not secure per se, but allows you to create secure applications if you put together the correct lines of code. The security in the end is up to the developer.

No-code platforms like Bubble follow the same logic to some extent. It will not set up your app’s security for you, but it gives you an advanced set of tools to do it yourself. The key difference between coding and no-code is that the former requires the developer to study and learn complex best practices to keep data secure, while platforms like Bubble have a robust set of security features at your disposal. Important decisions are made on your behalf, the software is constantly patched and kept up to date with the latest security updates and Bubble itself relies on third parties like Amazon and Cloudflare to host and back up enormous amounts of data securely.

Still, the comparison with traditional coding serves a purpose: Bubble balances flexibility and security. If the platform was too secure by default, it would be too rigid to allow the creation of such a wide range of different apps. To give you as a developer flexibility, you are allowed to set up apps that are insecure. Bubble offers powerful tools to avoid it, but doesn’t force you to use them.

So we can conclude that even if no-code has a much gentler learning curve, that doesn’t mean there’s no learning curve. Bubble gives you the tools, but it’s up to you as the developer to use them correctly.

Keep reading the article for the top tips for setting up secure Bubble applications. If you take security seriously and want to promise your users their data is securely managed, you can also take a much deeper look at it in the book The Ultimate Guide to Bubble Security. Here we lay out Bubble security tools over more than 300 pages.

Plan your app for Bubble security

The first point is obvious but still often overlooked. Creating apps and structuring your database in Bubble’s visual editor can be an incredibly fun and satisfying experience, but if you jump right into building without planning you’re bound to make mistakes that can take a lot of time to correct afterwards.

So what does planning mean?

Planning comes down to knowing which questions you need to ask about your own application:

• What kind of data will my app manage?Is it private? Public? Most apps fall somewhere in between: some data (like the articles in a newspaper or the products in an eCommerce store) need to be public, while other kinds (a user’s contact information and purchase history) have to be kept strictly private. Some data changes as it moves through a system: a blog post can be private while it’s a draft, but public once it’s published.
  
• How are my pages different from a security perspective? One page (such as your front page) may be public, but another (the app itself or a dashboard) requires the user to be logged in to see it.
  
• What kind of users will my app have? You can think of users having different roles and these roles come with different permissions. Some roles are there by default (such as users being logged in or not) while others are set up by the developer (such as admins).

We’ll get back to several of these questions later in the article. For now, take note of the most important point: planning is essential to set up secure applications.

Secure your Bubble account

Have you thought about how secure your Bubble account is? If not, do it now. Access to your Bubble account is the single most important security hole you need to close. Think about it – anyone with access can make any change they want to any version (test/live) of any one of your apps. That’s a scary prospect that deserves a thorough review – especially if you’re working with clients.

So what does this mean?

• Use a secure password (a long, cryptographically random string)
  I strongly recommend using a password vault like www.1password.com to generate strong passwords and store them safely.
• Use 2-factor authentication. It drastically increases the security of your account.

Set the same policy for your team and clients

A chain is only as strong as its weakest link. If you feel safe that your own account is now secure, keep in mind that it has to apply to every member of your team. Set a clear, easily understandable security policy and enforce it, so that you can rest assured no malicious party will ever be able to exploit one weak link.

If your clients have or will have access to the app on their own at some point, assume that they don’t know the importance of security in general. Be a serious freelancer/agency and a good consultant and advise them on the importance of a strong account security policy and what exactly the consequences can be if a malicious actor should gain access.

Set a clear and systematic Collaborator policy

The Collaborator feature is incredibly useful. It allows you to bring on a freelancer, coach, client or stakeholder and give them direct access to the editor. But just like your account, it comes with obvious security risks. The level of access you grant a Collaborator should be based on a clear policy, and that policy should be based on one simple rule:

No Collaborator should ever have access to a single byte more than they need to solve your problem.

Let’s look at what that means in practice:

• Never give your collaborators admin access unless there is a very specific reason to do so
• There’s rarely any need for a collaborator to have access to the live version of your app
• Access to write to the database may be necessary, but don’t default to it
• Consider the logs/queries: will they give your collaborator access to private information?

Make it a habit to give collaborators the minimum access level you know that they need, and then grant additional permissions if the need arises.

Lastly, the biggest vulnerability with collaborators is usually not the adding – it’s the keeping them around. Make it part of your policy to know when to remove the collaborators again. Use a task system or calendar events if needed.

Stay on top of your app settings to maintain Bubble security

Now that your account is secure and you have control over collaborators, it’s time to look at the settings of the app itself.

The most basic part of your app’s security is set in the Settings tab of the Bubble editor. Let’s quickly go over the most important potential vulnerabilities.

• Set the Editor Access Permissions to Private App
• Set the Limit access to this app in run In mode with a username and password to yes to keep the app between you and whoever should have access
  • Change the default username and password
• If you have connected to a domain, always enable SSL encryption
• Disable the API features you are not using, and don’t enable any Data Types in the Data API that you don’t want to grant access to

With all the basic app settings done, let’s have a look at the development side of things.

Understand the difference between client-side and server-side

These two terms are fairly self-explanatory, but since they have a massive impact on app security, let’s go over their meaning to avoid any misunderstandings.

Your app consists of two geographically separated parts: the client (which is the user’s device) and the server (the computer where your application is stored). Everything that happens on the user’s device is described as happening client-side and everything on the server happens server-side.

In very brief terms, everything that happens server-side is considered secure, while everything happening client-side is considered insecure. Why? Well, because everything happening on the client is controlled by the client. What that means is that it’s manipulable: a hacker can take any piece of data or a process and make changes to it, since it’s all resting on their laptop.

Following that line of thinking you may ask: does that mean my entire page is insecure? And the answer, in principle, is yes. Everything that reaches the user’s device is potentially insecure, and that includes everything that is visible and invisible on your page.

Wait… doesn’t that make my entire app insecure? No – keep in mind that everything resting on the server is perfectly secure. The trick is to stop information that the user shouldn’t have access to from ever reaching the user’s device. This is why we use Privacy Rules to secure the database; because it makes absolutely sure that a piece of information from the database never reaches a device unless the user has authenticated themselves and is authorized to access it. We’ll get back to that later.

Other data that reaches the page

For an application to work, a lot of stuff has to be downloaded to the browser. Images, fonts, videos – these all need to be transferred from the server to the client in order to be used for anything.

But that’s not all. Bubble’s engine is split into two parts: one is on the server, doing all the work related to the database. The other one is a file saved on the user’s device. These two are in constant communication to make sure that everything works. When your user clicks a button for example, the engine on the device sends a command to the engine on the server to let it know what to do.

And what did we agree upon earlier? That everything that reaches the page is insecure. What does that mean in this case? Bubble is of course a no-code product, but Bubble itself is written in code: JavaScript to be precise. What this means is that the engine that rests on the user’s device is a javascript file fully readable by anyone who downloads it by opening up your app. That’s not a problem in itself, but there are a few things you should be aware of. This code contains a lot of information about your app that you may not be aware of:

• The names of all pages
• The names of all elements and workflows
• API Connector initialization data and names
• All Option Sets and their content
• The names of all your Data Types, fields and default values
• Style names and information

This is not all the Javascript file contains; you can find the file using Chrome Developer Tools and inspect it if you’d like. You can check out our guide on Bubble and Chrome Developer Tools if you’re interested in learning more.

Learn to use Privacy Rules

Privacy Rules govern what data in your database one specific user is allowed access to. For example, one Privacy Rules can tell Bubble that only one type of user (logged in users) are allowed to download one type of data (food recipes). Another can make sure that one User can only download food recipes that they themselves created. 

Privacy Rules are applied on the server, meaning the data is kept completely secure as it never leaves the encrypted hard drive of the Amazon AWS cloud. They are also applied app-wide meaning that if you set them up once, they apply everywhere.

Privacy Rules are the foundation of your app’s security, and it can’t be said clearer than this: without them, your data is not secure. To learn more about them, you can check out our free in-depth guide on Bubble Privacy Rules.

Use server-side conditions on workflows

Your app consists of workflows and actions: these are the gears that keep your application running. They tell Bubble what to do as the user interacts with elements on the page, such as saving something in the database or navigating to a different page.

To stop workflows and actions from running unless specific requirements are met, we use conditions. These are ways to tell Bubble to only run this action if this condition is true.

Bubble needs to be able to confirm the condition on the server for it to be secure. In other words, the condition cannot rely solely on things happening on the page, but should optimally be able to check data stored in the database. Why? Because the page is insecure: it can be manipulated by a skilled hacker. The database on the other hand is kept stored in securely encrypted form far away from the hacker’s reach.

What does that mean in practice? Checking whether an element is visible or not is something happening on the page. Checking whether the Current User is an admin or not is happening on the server. The logic of the latter is that the condition relies on information stored in the database. We know that the integrity of the database is constant, and that the information is encrypted – so we can trust Bubble to verify that information in a place that a hacker cannot reach.

Always rely on data that can be checked in the database for conditions that need to be secure.

Set up a deployment checklist

The moment when you deploy your app is when you’re at your most vulnerable. This is the point from which your live users will see every change you made since the last deployment. Most developers don’t keep close track of all the changes they make in-between cycles of deployment. It’s perfectly understandable: no-code is so fast to work with, documenting everything in a document or project management tool is often more time-consuming than the work itself.

We may be great developers, but we’re also people: we miss and forget th things. That’s why a good checklist is so important. Keep it a live document and revise it as needed.

The following list is by no means exhaustive, as all projects are different. But it gives you an idea of what a checklist can look like:

• Thoroughly test all new features
• Double check Privacy Rules
• Test the app as different user types (logged in/not logged in/different user roles)
• Delete test pages
• Remove app collaborator Users
• Run the App Optimizer
• Delete initialization data from the API connector 

Set up the policy, adjust it as needed and never skip it. A rushed deployment that opens up a security vulnerability can have consequences that far outweigh the importance of launching features fast.

Use auto-binding

When you make changes in your database based on input from the user, these changes can be made in two ways: you can save it using actions, or you can save it using auto-bind. Auto-bind means that whenever an input field loses focus, Bubble will save its content to the database.

Is auto-binding more secure than actions? Technically no. But they have an advantage in that they reduce the total risk area of mistakes from the developers. Let me explain:

Any action that makes changes to the database can be secured with a condition such as Only when the Current User is logged in. Is this secure? Yes. Bubble will check this on the server before it allows the action to complete.

But this condition will need to be set up for each and every action that makes these changes. A developer may forget it in one single action. Accidentally change it. Accidentally delete it. It provides a larger area of error, since there is more to keep track of for the developer. It also means that should your security policy change, the change will need to be made across a range of different actions, again opening up for human error.

How is auto-binding different? Auto-binding can be controlled with Privacy Rules. What this means is that you only ever have to set your policy in one place, and it will apply all across your app. This is faster, gives less room for error and is ultimately more secure (even if both methods offer the same technical security).

Does this mean that you should always auto-bind and never use actions? No, keep in mind that security is not your only concern. There are plenty of scenarios where a Save button attached to a workflow is the better option from a UX perspective. But by knowing the security implications, you can make an informed decision in every instance to balance the scale of security and UX.

Set up server-side redirects

Whenever a User tries to access a page they shouldn’t be allowed to, you use a redirect to move them away from that page. For example, if the user of a Project Management Platform tries to access their dashboard without being logged in, you would usually direct them to a login page.

What you may not know is that there are actually two kinds of redirects: server-side and client-side. And as usual, the one happening on the server is the more secure.

Server-side redirects

Server-side redirects mean in practice that as a user tries to access a specific page, the server blocks the access and sends the user to another page before the page has a chance to load a single byte. This means that no information about the page whatsoever is ever sent to the browser, and is kept securely on the server the whole time.

Client-side redirects

Client-side redirects happen on the user’s device. In practice, Bubble runs a snippet of Javascript code in the browser that tells the browser to open up a different page. The consequence then is that the page needs to be loaded for this to happen, opening up for a malicious actor to stop that process or to access all the data that was sent to the browser as the loading took place.

To be clear: using Privacy Rules, your page should already be secure. There should be no private information there for any hacker to find, even if the page does load.

But security is about making everything as difficult for the hacker as we can. Access to the page might give them some piece of information that they can use for something else. It also gives you another level of security should you make a mistake like misadjusting a Privacy Rule. So let’s keep them out altogether.

What separates the two? Bubble will mostly attempt to perform a server-side redirection whenever it can (it’s also the least taxing method from a performance perspective). But sometimes, a page is set up so that a redirect needs the page to be loaded before it can be executed. This depends on how you set up the action to begin with. A simple workflow like the one below will almost always run server-side:

But if you choose another type of event or you start adding more complex conditions to the workflow, Bubble may be forced to load the page before it can determine whether to run the workflow.

How to determine your page’s redirect type

How the page redirects is identified in the HTTP protocol, which is the line of communication between the browser and the server. A successfully executed server-side redirect will have the status code 302, meaning that the server tells the browser that the page has temporarily moved.

If you get a response saying 200, it means that the page did not redirect. 200 does not actually mean client-side redirect: it means that the page was successfully loaded. And then it was redirected, regardless of the status code. You can check your page using a status checker like SureOak’s 301 Redirect Checker.

Designing for Bubble security

Security is not only about the technical aspects of your application. It also means you need to give thought as to how your app is designed.

As an example, why are passwords not shown on screen, but simply replaced by asterisks like ****? The answer is of course obvious: developers realised a long time ago that users needed to be protected against themselves. Computers, tablets and phones are used in all sorts of places: the office, the park, the airport and the local Starbucks. If passwords were to be shown in plain text, millions of passwords would be stolen every year simply by hackers looking over the shoulder of a user as they type it in.

This decision is of course made for you. But have you ever thought about how other design decisions might affect security? 

• What exactly do you show on the screen as soon as the user has logged in?
  Are you revealing private information? If your app is handling sensitive data, give some thought as to what exactly you are displaying the second after the user has logged in. Consider allowing the user to choose to display the information or not by requiring one more click of the mouse for example.
• Is there information in your app that should require additional security?
  If you are storing highly private information like a social security number or an API key, you may want to ask the user to log in one more time to prove that they are who they say they are. Check the password once more to avoid data leakages because the user left the screen for a few minutes.
• Should the user be logged out after a while?
  By default, users will be logged in for quite some time (12 months) after logging in. If your app is handling sensitive data, you may want to force a shorter logout time.

These are just a few examples of designing with privacy in mind. If your app has thousands or even millions of users over time, assume that they’ll put their laptops and phones into all sorts of risky situations. Be a good developer and close that window for them. 

Conclusion

Bubble security is all about you as a developer. You are allowed to set up apps that are not secure at all – that’s what flexibility gives you. What this means is not that Bubble is insecure, but that it’s your job as a developer to learn as much as you can about potential security issues so that you can make informed decisions while you develop great apps.

The paradox is that it’s hard to know what you don’t know. This is why it’s so important to seek out information, ask experienced experts and talk to the Bubble team to reveal those shortcomings. Don’t feel bad about it. There’s not a single thing in this life that I knew before I knew it. That’s what learning is all about. Both the Bubble forum, Bubble support and Twitter are great ways to ask experts. You can also book a Bubble coaching session to get help with your app directly.

This post gives you a short and quick overview of many typical security pitfalls, but to really dig into how to build truly secure Bubble applications, check out The Ultimate Guide to Bubble Security.