Security: How to manage API Tokens on Bubble

Hi all, Wesley from Flusk here :wave:t3:

Today I’d like to share with you some insights, tips and tricks about Bubble API Tokens, that can be way more dangerous than what people use to think.

Here’s a quick summary of what we’ll cover in this lesson:

  1. API Tokens - Generic Description and use-cases
    1.1 What’s an API Token?
    1.2 How to create an API Token in my Bubble app?
  2. API Tokens and their associated security risks
  3. How to mitigate risks when dealing with API Tokens
    3.1 Using 1 API-Token per 3rd-party service
    3.2 Removed unused API Tokens
    3.3 Do recurring checks
    3.4 Use Flusk

API Tokens - Generic Description

What’s an API Token?

Bubble API Tokens are 32-character tokens that are used to authenticate with your Bubble app using API Calls.

Let’s take a really precise example:
Let’s say you have a Bubble App A that wants to query the User database of a Bubble App B.
The App B has privacy rules defined on its User data type so by default no one is able to query it unless it’s an admin.
Forget about the “App Connector” feature that would simplify our use-case here.

For the App A to be allowed to query the database of the App B, the App B needs a way to know if the requester is allowed or not.
This is what API Tokens are here for. They are the keys of the castle.

If the App B receives an API Call containing a valid API Token, this means the requester is allowed to query the database.

Often, API Tokens are used to give 3rd-party services the ability to trigger API Workflows on your app. Stripe is a very common use-case.

How to create an API Token on my Bubble app?

To create an API Token in your app, you’ll need to navigate to “Settings > API” and you’ll find them under the “API Token” section.

You can then give it a name, and the value next to “Private key” is your API Token.

API Tokens and their associated security risks

These API Keys gives a full admin access to your app.
As mentioned in Bubble’s manual:

Using an API Token gives a client full administrator access to your database. This means that privacy rules are ignored and the client gets the same access level that an admin gets in the Bubble editor.
:link: Bubble Manual about API Tokens

One having a valid API Token for your app could perform the following actions:

  • Read, delete or edit all your database and data types
  • Trigger all publicly exposed API Workflows
  • Ignore all Privacy Rules

The golden rule when dealing with API Tokens is that you will give 1 unique API Token per 3rd-party service.

For the following reasons:

  • If something bad happens, you know who did it by looking at the API Token used to perform the malicious actions.
  • If you don’t use a 3rd-party service anymore, you can just remove its independent key and don’t have to update it on all the other 3rd-party services you’re still using.

If your business case needs several services to authenticate with your app via multiple API Workflows, you would create 1 API Token per service:

All good, all clean!

How to mitigate risks when dealing with API Tokens

Using 1 API Token per 3rd-party service

As mentioned earlier, this is much needed.
One API Token for Stripe, and another one for Xano.
They should never share the same token.

Removing unused API Tokens

This is the second golden-rule.
As soon as you’re not using a 3rd-party service anymore or that it doesn’t need authentication to your app anymore, remove it API Token.

This is super important.
Having keys that roam in the wild is never a good thing and could come to hands of people you don’t want them to have your secret keys.

So whenever you’re not using a 3rd-party service anymore, please delete the associated API Token.

Do recurring checks

As you might forget to remove the API Tokens of a 3rd-party you don’t use anymore the day you don’t use it anymore, we suggest you to do recurring checks to make sure all the API Tokens present on your app are actually used.

A good habit is to do it every month.

Use Flusk

At Flusk, we’ve set up a security checkpoint specifically for API Tokens.
As soon as we detect a new API Token created on your app, we’ll ask you to approve it.

On a monthly basis, we’ll also ask you to manually review all of your API Tokens to make sure none of them is roaming in the wild.


I guess this is it, Bubble friends!
Hope it helped, and talk to you soon.

Wesley Wasielewski
CEO & Co-founder at Flusk

:closed_lock_with_key: Automated Security Audits for Bubble.io apps
:chart_with_upwards_trend: Advanced Logs Monitoring and Error Handling for Bubble.io apps
:bird: Twitter/X Account with many Bubble.io security tips

With :heart:


Bubble is a very safe platform in itself.
Most security issues come from people who develop apps using Bubble and:

  • Don’t follow security guidelines
  • Don’t have the necessary resources and tools to check their security

Let’s keep trying our best! :heart_hands:

12 Likes

I don’t understand this, if you haven’t enabled the Data API, does it mean that admin authentication doesn’t allow access to anything?

It allows authentication to your public backend workflows with no privacy rule constraints.

1 Like

Assume I have an app with zero public backend workflows and the Data API unchecked, what then?

Unrelated to the API key but make sure you have solid privacy rules and then those are the big three security items checked off.

If your Data API is disabled and have no public BEWF, then the API key won’t be of any use.

And make sure your app’s editor isn’t public :wink:

1 Like

That’s actually kind of a relief because it would let me upload private files to 3rd party APIs.