Securely using API Keys from a Frontend No-code App

API keys are a fundamental component of modern no-code development. Without them, no-code tools wouldn’t be able to communicate to other services and data sources.

For example, a frontend app made with WeWeb wouldn’t be able to communicate to a Xano backend securely without an API key (or its cousin, the authentication token).

Everything that is stored in a frontend app is visible to a user, even if not displayed on the page. One could think that storing API keys in a frontend app, like in WeWeb, might be a major security breach then?

Well, yes and no, as they’re several ways to handle this. Let’s see them.

What are Public and Private API Keys

Tools that are supposed to be used in frontend applications often use what we call public and private API keys.

What are they?

Public API keys are designed to be shared with third-party developers and are often used for accessing non-sensitive data such as read-only information (like weather information or stock prices). They are also used to recognized who’s doing the API call (be it a user or an app). Public keys are typically freely available and can be used by anyone, making them an easy way to distribute data and promote the use of an API.

Private API keys, on the other hand, are intended to be kept secret and are used to access sensitive data or perform actions on behalf of a user. Private keys should never be shared, and developers must take great care to keep them secure. When using private keys, it's essential to implement proper authentication and authorization mechanisms to ensure that only authorized users can access them.

Public and Private API Keys: The Stripe Example

Let’s use the example of Stripe. As you may already know, Stripe is a payment processing system that allows you to let your user pay for your services in an app. Payment data is indeed very sensitive, that’s why Stripe gives us a public and private key.

‍

‍

In Stripe, both public and private API keys play different roles and are used for different purposes. They are part of the authentication mechanism that allows you to interact with the Stripe API securely. Here's a breakdown of the differences between public and private API keys:

1. Public API Key (also known as the publishable key):

• This key is intended to be used in the client-side code, such as in web or mobile applications.
• Public API keys are used to create tokens or sources, which represent sensitive customer information, such as credit card details. The token or source is then sent to your server-side code for further processing.
• It's safe to include the public API key in client-side code, as it has limited permissions and cannot be used to access sensitive data or perform critical actions, such as creating charges or refunds.
• Public API keys typically start with the prefix "pk_" followed by a series of alphanumeric characters.

1. Private API Key (also known as the secret key):

• This key is intended to be used in your server-side code and should never be exposed to the client-side or public-facing code.
• Private API keys have full access to your Stripe account and can be used to perform various actions, such as creating charges, managing subscriptions, and processing refunds.
• As the private API key has access to sensitive information and can perform critical actions, it's essential to keep it secure and prevent unauthorized access.
• Private API keys typically start with the prefix "sk_" followed by a series of alphanumeric characters.

In summary, the public API key is used for client-side interactions and has limited permissions, while the private API key is used for server-side interactions and has full access to your Stripe account. It's crucial to ensure that the private API key remains confidential to maintain the security of your Stripe account.

So, we’ve observed that most tools implement a public and private key, but how to use them?

How to use Public and Private API Keys?

Using public and private API keys is rather simple.

When you’re building the client-facing side of the app (typically, the web app’s frontend, or mobile app), use the public key.

Why? As we’ve seen before, all API calls that are made from a frontend can potentially be intercepted and decrypted by simply watching them (for example, using the developer tools in your browser).

‍

‍

Then, only use the private key through a backend. It could be a Xano endpoint, a Make automation, a custom server. Anything. The only thing is to use the backend as a proxy when doing API calls that would need to private key.

Here’s a schema of how it would work:

‍

‍

Remember to only store the public API key as a variable in the frontend, while storing the private key on the backend. And you’re good to go!

⚠ One thing though: do not exactly mimic the 3rd-party tools’ API (endpoints, authentication, etc). Otherwise, a hacker might do malicious API call to your backend by just following the 3rd-party tools API docs! Add some security by making the endpoints hard to discover, add rate limits/security on the backend based on the current user, etc.

That said, some tools don’t use this system and only provide one private API key. How to handle this use-case?

What to do if the tool provides only one Private API key?

Some tools, like Airtable, only provide one API key, which has unlimited permissions, and should be considered a private API key.

ℹ️ As a rule of thumb, when a tool only has one API key, consider it as private.

For these tools, you should never make API calls to them from a frontend app. You would need to use a backend that would act as a proxy (like we’ve seen before).

Nevertheless, at least in WeWeb, you could use our plugins to avoid this issue. Indeed, when you use our plugins, we store the API keys on our own servers, and proxify the API calls for you, automatically.

That’s why WeWeb Stripe’s plugin asks you for both public and private API keys, or why we have an Airtable plugin. We’ll spin up a server for your app which will be called when you use the plugin’s actions in your workflows.

‍

‍

Keep in mind that it’ll only work when using the plugins, though. When using the REST API or GraphQL plugin, everything will be sent from the frontend. So for tools like Airtable, always use the plugin!

In conclusion, doing API calls to 3rd-party tools from a frontend app like WeWeb is secure, as long as you use public API keys. When you have to do a sensitive API call needing a private API key, or for tools that have only private API keys, use a backend as a proxy or WeWeb plugins. By following these best practices, you can ensure that your application is safe and secure, while still taking advantage of the power and flexibility of APIs.

‍