Plugin Security

Plugin builders
1

Hey everyone,

We’re avid plugin developers and we enjoy the whole process of taking on requests and sponsors, pushing out plugins and continually maintaining them as needed. Recently, we’ve realized a measurable surge in inquiries regarding the security of plugins developed by Bubble plugin developers such as ourselves. After some research and communication with the Bubble team, we’re now opening up the conversation to the rest of the Bubble plugin development community about the what Bubble team can and should do with respect to the security of sensitive fields for plugins.

What are best practices for handling plugins that require sensitive data?

There are four common fields exposed to Bubble Developers when implementing a Plugin. In order to best extract the information shared, you should be familiar with the Plugin Editor, frontend development and related terminology.

Element Fields
A function runs whenever a value in these fields has been changed. Useful for manipulating the DOM quickly, such as re-rendering elements including Stripe’s Payment Request and PayPal’s Checkout buttons. This exposes fields to the Client, which could contain sensitive data such as Secret keys but can be dynamically set.

Element Actions
A function executed in a Workflow when added via Workflows > Element Actions. Useful for initiating single actions, such as tokenization for Stripe’s Sources and event registration for Segment. This exposes fields to the Client, which could contain sensitive data such as Secret keys but can be dynamically set.

API Action (Public)
An HTTP request executed in a Workflow when added via Workflows > Plugins. Useful for initiating single actions, such as customer creation for Stripe’s Customers and event registration for Segment. This exposes fields to the Client, which could contain sensitive data such as API keys but can be dynamically set.

API Action (Secret)
An HTTP request executed in a Workflow when added via Workflows > Plugins. Useful for initiating single actions, such as customer creation for Stripe’s Customers and event registration for Segment. This does not expose fields to the Client, but can also not be dynamically set.

We’re all looking for ways to make plugins more useful, friendlier and approachable. We’d love to ensure that the fields we’re setting are kept safe and secure from interception or other harmful means. :facepunch:

3 Likes
2

Thank you for asking this question, this is indeed important as the plugin ecosystem grows. In general, when it’s about security with plugins, there are 2 different cases:

  1. Stuff that the plugin builder needs to do to make sure the API credentials, etc. are secure
  2. Stuff the application building needs to do to make sure their users’ data/credentials are secure

The general rule is this.

  1. If the data/credential to be secured is hardcoded in the app by the application builder, the plugin builder needs to make sure these keys are marked as secure in the plugin editor. So this applies to API keys and keys as defined in the Shared tab. So for instance, if when using a plugin, the user enters his key in the Property Editor for an action, that means the setting isn’t right. It should be a key and made secret, and defined by the application builder in the Plugins Tab.

  2. If the data to be kept secured is user-dependent, the responsibility here is on the application builder, and they need to make sure they have the right privacy rules in place to make sure the data isn’t exposed to the wrong user. The plugin builder here doesn’t have to do much when building the plugin, the property on the action, for instance, does not have the concept of private/public.

I hope this is more clear, happy to elaborate more if this isn’t clear yet.

5 Likes
3

Very pleased to see this conversation taking place.

Almost by definition, most/many users of the Bubble platform (myself included) rely on core Bubble and the plugin developers to provide a secure environment as we are not developers trained to know which data can (or needs) to be sent to the client.

My needs as an app editor are:

–Ability to have external app id’s and secret’s kept out of the view of anybody but our developers, AND have different values for dev and live versions.

–Ability to have access tokens as well as parameters set dynamically through the database, as they are user level items. I do not know enough to comment on whether or not those access tokens need to also be private, but I would sure like best practices to be followed.

–Clear labeling of the different types of data within the ecosystem, with documented, consistent, absolute (not general) rules regarding the impact of using each.

–I don’t know anything about the approval process for plugins, but it would be nice to know that if approved, it has passed some sort of security check to know that some bad actor has not inserted a sniffer of some sort, sending data back to the plugin developers server (No offense to our wonderful plugin developers who would never do that!)

At that point, it becomes my responsibility to appropriately use each.

–Ken