Security
This page lays out best practices when it comes to making your app and your data secure.
Enable SSL
SSL ensures that the data transmitted between the server and the browser is encrypted - make sure to set it up by checking the box located in the Settings > Domain/email section of the Bubble Editor.
Create privacy rules
Having robust privacy rules is essential in making sure that your server doesn't set data to a browser that the user is not supposed to see. See link below for more information about setting those up.
We also have a video walkthrough for Bubble Privacy Rules.
No "paywall" popups
In Bubble, you can create a popup that blocks the user from visually seeing or interacting with the page. However, these popups can be closed relatively easily using Developer Tools in the browser.
To put this in specific "Bubble-ese": you shouldn't rely on a popup with the setting This popup can't be closed by pressing Esc to lock users out of pages.
Don't store sensitive data in an unencrypted format
If your application needs to store very sensitive data, like Social Security numbers, credit card numbers, etc. in encrypted format. Better yet, find another company (like Stripe or Paypal) that can handle these very risky transactions, and integrate them into your app through Bubble plugins or using the API Connector.
Bubble does encrypt all data at rest, which makes data storage and data usage more safe if you have authentication and privacy rules properly set up. But if you've accidentally made your privacy rules more loose than they should be, someone may get a hold of your data. We would recommend encrypting the values that go into those sensitive fields yourself and then decrypting them before they're used.
Set minimum password requirements
Use the Define a password policy functionality found in Settings > General section of the Bubble editor to set the minimum length, capital letter requirements, etc.
We recommend setting a minimum password length of 8 characters and requiring 1 capital letter and 1 number.
Don't use private API keys/tokens on the page
If you need to make an API call that uses a secret key or a token, make sure that it's not populated on any page but is instead in one of these 2 places:
In the API connector, marked as "Private"
In a backend workflow
This will ensure that the user's browser never sees the API key/token.
Forum resource
If you're interested in learning more about how Bubble secures data in general, and some other security recommendations, you can read these security guidelines from early 2019 posted in the Bubble Forum by Josh (Bubble CTO and co-founder).
Testing privacy rules
To test whether privacy rules are set up correctly, it can be helpful to use a web browser's developer tools to examine what data is available to the user. Here's a page that shows how to do that with Chrome.
Scanning files for malware
When users have the ability to upload files to your app that other users can download, ideally they should be scanned for malware. Some API based solutions for this include Scanii and Cloudmersive. Filestack also offers this option along with their file storage service, but is quite pricey.
This will help protect both admin users and standard users - if admins open these files somewhere in the admin portal or are sent these files via email, that would be an issue.
Note that some browsers (e.g. Chrome in Windows) have some built-in file scanning ability as well to prevent downloading files tagged as malware, so there are some built-in protections here for many users.
Risks from plugins and custom code
Using community plugins and custom HTML in your Bubble app carries some inherent security risks with it.
One of those risks is that the plugin developer could be malicious and steal data from you, like by tracking all browsers which load the plugin on the front end.
XSS (cross site scripting)
Another risk is the possibility that plugins will allow raw user data to run javascript in other users' browsers.
Bubble's native elements should all have protections built in to prevent users from executing javascript when users' data is shown to other users. Plugins, however, may not all have this set up. (The Bubble HTML element, of course, is an exception here, as it is intended to be able to include HTML and javascript.)
This is a risk when showing data on the front-end to users - for example, if I have a calendar plugin and I use it to display data from many users to each other, it's possible that one user will enter some executable code in a text field and that the plugin will execute that code when trying to display it. There are many different ways to exploit XSS vulnerabilities, so the specific ways to test this will not be covered here.
CSV injection
When allowing for CSVs of user-entered data to be downloaded from an app, programs like Excel will read Formulas that are included in those CSVs. If a user's "About" field has a formula, they can use it to execute programs outside of Excel, or hit APIs and export the app data. More info about the vulnerability here: https://owasp.org/www-community/attacks/CSV_Injection
For a Bubble-specific guide on how to deal with this bug, see here:
This is a known bug with Canvas' CSV export flow in the admin portal. We've decided to leave this vulnerability there for the moment, as it would add quite a bit of complexity to the app to remove it. All app admins should be made aware of this vulnerability.
Unsafe HTML in emails (phishing)
Emails can be used as a vector to steal user data, user credentials and other sensitive info. This relatively simple attack has been the cause of several high-profile cybersecurity breaches over the past few years.
Block all iFrames of app
If your app allows other websites to display it in an iFrame, then other developers can much more easily impersonate your website or use its content to show on their own websites. Impersonating your website is useful in the case of a phishing attack.
It is okay to allow all iFrames or iFrames from the same origin if your app has a valid reason for doing so and you are aware of the minor risks involved. Otherwise, it's best to block all iFrames of your site.
Last updated
Was this helpful?