Josh: Request for a Security Q&A Guide

Hi @antony
Thanks for bringing back this discussion! :raised_hands:
+1 for your request, that would be great!

For those interested: @josh’s Performance Q&A guide

I think this new Q&A could result in a document-guide and answer considerations form these 2 posts, starting with:


  • Data storage / encryption
  • Setting security (Privacy roles, conditions, redirect, two-factor authentification…)
  • Server-side vs client-side


  • Compliancy (GDPR, PCI, HIPAA, Privacy Shield…)
  • Cookies
  • Servers (location…)

Hi @neerja! In addition to this more global Bubbler Guide, I believe it would be of great help to have a text regarding security characteristics that Bubblers could literally paste in their apps to inform their users :ok_hand:

Unfortunately, my topic didn’t get much traction, so I ended up contacting the Support. Here’s their answer (dated July 2018):

Should we implement specific things (else than privacy rules)?

We take security very seriously (our largest client deals with personal financial information we have to be careful with this). The most important thing you can do security-wise is define some rules on who can see which information. This is an advanced feature, but you can do this in the Data Tab > Privacy. These rules are checked server-side for a higher security. We are not able to recommend other services or implementations beyond the privacy rule functionality that we provide.

Infrastructure-wise, Bubble is hosted on AWS West Region (Oregon, US; this can be customized if you’re a on Dedicated Plan) which maintains a state-of-the-art security infrastructure. We encrypt all traffic to over https, and encourage and support our clients to use encryption on their own domains. All user passwords are stored salted + encrypted in our database; other user data is encrypted at rest (we’re on AWS RDS). Our servers use up-to-date, patched versions of Linux and they are constantly updated. You can add a SSL connection to your own domain under any paid plan.

Should we draw the line somewhere (else than medical and credit card)?

We do discourage users from storing credit card information as well as medical information. Note that we are not HIPAA compliant: HIPAA compliance requires each process and component to be compliant not just the associated storage. So unfortunately, the platform as a whole is not yet HIPAA compliant even though based on Amazon S3 documentation, the storage used for your data might be.

Again, we are not able to recommend what to store and not to store on your site, but rather can provide you with all the documentation you require to make these calls yourself.

Although that was helpful (and fast! Thanks Support Team :pray:), we are still unsure if Bubble is a good fit for this specific project of ours, but we decided to keep working on other parts of the MVP while still considering this.

I read that we should not store sensitive personal data (see section 13 of Privacy | Bubble). But in the mean time I see that an important Bubble client stores personal financial information. So I’m wondering what I’m missing, if they used extra security layers or maybe I’m misinterpreting what sensitive means.

Really I’m oscillating between thinking Bubble is fine for building “leisure” apps (think Airbnb, Netflix, Upwork, Twitter, etc. which don’t really use critical data) and “serious” apps (regarding the data. Think passwords as LastPass, accounting as Freshbooks, lawyers, etc.).
And I would love :sparkling_heart: Bubble no matter what ; I’m just not quite sure.

Basically, I guess what I am trying to understand is what makes it OK to store tasks, products or food recipes in Bubble, but not Social Security Numbers or passwords.
This is very certainly a newb question, but to me storage is either secure or it is not. It doesn’t correlate to the type of data. Why should I treat my food recipes differently than my passwords? I mean, if I decide they are not OK to be shared, they should be so equally, independantly of their nature.
What I do get instead, is that in case of a breach, the consequences won’t be the same.
Well, for a starter, my 3-chocolate-cookie will get a larger audience :cookie: