API Connector security
This section covers security related to the API Connector plugin.
Last updated
This section covers security related to the API Connector plugin.
Last updated
This article covers the security aspects of using the API Connector plugin specifically. If you want to learn more about the API Connector in general, you can check out the articles below:
Article: The API Connector Article series: API
The API Connector is Bubble-made plugin used to make to external apps and systems. The API Connector is designed to automatically manage many security aspects and defaults to strict security settings to prevent unintentional vulnerabilities.
Still, as with any other area of app development, it's essential for you, the app developer, to ensure the API connector is configured securely and to familiarize yourself with best practices in this domain.
In this section, when we say "API keys," we're talking about all generated tokens used for authentication. This includes not just traditional API keys, but also OAuth tokens, JWTs (JSON Web Tokens), secret access codes, and other authentication credentials.
Many services that you connect to using the API connector will generate one or more API keys that you use to your requests.
API keys are unique strings of letters and numbers that act like a password or a digital handshake between applications. They grant access to specific functionalities and data within an API service, allowing your app to talk to that system seamlessly.
Just as you wouldn't want to leave your home key under a doormat for anyone to find, it's crucial to keep your API keys hidden and secure.
If they are exposed, malicious actors can misuse them, potentially leading to unauthorized access, data breaches, or unexpected charges if the API has associated costs.
By ensuring API keys remain private, you're safeguarding the relevant API connection.
Some ground rules for handling API keys in Bubble:
❌ Option sets ❌ In on-page workflows, elements and dynamic expressions ❌ In app texts (translation strings) ❌ In custom states ❌ In URL parameters ❌ In the names and/or labels of your workflows, elements, pages, data types/fields and option sets ❌ In the default values of your data type fields
❌ Chat channels ❌ Forum posts ❌ Social media posts ❌ Screenshots
API keys should be handled like you would handle the passwords of your most important logins.
Parameters in an API call are essentially pieces of information you send along with the call to either request specific data or provide some context. If the recipient recognizes the parameters, they can then tailor the response to fit your requirements. For example, if you're calling an API to get weather information, a parameter might be the city or postal code. If you are calling an API to create a new user in an external app, parameters might be the email address and name of that user.
Where are parameters included?
Parameters can be placed in various parts of an API call:
URL Parameters: Often seen in the URL itself after a "?" symbol. For example, api.website.com/data?city=NewYork.
Header Parameters: Included in the request header, often used for authentication or specifying content type.
Body Parameters: Used in POST requests, where data is sent in the request body. Useful for sending more complex data like JSON objects.
Why set them to private in the API Connector?
In the API Connector, setting parameters to "private" removes it from your app's code files and makes it inaccessible to end-users. This is possible because API calls by default are routed through Bubble's server. This allows us to store the parameter only on the server and include it as needed when the call is made.
This is particularly important for sensitive info. For example, you wouldn't want to accidentally expose an API key or confidential data. Keeping parameters private ensures they remain a secret between your app and the API.
In the example above, we've ensured that a parameter in the Header is private. But what about parameters that you include in the URL? Just like header and body parameters, they too can be set to private. But before that, they need to be parameterized.
Let's first look at an insecure parameter included in the URL:
The information above would be visible in your app's code file on the user's device. In many cases there is nothing wrong with this, but in the example above, we have included some sensitive information: an API key.So how do we hide it?
Note the text on the right-hand side of the URL input form that says (use [] for params). This tells us that we can use brackets to turn a string of text in the URL into a parameter, that can then be set to private. Let's see what a more secure way to send the parameter would look like:
In the example above, we wrapped the URL parameter inside of brackets, and Bubble automatically creates a parameter below with an input field for both the key and the value. This allows us to set the parameter to private keeping it hidden from the app's users.
You can set up more than one bracket in each URL, and even turn the whole URL into a private parameter if you prefer to even keep that hidden.
This section gives a brief introduction to how API calls work. If you want to learn more about how API requests and responses are structured, as well as the HTTP protocol, you may be interested in reading our extended section on how APIs work.
Article series: Introduction to APIs
Article: What is a RESTful API?
Article section: What is the HTTP protocol?
An API call happens in two stages: there's the request and the response. In the case of the API Connector (making outbound calls), your Bubble app (the client) is always the one making the request, and the server you are communicating with (the server) is sending the response. The entire process is transferred via the (and in most cases encrypted with SSL/TLS), just like when you load a web page.
To learn more about the different parts of a request, we recommend the article listed above. In the table below, we've listed the short-form explanation for each, along with common security recommendations:
| Part | Purpose | Security Considerations | Recommendations |
|---|---|---|---|
Contains for the API call | Can reveal information about the request, e.g., | Avoid sensitive info in custom headers | |
Contains the main content of the request/response | Transmits the actual data, which can be sensitive | Avoid including information that the API server doesn't need. | |
Indicates the type of request (e.g., GET, POST) | Certain methods (e.g., POST, PUT) may change data on the server | Use the appropriate method for the task; Avoid using methods that change data unless necessary | |
Specifies the endpoint and sometimes parameters | Parameters can expose sensitive information if not set to private | Use the to mark parameters as private Avoid placing sensitive info directly in the URL | |
Details for specific queries or actions | Can be crucial for data operations | Make sure parameters don't leak sensitive data Use private when necessary |
Keep in mind that while the information in a call may be encrypted with while in transit, the receiver of the request (the server) will decrypt all the data included in it. While most API services can be trusted to handle that information securely, it's still best practice to not include more information than is needed. That's why our recommendations above encourage you to follow that practice.
This is in line with .
To enable a specific API call, you need to it. If the call includes parameters, you need to assign a to these parameters that Bubble can use when the initialization is done. The default parameters become part of your app's code base, and can be viewed on the device of the user.
Do not store sensitive information in this field
If you prefer the value to not show up anywhere, you can delete its content after the initialization is done
When using the API Connector, many of the settings you will use with that API are not set on Bubble's side, but in the dashboard of the API provider. To maintain secure connections, it's important to go over these settings and ensure they are properly set up. Settings are sometimes connected to one specific API key, meaning that you can use different keys with different settings to maintain flexible security.
Note that the different settings and features available in each API service can vary.
Many API services offer settings for limiting the permissions of a call, such as which applications can use the key or which API services the key can call. We recommend setting permissions to the strictest possible setting that lets you successfully run the call you need.
Many providers have , or allow you to set your own rate limits in order to maintain an expected volume of calls or stay within a budget. Learn how to set and view rate limits set by the API you're connecting to. This prevents overwhelming the server, overspending your budget and potential IP blacklisting.
Many API services keep detailed logs of every request and response that goes through their platform using your authentication. Learning to use the audit logs helps you stay on top of all the data that is exchanged, as well as debugging errors. Logs and analytics can also help you identify unusual patterns that might indicate malicious activity or potential vulnerabilities.
If an API token somehow ends up in the wrong place, we strongly recommend immediately logging into the relevant API service and disabling it. With most services you can then generate a new one, making the old API key useless.
