API Connector security

This section covers security related to the API Connector plugin.

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.

Handling API keys

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.

Authentication identifies who the client is and authorization determines what they should have access to.

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:

API keys should never be stored in places that can be revealed in your app's source code, such as:

❌ 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

API keys should not be shared with anyone outside of your team - do not share it in places such as:

❌ 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

What are parameters?

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:

1. URL Parameters: Often seen in the URL itself after a "?" symbol. For example, api.website.com/data?city=NewYork.

2. Header Parameters: Included in the request header, often used for authentication or specifying content type.

3. 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.

By checking the Private box, we make sure that the parameter is kept hidden away on the server, invisible to your end-users. When the call is made, the parameter is sent from Bubble's server to the API service.

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.

Making URL parameters private

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.

API call structure and security

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

Don't send the server more data than is needed

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 .

Default parameter values

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

Sometimes you'll need to include one or more parameters when you initialize a call. You can remove these values after it has been initalized to avoid them being visible anywhere in your app's code.

External API dashboard settings and features

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.

Limit Permissions

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.

Rate Limits

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.

Get to know audit logs and analytics

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.

FAQ: API Connector

What should I do if I misplace an API token?

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.