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.
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 the API Token. 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.
Solution
As this is not really an issue, the way for you to fix them is to make sure they are really needed and used in your app. If they are, you can mark this issue as resolved. If not, please remove them from your application.