Josh: Request for a Security Q&A Guide

Hey @josh ,

Like many Bubblers, I have read every word of the wonderful Performance Q&A Guide you ran here earlier in the year. As someone put in there: “Best post ever!”. It was great how you stayed with the post for a few weeks to answer all the questions that came up.

Please can you now do the same for a Security Q&A Guide?

My app will store details I want to apply the maximum security to, and I am really unclear about what techniques to use or avoid.

It would be great to hear from the more experienced community members too.

Thanks in anticipation!

PS - @LucM, @gilles, @levon - did you get any further with what you discussed in 🕵️ Storing sensitive data: how safe is it? …?


To clarify, are you looking for information about how Bubble operates behind the scenes or how to approach things as a builder in Bubbler? Or both?

1 Like

Hi @dan1 - good question!
It is both - I want to understand how Bubble operates so as a builder I can store and use my most vulnerable data in the most secure way. I’m 6 months into a 12 month project, so I now have the understanding of Bubble to know the kind of questions to ask. I’m working on a list of specific questions, but while doing this I want to check where Josh is with helping us on this.

@antony The DPA page is a good start but we can look into providing more of a user-friendly 1 pager and you can email Support your list of questions.


Hi @neerja, thanks for your reply!

I’m looking for specific Do’s and Don’ts of how to structure my Bubble app for the best security of my vulnerable data, and the DPA page doesn’t quite cover those topics.

I’d also prefer to see a discussion here in the forum so that other experienced Bubblers can contribute too. This seems to be the way information on a deep subject such as this has been shared before.

Would that work for you folks at Bubble? :slight_smile:


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:


Hey guys, just a quick note to say I’ve read this. I’ve been pretty quiet on the forum lately because I’ve been a pretty underwater in terms of work – Bubble’s been growing really fast, and that’s exciting, but it makes for busy times! – and I’m behind on publishing / clarifying documentation on how to think about security as a Bubble user. I’m sorry for the under-communication on this. I’m going to try to carve out time in the next few weeks to publish a guide of some sort… I think you’re asking great questions and we should definitely have published answers for them.


Hey @josh, thanks sooo much for your post. I know how it is when your business is growing fast, so I appreciate your note here. I’m just sitting here writing a big list of my questions, and I’m sure others will chip in too, so hopefully we can all help each other out in the next few weeks! :slight_smile:


Hey @LucM, really appreciate your involvement in this thread and all the great content you posted. Looks like we’re going to get some good sharing and move things forward!

1 Like

Great Post @antony

This is going to be “The Best Post Ever”!

I have a ageing questions around security, so I’m looking forward to see this post unfold.


Hi Josh
Great to hear from you security is a big issue in the Uk with the new European GDPR Compliance rules and possible data breach fines.

Additional guidance on how to securely set up applications would be invaluable to me.

Thanks for reaching out and creating an awesome product.

Regards Dave

1 Like

@david.boggild the Privacy & Security section in the manual covers the app setup aspect. We will definitely post back with more documentation on security.

This is confusing. It says Privacy rules don’t apply to workflow, but the API workflows have a checkbox to ignore privacy rules.


@Kfawcett There are a few different concepts covered in your post.

  1. The checkbox ‘ignore privacy rules when running the workflow’ has an impact on searches required for that workflow

  2. The quote from the manual ‘Privacy rules do not apply to modifying data through workflows’ means that there is no ‘can edit’ privacy rules for data modification

  3. You might ask there is a ‘Modify via API’ available in 2^ so what is that? That is for DATA API and not workflow API.

We realize there are a lot of nuances not covered in the manual which we instead address on the forum. We are updating our documentation and welcome the community’s feedback on language change, points for expansion, and other stylistic recommendations.


Hi Everyone (and especially @josh)…

Okay, so here is my detailed list of security related questions.

To put this in context, I believe I am typical of a user that Bubble targets… someone who has the structured creativity to design an app, but doesn’t have the experience to already know the security challenges in cloud based applications. Put another way, I am an “App Designer” and not a “Software Guru”.

The Bubble Environment.
Here is a diagram of the people and technology involved in a Bubble App from a security point of view:

Server Side
On the server side we have the Bubble App sitting on an AWS server. The app runs workflows, and stores the data from our app in “encrypted at rest” form on the server. The app communicates with the outside word through four methods:

  • - for app development and support from Bubble staff
  • - for the app’s users
  • API Connector / Plugin - to initiate communication with other servers
  • Exposed API - to receive communication from other servers.

Client Side - App Users
Locally on the user’s local computer, the app can do the following:

  • Place elements which can display data from the server database
  • Run workflows which can read and write data to/from the server database
  • Store data locally in States

QUESTION 1 - When a “normal” workflow runs (as opposed to an api workflow), does it run entirely on the Client, and talk to the Server just to read and write to/from the database?
If the reality is more subtle than that, can you elaborate on the details?

Kind of Data to Protect
I can think of two types of sensitive data that my app will store:

(1) API keys for External Services.
My App Users will link my app to multiple external accounts of theirs for external services. I want to store their API keys for those services as securely as possible.

(2) “Sensitive Personal Data” about the App User’s Clients.
I can’t control what data my App Users will store, but it could sway into the area of their client’s “Sensitive Personal Data” as defined by the GDPR. Hence I would like the possibility to afford more protection to some key data fields if that is a possibility.

Possible Security Leaks
So that is fine, but what access mechanisms am I actually trying to protect this data from? Here I list the what seem like the possible leaks which are beyond the control of either the App Owner or the App User.

AWS Server
This seems a low risk since the data is stored in encrypted form and, well, it is AWS and their business is bits and bytes rather than apps… and this is their multi-billion business so I seem to trust them.

Internet Traffic to and
This feels pretty safe as it can be or is already set up under https: so is encrypted and can’t be intercepted.
SOLUTION - Make sure is encrypted.

API Requests
This is a whole brave new world for me too. I’m slowly learning about API Connector, API endpoints and Plugin development. Many thanks to the CoBubble folks for their great videos on how these things work. There is a whole second level of learning about the security side of APIs, that so far I have to trust will ensure my app data is safe.

QUESTION 2 - What is the best documentation out there on understanding the security mechanisms of API traffic from an App Designer’s perspective?

QUESTION 3 - What are the likely security vulnerabilities of API connections that I need to be aware of and careful about?

Other App Users (User B, User C etc)
SOLUTION - I feel data can be made secure from other users of my app using the combination of three techniques:
(1) Bubble’s Privacy Settings
(2a) Storing the data owner’s User record in every single Thing that my database creates.
(2b) Ensuring every search I do restricts the items returned to those owned by the currently logged in user (or their organisation head’s user).
(3) Managing the visibility of elements which display data according to who is logged in.
Hence I have at least two levels of security should one level fail due to human error.
CONCLUSION: Safe with good practices in Bubble.

App Hackers
So by this I mean:
(1) A technical bad guy who gains access to the App User’s login.
(2) Some kind of malware which is running Client Side.
(3) Some other possibility I’m not aware of.
CONCLUSION: a threat that we may want to use specific techniques in Bubble to guard against.

Bubble Staff
This is an interesting one. Bubble Staff seem to be the only people who have clear access to our entire app database apart from us App Owners. While I want to trust them, they suffer from the affliction of being human. I’m sure if they really wanted to hack our App User’s data then they could… but maybe we could make it slightly harder to do in some specific cases.

QUESTION 4 - Are there any techniques could protect some specific information easily falling into their hands? Can Bubble employees can easily make copy of our database? What can prevent that? Can we prevent them having access to the Live database unless they use a specific password we provide?

Some Specific Bubble Questions

(1) Protecting API Keys - hackers
So I will need to store the App User’s API keys for different services in some text fields in a Thing - let’s call it an “API Keys” thing.

Once a key is stored in the API Keys thing then I can make sure it is never visible again through any element in the app. So I can display it’s value as “key*********123”, and always present an empty input field when a new key is to be entered. All well and good. But…
QUESTION 5 - Can a hacker get around those visibility rules on the client machine to access those keys?

Then I need to access the key in a Workflow… but I have no idea what the security risks are here.
QUESTION 6 - is there a possibility of the key’s value being hacked if I access it within a “normal” (non api) workflow? How does my use of actions within the workflow affect this, e.g. would it be safe unless I stored it in a state, for example. Or would I really only want to use the key within an API workflow?

(2) Protecting API Keys - Users.
Okay, so I get a good solution to (1) above. Then my concern is access to the key by rogue Bubble Staff or maybe a developer I employ myself.
QUESTION 7 - is there a technique I can use to actually store an encrypted version of the key in the text field of my API Keys thing? As an App Designer rather than a Software Guru, this is something I have no real experience of.

(3) Protecting Fields Storing “Sensitive Personal Data” (SPD)
Well, I guess point (1) above doesn’t really work for SPD or the App User isn’t able to read it… so I guess we are looking more at using the techniques discussed in (2) above.

Looking forward to some good debate and detail on all of this!

Best wishes,
Antony. :slight_smile:


Hi all, sorry for being slow to respond on this. Here’s an FAQ that I hope touches on most of the main questions.

I also want to note, for the benefit of future readers of this FAQ, that we’re currently hiring engineers and plan to devote significant engineering capacity over the next year towards strengthening our security and compliance stances, so if you’re reading this, check the date on the post: we may post more updated information on our website once we’ve done more work on this.

Thanks @antony and @LucM in particular for pulling together questions. I’ve edited the list of questions to make them a bit more general, but if there’s specific things you’re wondering that my below answers don’t address feel free to write follow-ons (though it may be a bit before I reply)

What’s the difference between security, privacy, and compliance?

These three topics are related and often come up in the same discussion, but they represent different goals and mindsets. All three are important, and it’s helpful to distinguish them when thinking through how to design your app.

Security is about identifying threats to your application from potentially malicious third parties, and taking measures to mitigate those threats. From a security mindset, the goal is to prevent hackers from stealing or altering your users’ data. There’s no such thing as perfect security, but there are many things that can be done to make it harder to steal your data. When thinking about how much security is necessary, one question to consider is who is likely to be motivated to attack you. Building a system that can withstand a foreign government trying to steal diplomatic secrets is very difficult and expensive; building a system that can withstand ordinary criminals is significantly easier.

Privacy is about respect for the users whose data you are trusted with. It’s about clear, accurate communication about how you intend to use this data, and implementing systems in such a way that the data is only used in ways that you communicate. When thinking about your privacy stance, the gold standard question is “Would your users be surprised about what is happening with their data?” If yes, then there’s an ethical obligation to either communicate better so there isn’t surprise, or change the way their data is being used.

Compliance is about following laws and regulations that apply to your business. The goal of compliance is to mitigate the risk of legal penalties. There are many laws and regulations world-wide that affect the use of data, and it can be confusing to sort through them all. Laws are often worded vaguely, and often it takes a lawyer or expert in the particular law to understand how regulators and court systems will actually interpret it, especially in situations where you are located in one country but your customers are in another, or in situations where a major law such as GDPR has recently come into effect, but there isn’t much case law actually enforcing it. When considering your compliance stance, you should think about which laws are likely to be enforced against your business, and how much legal expertise you should bring in-house. This is a factor of where your business is located, what jurisdictions you do business in, what industry you’re in, and how visible / high profile you are.

All three concepts are related. From a privacy perspective, security is part of being a responsible steward of your users’ data: even if you intend to use it in a way that respects your users, if a malicious actor can steal it, then your good intentions can be undermined. And from a compliance perspective, many of the laws that regulate data storage have the goals of trying to protect security and privacy.

That said, they can also diverge. Investing in security won’t help privacy if the systems you are securing are designed to sell the users’ data to third parties. Privacy laws are often valuable for encouraging good behavior, but can also sometimes be misguided and mandate behavior that doesn’t always lead to good security or privacy outcomes. So when considering how to design systems and where to spend your energy, it’s important to be clear in your own head what privacy, security, and compliance objectives you are trying to accomplish.

What are Bubble’s stances on security, privacy, and compliance?

For security, our focus is on making the parts of the systems that we have direct control over as robust to hacking as we can. Our goal is that data should only be accessible to the people that the app creator intend that data to be accessible to. So security is a collaborative effort between us and our customers: we see our job as doing our part to make Bubble apps secure, and to give our customers the tools and knowledge to their part. That includes promoting features such as Privacy Rules that give our customers the ability to secure their app.

Bubble’s stance on privacy is that we are in the business of providing a platform and tools to our customers, not in the business of selling user data. The only benefit we try to derive from data stored on our systems by our users is improving those systems and making them more useful for our customers. We don’t sell data to third parties, and we treat data in our care with respect.

We view it as the responsibility of our customers to define the relationship with their own users: we have a wide range of apps on Bubble for all kinds of purposes, so our goal is to enable our customers to pick the privacy practices that make sense for their context.

Bubble’s stance on compliance is that we’re providing a set of tools to our users that can be used in either compliant or non-compliant ways. In general, we will not weigh in on whether a specific use of Bubble is compliant or not, because our customers are all subject to different regulations, and because we do not want to be in the position of giving legal advice.

However, we do want to make it easy for our customers to be compliant. The way we can do this is by documenting our processes and comparing them to practices required by common regulations, and getting external certifications and audits, to make it easy for customers to see if we meet a given regulatory standard. This is an area we are currently weak on and would like to invest in over the next year or two. For instance, we’ve had a lot of interest from customers in having Bubble certified as HIPAA compliant. This is something we plan to eventually do, but our current focus is on platform stability and performance, so it is not something we can take on immediately. We have invested in helping our customers be GDPR compliant: you can see our terms, privacy policy, and DPA for more information.

In addition to helping our users be compliant, we do our best to comply with all regulation that we believe that Bubble itself may be subject to. That includes US law governing technology providers, as well as the GDPR.

What is Bubble responsible for in terms of security? What are Bubble app builders responsible for?

We operate a shared responsibility model where Bubble and our customers are jointly responsible for the security of the applications they build on Bubble.

Bubble’s responsibilities:

  • Ensuring that the cloud infrastructure Bubble apps are hosted on is secure at a physical, network, and virtual machine level
  • Ensuring that data uploaded to Bubble apps is stored in an encrypted and secure manner
  • Protecting against application-level security vulnerabilities in Bubble’s editor and its run-time programming environment
  • Ensuring that Bubble’s programming language can be used to build secure applications, and making sure customers are informed on how to use Bubble’s programming language securely
  • Ensuring that third party data processors that Bubble chooses to use in order to provide its services operate to the same standards that Bubble does, and ensuring that they process users’ data in a secure and private manner

Our Customers’ Responsibilities:

  • Protecting the credentials they use to authenticate to Bubble
  • Defining the privacy and access policies for data that they and their end users upload to applications built on Bubble
  • Communicating those policies to their end users
  • Designing their applications in such a way that users can only see data that their privacy and access policies allow
  • Using Bubble’s security features, including Privacy Rules, to ensure that only authorized users can view data
  • Ensuring that any third party code or services that they install in their app or send data to via their app, including third party plugins they install via Bubble’s plugin marketplace, third party Javascript they include directly in their page, APIs they send data to, and APIs they create and expose, respect the privacy and access rules that they define, and maintain a high level of security in their operations

What are Bubble’s main security practices?

Some of the more important things we do to protect the data we host include:

  • Provide and encourage SSL encryption for apps hosted on Bubble
  • Store data encrypted at rest in our databases
  • Use one-way encryption to protect passwords
  • Use firewalls to defend our network from intrusions
  • Ensure all servers are fully patched on each deploy, and maintain the capability to patch our entire infrastructure within hours if necessary
  • Use secure operating systems (*nix-based) on all Bubble servers
  • Use vulnerability monitoring tools to detect potential vulnerabilities in our infrastructure
  • Work with security researchers to identify and resolve security vulnerabilities
  • Have defined incident management and notification processes for dealing with security incidents
  • Review new development work for security implications before releasing to production
  • Use Amazon Web Service’s state-of-the-art data centers to ensure good physical security for our data
  • Perform background checks on employees with access to customer data

What kind of data is safe to store on Bubble?

We make every effort to ensure that data stored on Bubble is safe. The goal we work for is for the answer to this question to be: “all data”. As of right now, Bubble is a nine-person team, so we don’t have a dedicated security division the way that a major tech giant does; that said, we take security seriously, and as we grow we plan to build out a world-class security function.

When people ask us this question, however, generally they are asking in a compliance context: they want to know what kind of data is legal to store on Bubble.

As explained in my answer to “What are Bubble’s stances on security, privacy, and compliance?”, we generally don’t answer this question, because the answer varies for each of our users depending on their circumstances, and we don’t want to be in the position of giving legal advice. We encourage users to assess the likely legal risks that apply to them, consult with experts or lawyers, and make an informed decision. As we grow our team and complete various certifications, we’ll update the community and let you know: as of this writing, GDPR is the only piece of legislation that we’ve developed materials for.

How does Bubble handle cookies?

Cookies are a technology used to remember a specific web browser. Bubble uses cookies to power its log-in system: cookies are how we know that when you try to visit a page, you are the same person who logged in a minute ago.

Cookies are often a concern in discussions of privacy on the internet because they are often used by ad networks and other services interested in tracking user behavior to watch what websites a person visits. However, this is just one way cookies can be used: cookies by themselves are just a way of knowing that the person who visited a page a minute ago is the same person who is visiting it now.

As an application builder, we give you a choice of setting cookies on all your visitors, or setting cookies only when a visitor logs into your app. This choice is controlled by Settings -> General -> “Do not set cookies on new visitors by default”. More information about how that setting works is here: When you set cookies on users, we allow you to optionally store data about them that persists next time they visit your app; this is necessary for logged-in users and optional for non-logged-in users.

Although privacy laws differ, generally it’s always okay to use cookies if you explain why you need them, and using them to manage user login is a legitimate purpose. You can see our terms for an example of how one might communicate the use of cookies to your users.

How do privacy rules work?

Privacy rules are the primary tool in Bubble for specifying who ought to be able to see what data. When designing an application, you should think through, for each kind of data your app will store, who ought to be able to see it. Just the user who uploaded the data? The user and certain other users who meet specific conditions? The general public?

If the answer is not “the general public”, then it is important to create privacy rules. Think of each rule you create as a reason someone ought to be able to see a piece of data. For instance, one reason might be, “I’m the user who uploaded it”. Another reason might be “The user who uploaded it tagged me”. More information on how to set up and use privacy rules is in our manual:

Privacy rules get applied whenever your app searches for or retrieves data. Behind the scenes, we add them as extra constraints to searches: if you search for all users, what we really do is search for “all users who the currently logged-in user is allowed to see”. This applies to searches on a page, as well as searches inside workflows: whenever we are running a workflow, we track who the “current user” is, and only show that workflow data that is allowed by privacy rules.

The general rule of thumb is: if privacy rules allow someone seeing data, that person can see it. Don’t rely on hiding things on a page or redirecting to a different page to protect secure data, and don’t rely on not having built a search anywhere that returns the data. Those measures might stop someone from stumbling on data accidentally, but they won’t stop someone determined to view it.

If you need to modify data that the current user is not allowed to see, the best approach right now is to use a scheduled API workflow with the “Ignore privacy rules when running the workflow” box checked. This will run the workflow entirely on the server without sending data to the user’s web browser, and it will remove the restrictions on searches, so that the workflow can retrieve data that the user wouldn’t otherwise be able to access.

How are passwords stored in Bubble?

We use one-way hashing and salting to store passwords. One-way hashing is an irreversible transformation: you cannot go from the hashed password back to the original password, so in a worst-case scenario if the Bubble database is compromised, the attacker won’t be able to see what the original passwords were. (The way we check a password is we hash the password that the user enters, and see if it matches the hash we have in the database. Since the only thing we care about is that the two passwords are the same, it’s not important to be able to retrieve the original password: that’s why one-way hashing is considered a best practice for password storage).

Can the Bubble team view our app’s data?

Yes. We view user data in order to respond to help requests and diagnose system issues. We have internal policies against accessing data except as necessary to address a specific customer need. We do background checks before hiring employees who will have access to customer data, and we take the responsibility of avoiding data misuse seriously. We plan to strengthen controls around this as we grow: for instance, we may in the future switch to an opt-in protocol where most members of the team can’t access data unless the app owner specifically consents. For now, we are a pretty small organization that works closely together, so we feel comfortable that we have a good sense of what everyone on the team is doing with user data.

Is there a way to add additional levels of protection to specific data in Bubble?

We often get asked for this in the context of particularly sensitive data that users would like to work with in Bubble. For instance, people often want to know if certain data can be stored in an encrypted format.

In general, the answer is that all Bubble data is already stored in an encrypted format, so there’s not really a sense in which something can be encrypted more than it already is. (People sometimes ask if other fields can be protected in the same way we protect passwords: passwords are a special case because they are stored via one-way hash, making the original password permanently irretrievable. See the above question about password storage).

That said, it is possible to store data in Bubble in a way that the Bubble team cannot access it. We do not currently have an out-of-the-box solution to this, and I haven’t had a chance to audit any plugins in the marketplace that offer this, but this is theoretically possible in Bubble using element plugins, in one of two ways:

  • Client-side encryption. An element plugin could encrypt data in the users’s web browser, and share only the encrypted data, not the original data or the password, with Bubble. This would require the user entering their encryption password whenever they want to access the data, because you wouldn’t want to store the password in the Bubble database in this scenario.

  • Using a third-party service that specializes in storing this data. This is how Bubble’s Stripe integration works: when you enter your credit card number, the card is sent directly to Stripe from the user’s web browser, without ever going through the Bubble server. Stripe replies with a token that represents the credit card, which does get sent to Bubble. Bubble can then use that token to ask the Stripe api to do things, such as charge the credit card.

How secure is data that gets sent to a user’s web browser?

The general rule of thumb is that if data goes to a user’s web browser, everyone with access to that computer can potentially access the data. If you want to ensure that a user doesn’t see a particular piece of data, the only way to do that is to make sure it never gets sent to their web browser, and the only way to do that is to enable privacy rules for that data and make sure they don’t have permission.

As long as you have SSL enabled, sending data to the users web browser is generally secure against interception by third parties: you can be confident that only people with access to that users’ computer can see the data.

What data gets sent to a users’ web browser?

When you are editing a page or a custom element, you should assume that every piece of data referred to on that page, including data in elements and data in workflows, could be sent to the users’ web browser. If you want to work with data that does not get sent to the users’ web browser, build an API workflow: those run entirely on the server, whereas normal workflows run in both the web browser and on the server.

When does data in the user’s web browser make it to the Bubble server when we run a workflow?

When you run a workflow on a Bubble page, Bubble runs the workflow in the user’s web browser, and it may also run the workflow on the Bubble server if the workflow has an action that requires the server. This includes things such as creating / modifying / deleting things, sending emails, processing payments, or logging in and out. If you are not sure if a workflow is running on the server, you can use your web browser’s developer tools to look at the network requests your browser is sending. Bubble will send a “” request whenever it runs a workflow on the server.

When a workflow runs on the server, all data that the workflow touches, including the contents of any inputs that the workflow references, are sent to the server.

Is connecting to an API secure?

Most popular APIs are safe to connect with. Things to check are that the API url is served over https, not http, and that the service is reputable and trustworthy. Bubble automatically protects secure API credentials that are saved in the Plugins tab in the editor. We will not send private keys to a users’ web browser: instead, if the app accesses the API, we proxy the call through the Bubble servers and add the credentials on the backend.

Some users build apps that use dynamic credentials, where every user who connects to an API uses a different set of keys, and store those keys in the database. It’s safe to do this as long as you are very careful with privacy rules: you should make sure that only the user who uploads their keys can view those keys.


Thanks Josh. As always, a very informative post.

I hope in the future the privacy rules will allow more complex conditions like the below screenshot.


Hey @josh,

Thank you soooo much for your amazingly detailed reply. I feel it answers all my questions for now, and the details about keeping sensitive data to an api workflow was particularly useful. Your intended focus on security in the coming year is really great to hear.

I’ve taken a huge leap of faith in choosing to base my whole new business venture on Bubble, and it is moments like this where I really feel safe and fully supported in my decision. Thank you.

I also felt much more secure about Bubble as a company to hear how you are growing and how you plan to use those resources. It would be great to get some kind of “What’s Happening at Bubble” newsletter now and again to keep your loyal fans up to date.

Here’s to a great year with Bubble in 2019!

Best wishes,
Antony. :slight_smile:


Thanks Josh for the clear and concise information related to security on Bubble. Its exciting to see what the future holds in improving compliance and scaling security management.

Excellent response, @josh, thanks for taking the time to fill us in with these details. I’ll certainly be chewing over!

I do understand the importance and mechanics of the privacy settings in the data tab on who is able to view what. However, I can use some guidance as to whether I am naively exposing data via API’s, which I’m not so sure on.

As an example, I connect through Stripe via cobubble’s plugin to process credit card payments. If I have the below image as my current settings in the API tab in Settings, am I inadvertently making all the checked data type information public, or is the checked data types only “public” to API’s that I choose to directly connect with?

My apologies on a potentially newb question, but I really want to be vigilant that I am doing the right thing.

Lastly, does bubble, or other companies bubble trusts, offer to test privacy and security of bubble apps? This would be extremely valuable to have someone attempt to “maliciously” fetch data, and then report back the types of data they were (or weren’t) able to obtain so that we know where the leaks are coming from.