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: https://bubble.io/reference#ApplicationSettings.cookie_opt_in. 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: https://manual.bubble.is/working-with-data/privacy-and-security.html
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 “https://your-app-domain.com/workflow/start” 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.
), 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.
Bubble no matter what ; I’m just not quite sure.
