Bubble API Tokens are 32-character keys used to authenticate API calls with your Bubble app. They serve as a way to verify whether a requester has permission to access resources and workflows in your app.

A Bubble API token grants the bearer full administrative access to your app, equivalent to the level of access you have as the app builder. This means any client with the API code can

This issue is flagged to highlight the presence of an API token in your app and to remind you of the extensive access it grants. This ensures you can make an informed decision about whether to retain or remove the token based on your app’s security needs.

This issue will be triggered if:

Bubble API tokens grant broad access to your app and its data, but their use isn’t inherently wrong. The purpose of this issue is to help you evaluate whether this level of access is necessary or if you can configure an alternative setup that limits access while still meeting your app’s requirements.

The Login action enables users to access your app by entering their email and password, typically through a login form where the user submits their credentials. However, Bubble also provides the option to pre-fill this data using static values, allowing you to specify the email, password, or both directly within the action.

This can lead to two vulnerabilities:

This issue is flagged to notify you that one or more Login actions in your app have credentials pre-filled. This setup may pose a security risk, as it could potentially lead to unauthorized access or expose sensitive information.

This issue will be triggered if:

We strongly recommend against pre-filling login credentials in your app, as this practice can introduce significant security vulnerabilities, as outlined in the overview. Instead, allow users to enable the “Remember me” option, which securely stores their email in a cookie on their device after they log out. While there may be specific edge cases where pre-filling is considered, it’s generally unnecessary and poses avoidable risks.

Even with privacy rules in place, data “leaks” can occur if the rules are not properly configured. Various scenarios can lead to unintentional exposure of data, and while these might seem like rare corner cases, they are more common than you might expect.

This issue serves as a warning that Flusk was able to access data marked as sensitive while logged out, highlighting a potential gap in your app’s privacy configuration. It is not directly based on checking your privacy rules but rather on identifying exposed data during a logged-out state.

The purpose of flagging this issue is to indicate that a non-logged-in user may have access to data marked as sensitive, potentially exposing information that should be protected.

This issue will be triggered if:

This issue highlights that sensitive data is accessible to non-logged-in users, but it is not tied to any specific privacy rule misconfiguration. While we provide potential solutions in this section, it’s important to note that not all scenarios may be covered. We strongly recommend reviewing our comprehensive guide on privacy rules to help identify and resolve the issue.

To learn more about how privacy rules, check out the article below:

Article: Protecting data with privacy rules

Bubble allows you to secure the test version of your app (commonly called version-test) with a username and password. However, if you use the default credentials, there is a risk that someone could gain unauthorized access to the test version simply by guessing them.

The default username and password is username and password.

The purpose of flagging this issue is to remind you to change the default and set your own unique credentials instead.

This issue will be triggered if:

To solve this issue, do the following:

Allowing your app to be rendered as an iframe introduces several security vulnerabilities because it exposes your application to manipulation by external websites. Here’s a breakdown of the potential risks:

The purpose of flagging this issue is to inform you that your app currently allows rendering as an iframe, which could expose it to vulnerabilities like the ones outlined above.

This issue will be triggered if:

Similar to other potential vulnerabilities, allowing iFrame rendering is not inherently harmful. However, if you are not actively using this feature or are unsure of its purpose, we recommend disabling it to minimize the risk of vulnerabilities like those outlined in the overview.

Bubble allows you to set a password policy in your app, that forces all users to use a password that:

These four options can be configured independently, allowing you to require any combination of them, from just one to all. Not enabling this feature allows users to set weak passwords, such as common dictionary words or names, which can be potentially guessed or brute-forced by malicious actors.

The purpose of flagging this issue is to make you aware that your app currently doesn't have a password policy set.

This issue will be triggered if:

Note that it will only trigger when all options are empty. In other words, it can still be worth looking over your password policy eve if Flusk is not flagging the issue.

We recommend implementing a password policy for all apps that handle sensitive information, as users often choose short, easily guessed passwords, such as common dictionary words or names.

We recommend setting a password policy that requires a minimum of 8 characters, including at least one number, one uppercase letter, and one special character.

If a specific data type is not meant to be public, you need to define privacy rules to protect it. Flusk automatically identifies data types that don't have privacy rules set up, based on:

You can read more about how to set field sensitivity in the article below:

Article: Flusk database rating

The purpose of flagging this issue is to identify data types that have sensitive fields, but are not protected by privacy rules.

This issue will be triggered if:

You can read more about how to manually mark data types in the article below:

Article: Flusk database rating

We strongly recommend setting up privacy rules for all sensitive data types.

To learn more about how to protect your database with privacy rules, see the article below:

To learn more about how to mark data types as safe/sensitive:

Flusk currently evaluates pages in two ways:

If a page is sensitive, it should contain an action that uses server-side redirection to redirect users to a different page, such as a front page or 404 page.

The purpose of flagging this issue is to identify sensitive pages that don't have a proper redirect action.

This issue will be triggered if:

You can read more about how to manually mark data types in the article below:

Article: Flusk page rating

We strongly recommend setting up a server-side redirect action on all pages that contain sensitive information.

To learn more about page security, read the article below:

To learn more about how to mark data types as safe/sensitive:

Bubble provides the option to open your app editor to other users, allowing them to view and/or edit your application. This feature can be helpful for showcasing the editor publicly or collaborating with others to resolve specific issues.

However, granting open access to your app editor poses a significant security risk. It provides unrestricted access to all aspects of your app, including sensitive data, workflows, and settings, which can expose your app to potential vulnerabilities or misuse.

The purpose of flagging this issue is to make you aware that your app is currently allowing anyone to view and/or edit the app.

This issue will be triggered if:

We strongly advice to use this setting with caution, since it gives a very broad access level to all users who know the URL of your app.

If you want to collaborate with other users in your app without opening the editor up for anyone, you can consider using the Collaborator features instead (see below).

To learn more about how you can collaborate with other users when building your app, see the article below:

Just like the data in your database, uploaded files can be secured using privacy rules. These rules ensure that even if someone obtains the file’s URL, they cannot access the file unless the privacy rules explicitly grant them permission.

This rule needs to be set both in the privacy rules, and the relevant file uploader element, making it easier to miss.

This issue is flagged to inform you that one or more file uploaders in your app are currently set to upload files without the protection of privacy rules, potentially leaving them accessible to unauthorized users.

This issue will be triggered if:

If a file uploader element is intended to upload private files, follow these steps to ensure the files are properly secured:

Note that you need to set up your privacy rules to make sure that only the right users have access to the file. You can read more about this in the article listed below.

To learn more about how to set up privacy rules, including protecting uploaded files, see the article below:

Just like the data in your database, uploaded images can be secured using privacy rules. These rules ensure that even if someone obtains the file’s URL, they cannot access the file unless the privacy rules explicitly grant them permission.

This rule needs to be set both in the privacy rules, and the relevant picture uploader element, making it easier to miss.

This issue is flagged to inform you that one or more picture uploaders in your app are currently set to upload files without the protection of privacy rules, potentially leaving them accessible to unauthorized users.

This issue will be triggered if:

If a file uploader element is intended to upload private files, follow these steps to ensure the files are properly secured:

Note that you need to set up your privacy rules to make sure that only the right users have access to the file. You can read more about this in the article listed below.

To learn more about how to set up privacy rules, including protecting uploaded files, see the article below:

Privacy rules consist of two types of rules:

Privacy rules operate in a way where the most “permissive” rule takes precedence over others. This means that if the everyone else rule grants access to sensitive data in searches or fields, that data will be accessible to everyone, even if more restrictive dynamic rules are in place.

This issue is flagged to highlight any instances where the Everyone else rule is set to allow users to View all fields. This setting could unintentionally expose sensitive data to unauthorized users, bypassing the more restrictive privacy rules you may have configured.

This issue will be triggered if:

We strongly recommend setting up privacy rules for all sensitive data types.

To learn more about how to protect your database with privacy rules, see the article below:

To learn more about how to mark data types as safe/sensitive:

This issue is flagged when a public parameter is identified as potentially sensitive.

Since sensitivity is determined by Flusk’s prediction model, there may occasionally be inaccuracies. If you believe this parameter is not sensitive, you can choose to disregard this issue.

Sensitive parameters often include items like API keys, private unique IDs, endpoints, or any other information you would prefer to keep private.

This issue is flagged to alert you that at least one parameter in your API Connector calls is not set to Private, making it visible and potentially exploitable.

This issue will be triggered if:

There are a few possible solutions to this issue:

If you need dynamic content in the parameter, Private needs to be unchecked, but you can safely clear the initialization value.

To learn more about how the API Connector works, and how you set up secure calls, see the articles below:

By default, the endpoints specified in your API calls are not private and can be accessed by anyone who knows their location.

This may not pose a significant risk when working with third-party services that require additional authentication to access data. However, it can become a security concern when calling an endpoint that does not require authentication, as it may expose sensitive information or functionality.

Flusk leverages AI to identify API endpoints that may be sensitive. However, it’s a good practice to review all URL endpoints in your app, even those not flagged by Flusk, to ensure they don’t inadvertently expose sensitive information or functionality.

The purpose of flagging this issue is to make you aware that Flusk's AI model has identified at least one URL endpoint that can be made more secure by hiding it.

This issue will be triggered if:

There are two different solutions to this issue:

To secure the URLs in your API calls, you can implement a workaround by defining the endpoint URL as a private parameter within the API call. This approach conceals the URL and helps to keep it private, reducing the risk of exposure.

Here's an example:

Before:

In this example, we already have a parameter set up (param1), but the URL is not concealed.

After:

By replacing the URL with a parameter (in this case we've called it URL), you can store the URL as a hidden parameter instead. Make sure to check Private to hide the parameter. This way, it will not show up in your app's codebase.

If you don't consider the URL sensitive, you can click the Ignore button in Flusk's Issue explorer to not see it again.

Activating the Bubble API allows external systems to interact with your application through various queries. Swagger provides a way for your API to describe itself automatically, enabling other systems to understand its structure and available queries.

While the Swagger file is not inherently a security vulnerability, hiding it is a form of obfuscation. Obfuscating the Swagger file can make it slightly more challenging for an unauthorized user to identify and access your API endpoints, adding an extra layer of complexity for potential intruders.

Article section: What is the Swagger specification?

This issue will be triggered if:

Like we mentioned in the overview, the Swagger documentation is not in itself a security vulnerability, but leaving it visible makes it easier for a potential intruder to identify your API endpoints.

If you have no use for it, or are unsure about what it does, we recommend hiding it.

To learn more about the Swagger documentation and what it's for, read the article section below:

Article section: What is the Swagger specification?

To learn more about the Bubble API in general, check out the article series on that subject:

Article series: The Bubble API

The Assign a temp password to a user action allows you to generate a new password for a user, enabling them to log in to their account and update it with a personal, unique password. However, if this action is executed client-side, there is a risk that the randomly generated password will be visible in the Network tab of your browser's Developer Tools.

The purpose of flagging this issue is to highlight instances in your app where a randomly generated string is being used in conjunction with the Assign a Temporary Password to a User action. This setup could potentially expose the temporary password to unauthorized access, increasing the risk of it being intercepted or stolen.

This issue will be triggered if:

This action should in most scenarios be executed server-side, using the backend workflow editor. This ensures that the password is generated on the server (as opposed to on the user's device), and does not become visible in the browser's developer tools.

To learn more about how to set up API workflows, see the article series below:

Article series: The Workflow API

Bubble provides two distinct environments for your app: Test and Live. The Test environment is designed for previewing and testing your app during development, allowing you to experiment and refine features. The Live environment is what your end-users interact with — it represents your fully deployed and operational app.

The test version of your app can be password protected, and we strongly recommend doing this.

This issue is flagged to inform you that the test version of your app is not password protected, allowing anyone with the URL to access it.

This issue will be triggered if:

We strongly recommend always password-protecting your test version, to make sure that no one can access it without authenticating.

Bubble allows you to add collaborators to your app, enabling efficient teamwork and problem-solving during development. However, retaining collaborators indefinitely can pose a security risk.

Flusk helps mitigate this risk by letting you mark collaborators as approved or unapproved, ensuring you maintain control over who has access to your app over time.

The purpose of flagging this issue is to identify non-approved collaborators that still have acess to your app.

This issue will be triggered if:

There are two ways to fix this issue:

Keep in mind that once a collaborator is marked as approved, Flusk will no longer flag this issue for that user. Therefore, it’s important to only approve collaborators you trust and intend to keep involved with your app long-term.

If there's no reason for the collaborator to have access to your app anymore, you can remove them.

To integrate Google Maps into your Bubble app, you’ll need to input a Google Maps API key into the Bubble editor. Keep in mind that this API key is publicly accessible, which means it could potentially be discovered and misused by unauthorized individuals.
​

The purpose of flagging this issue is to notify you that your Google Maps API key is not restricted to your app’s domain, which leaves it vulnerable to potential misuse by unauthorized parties.

This issue will be triggered if:

Flusk performs this test by locating your API key, and sending a request from a different server. If the request goes through, the API key is vulnerable for misuse, and the issue is flagged.

This issue is a bit differerent from most Flusk issues, as it's not fixed in the Bubble editor, but in your Google Cloud Console settings.

The Bubble API allows you to set up API workflows that can be triggered either by your app or external clients, such as other systems or applications. However, if an API workflow is configured to run without requiring authentication, it can be executed by anyone who knows the endpoint. This can create a potential security vulnerability, as unauthorized entities could exploit it to interact with your app.

The purpose of flagging this issue is to notify you that one or more of your API workflows have the This workflow can be run without authentication option enabled. This setting allows anyone with the endpoint URL to execute the workflow, potentially exposing your app to unauthorized access.

This issue will be triggered if:

There are two ways to solve this issue:

If the workflow doesn't need to be executable without authentication, you can disable this option.

Note that some requests, such as webhooks, may still need to be able to access the workflow. If so, use the method below.

If a client needs to access the workflow but cannot log in as a regular user (such as for webhooks), consider securing the workflow by requiring a Bubble API key. This adds an additional layer of security while allowing external systems to interact with your app.