A roundup of latest security improvements

Hi everyone,

My name is Lindsay, I’m a product manager working on security here at Bubble, and I’m excited to share some important security updates we’ve been working on over the past six months.

At Bubble, our goal is to make security a natural part of the building process. That means adding defaults and features that help guide you toward security best practices from the start, and strengthening our security dashboard (formerly Flusk) to scan your apps and alert you to potential vulnerabilities.

We’ve been working closely with security researcher @georgecollier (thanks, George!) to identify and implement key security fixes. We also actively work with and encourage other researchers to find and report issues. [See more here.]

Below are some of the updates we’ve completed over the past few months.

Editor and platform updates

API security improvements

  • By default, new API workflows won’t be accessible outside of a Bubble application unless you explicitly choose to make them public. This lowers the chance that you’d unintentionally expose an API workflow that could be discovered and exploited.
  • Similarly, Hide Swagger API is now set to true by default in the settings tab, which limits the amount of information available about your API workflows.

New security features

  • We’ve enabled a “log out of all devices” feature for customers with dedicated environments on the enterprise plan (it was already available on the main environment). This helps protect your app’s end users — if one of their accounts is compromised, they can change their password and force all active sessions to log off, ensuring an attacker loses access immediately.
  • You now have the option to disable the file upload API endpoint that allows unauthenticated users to upload files to your app. Note that unauthenticated uploads are still allowed by default, so you’ll need to configure this option if you want to block them.

Infrastructure and platform protections

  • We’ve updated settings on Cloudflare to make Bubble applications more resilient to certain types of attacks. One example: stronger protections against unauthorized eavesdropping of network communication between a user and your app (also known as “strict transport security”).
  • We’ve made two-factor authentication more resilient against automated attacks, helping prevent unauthorized access and keeping your accounts better protected.

Security dashboard updates

Head to app.flusk.eu (and scan.bubble.io in a few weeks) to run a security audit on your app with the security dashboard — we’ve made several updates to make it more useful and user-friendly.

New look and feel

  • We’ve added a new security dashboard entry point on the projects sidebar, with more editor entry points coming soon.
  • We’ve redesigned the way our tests are run so that users can choose which branches, data types, and pages to check during each audit.
  • We’ve updated the privacy rules checker design to improve accessibility.
  • We’ve fixed several bugs and updated the issue description language to make the issues clearer.
  • Finally, we’ve rebranded Flusk to the security dashboard and have aligned all designs with our design system to make the security dashboard look and feel like part of Bubble.

New security checks

A security check is a scan our security dashboard runs within your app to make sure it’s secure.

  • Unsafe API call configuration: How you set up authentication in the API Connector is important for keeping your external API calls secure. If an API call is set to Use as: Data and uses certain authentication methods (None, self-handled, or OAuth2 User-Agent Flow), the call skips Bubble’s server-side validation and privacy rules, which could expose sensitive data. The security dashboard now flags these unsafe configurations.
  • Stripe secret key in the wrong field: If a Secret key is mistakenly entered into a public-facing field (such as Client ID or Publishable Key), it becomes exposed to users or clients, even though the setup may still work. This misconfiguration can lead to serious security vulnerabilities, including unauthorized access to your Stripe account.

What’s coming next

  • New domain: We’re moving from app.flusk.eu to scan.bubble.io.
  • UX improvements: We’re planning updates to make the security dashboard more intuitive and easier to use.
  • More entry points: We’re also adding additional entry points to make the security dashboard more accessible.

As always, we’re committed to making Bubble more secure and helping you build with confidence. If you have questions or feedback, feel free to share them below!

Lindsay

15 Likes

:clap: :partying_face:

2 Likes

Will it be possible to use an authorization header (bearer) or api key in url to continue to use this endpoint from plugin or even from outside Bubble but keep this secure? At the moment, it’s doesn’t seem possible…

Thanks to care about security and thanks to @georgecollier to contribute to this

4 Likes

Thank you to everyone involved for your continued efforts, especially in this area of ​​security.

One question: I don’t see any place to manage team members in the same app. Will this be restored in the next update?

1 Like

Yes!!! This needs to be done. When they first announced that a lot of users @lindsay.esterman highlighted this need

1 Like

Awesome. Next up on the list should be better scoping of API tokens. It doesn’t need to be crazy modular with 100+ settings like certain other products, but it shouldn’t be all-or-nothing either. Right now it just gives too much access. There should be 2-5 levels of access and ideally you should be able to set privacy rules on API tokens.

This is a relatively quick win and much-needed.

Edit: This too. Essential for 3rd party integrations like sending private audio/video/images for AI processing.

6 Likes

@randomanon coming with good ideas

1 Like

I agree, but I also believe that Bubble should automatically create (or have an action for) an API token for each user in DB. This could be used for plugins (including API Connector) or just for easy integration from external services like Zapier or Make. Actually, the password flow is not the best option from my point of view.

6 Likes

I’m gonna edit that into my post. Totally true. Also applies to AI generation/processing. You want to send a private video/audio to an external service? You either have to use a weird hacky workaround or compromise security or both.

1 Like

Could this update explain issues here

and here

@lindsay.esterman ?

1 Like

Great work!

@lindsay.esterman

The language around the “API workflow protection” error is misleading, and the error is likely falsely flagged. As an example, an API workflow with the following settings:

image

Reports the following error in flusk:

This is incorrect. The error is likely firing due to the presence of “Expose as a public API workflow”, but it DOES in fact have authentication (not only is “This workflow can be run without authentication” unchecked, but the condition presents its own authentication). The last section is also unclear, and should probably read something like:

”If not, uncheck This workflow can be run without authentication. Optionally, create a new API token in settings and use it when calling the endpoint”

1 Like

Security dashboard is unaware of the contents inside workflows. Only what’s exposed publicly. In addition make sure you’re looking at the same version in Bubble as the scan in security dashboard

Fair, but the first part is definitely a bug. And yeah, version matches. In this case, it flags on both main and live.