Security in front-end projects

👮 - Keep your project secure

Front-end projects can be very insecure when dealing with external API keys or secrets.

Keep in mind that every key you use in a front-end environment is directly exposed to the browser, so there is a series of considerations to take into account when working in a project of these characteristics to keep them away from possible wrongdoers.

🕵🏻‍♀️ - How do I know if my keys are exposed?

To know for sure if any of your keys are exposed, open your project in the browser, go to inspect -> source and hit ‘Search’

This is going to make a search in all of your source code. Paste in there the key you want to check, for instance, this is a key from AirTable that was exposed to the browser:

🙊 - How do I protect my keys?

There are several steps and procedures to protect your keys and ensure there is no malicious access to them.

1. 🔒 Restrict your key’s access

Most sites give us several options to restrict access for the keys we are generating. The most common ones are choosing if our keys are going to have only reading access or reading and writing access.

This is important. You might be tempted to give all permissions to your key to ensure it works, but it is a better practice to only allow your key to make the job it needs to do. If you only need to retrieve information from a database, do not give the key access to write on it, you are opening a door that does not need to be opened.

📖 If my key is read-only, does it matter if it is exposed?

At first glance it might seem that if your key does not have access to write on the database and it only reads data that is intended to be public, anyway, it can be exposed on the browser and it does not matter, right?

Well, it might not be giving more access to the hacker than it would have from merely accessing the site where the information is published, but it does give them an extra tool to work with:

• it is easier to to make scraping bots that use the key
• it is easier to brute-force your database and hit rate limits because of bots repeatedly making requests using your key directly
• it is easy to make changes to the database, add data that should not be public, and forget that the key has access to everything
• the key might appear as a leaked secret in public scraping tools and hurt your SEO and reputation

So, it is worth it to secure the key anyway.

💻 Are there keys secure to use in the front-end?

Yes, some sites, like Supabase, make keys that are intended to use in the client-side.

This is because the access control is made inside the platform. In this case, for instance, the access is managed through RLS policies (Row Level Security) that fine-tune who can perform which actions in the database.

It is important when using these type of keys to pay attention to the policies provided by the platforms to control access.

2. 📄 Use environment variables

You should be using environment variables to store your keys. These variables are pieces of data available to your whole project.

In your local development process, you should create a .env file that will not be uploaded to the repository and that will contain your variables, for instance, your keys.

This file will never be uploaded with the rest of the files in the repository and should be added to your .gitignore file. Every developer working on the project should have a .env file in their filesystem that will not be shared.

Refer to our Environment variables instructions to learn more about them.

🔑 How and where do I access my variables in the code?

The environment variables that contain your keys should be accessed ONLY in server-side files. So, if you are working with a library that needs to instantiate a client, such as AirTable, and uses their key to create that client, you need to make this instance in a server-side file.

If you are working in a Nuxt / Astro project, make sure to only access your keys in your server folder: you will need to perform all operations regarding the key in an API call that you will later on use in your code instead of using the client directly.

Also ensure that your API call is protected using your Bearer tokens or any means of authentication present in your site.

If you do not have any authentication system in your site, you can protect your calls by using CORS headers or rate limiting through services like Redis.

If you are working in a pure client-side project like a Vue project for instance, you need to make use of your deployment service’s serverless functions (in this case Netlify). These functions are executed on their server-side and can be used like an API call would be.

You can see code examples of both of these in our AirTable and Supabase blog posts.