How to improve the security of your frontend
Using AWS Secret Manager, we believe the API KEY we can simply leave it statically in the code, today I bring you an idea on how to deal with this problem.
Published Mar 15, 2024
Today we are going to discuss a topic that we often overlook, security in frontend applications (also applicable to backend). We believe because they are API KEY we can simply leave it statically in the code, today I bring you an idea on how to deal with this problem.
Read the full version in Spanish here:
During the application development process, you have surely had access to third-party service credentials (API KEY) that should only be used for test environments (localhost).
Sometimes a new member in to the team or someone leaves the team, keeping those credentials secure and up-to-date has always been a headache for every security person on the development teams.
The first thing any security analyst will see about your frontend application is to look for sensitive data that the end user can have access to, just by doing F12 (developer console) you can enter and see the LocalStorage.
Do not do it, please!
Remember that fronted applications are packaged and delivered to the browser completely, therefore by simply examining the code we will have everything that the application contains, this point It is key for when you want to do something like in your .ENV, bad idea to use it.
Don't do it!, since by doing so you will be exposing those credentials to any user of your website. Yes, yes you will tell me “But I go into the Google Apps and I indicate the domain I want as a whitelist”, and I will tell you it is correct BUT NOT ENOUGH
Thinking about this situation you must already be thinking: If I don't have that API KEY, how can I make my application work correctly? The short answer is: you need to call a third party to request that information and only then be able to make the “request” you need. .
Let's imagine that for some reason that API KEY is compromised and you want to replace it with a new one to remedy the situation, you should do something similar to this:
If it is a "Mobile" APP, you will have to create a new version, upload it to the corresponding store, then release that new version and wait for all your users to download this version. It is a slow and non-scalable process.
On the other hand, if it is "Web", you will have to do something similar; release a new version, invalidate the cache (something many do not do in their CI/CD processes) of web applications and wait for your users to visit you again and the browser gives them the latest deployed version.
Here's where we leverage a third-party service. This service acts as a centralized repository for API keys, ensuring secure storage irrespective of the application type (frontend or backend) or its implementation details (like an AWS Lambda function).
AWS Secrets Manager is a secrets management service that helps you protect access to your applications, services, and IT resources....
- You save a “Secret”, in your AWS account.
- That “Secret” is encrypted at rest (only you will have access to the plain data), therefore there is no way for it to be exposed.
- Using the AWS API or SDK you will be able to consume it easily.
- 100% integrable with other services such as IAM and AWS Cognito (we will see the practical case later).
- You will be able to enter your AWS console and change the value as many times as you want without having to inform whoever is consuming it.
This service allows you as a frontend developer to deploy your applications without the need to expose sensitive data during the CI/CD process or during final packaging.
- Store sensitive information: API keys, passwords, and legal identification numbers (Passport, S.S.N) in Secret Manager.
- Store other application configurations: App URL, server configuration, non-sensitive API keys, etc. in environment variables.
- Enhanced security: Encrypts and stores sensitive data separately from your application code.
- Granular access control: Restricts access to specific users or roles.
- Auditability: Tracks who accessed and modified sensitive data.
- Security risk: Environment variables are easily accessible in the code source, making sensitive data vulnerable.
- Lack of flexibility: Difficult to manage permissions and control access to sensitive data.
- Maintenance challenges: Updating sensitive data requires code changes and deployments.
Using Secret Manager for sensitive information and environment variables for other configurations provides a more secure and flexible solution for your applications.