Great read! I have a question for you. Since storing credentials in the source code or cofig files is a big NO for all sorts of reasons, what do YOU do in cases where there is a SPA application that needs to authenticate with the backend (via JWTs) without any user interaction? I mean, lets say that we want only this app to be able to access specific back end resources, hence we must somehow provide the sourcecode of this app with some credentials to communicate to the back end to gain access (retrieve a JWT for future calls). For example, you have an application that accesses a backed web api and you want only this application to be able to access that particular API.
Hi Nikolaos, a critical topic you raised! This could easily render a dedicated article. But, as a quick overview:
It really depends on your infrastructure, environment and required security level.
Loading secrets on demand from an external, secure place, is recommended. Once it's loaded, the app can share it internally as an environment variable or keep it short-lived in a contextual variable to avoid leakage inside the app.
Once a secret is in the machine RAM and unencrypted, it's already exposed, though. Depending on how much security you need, it might be worth having secrets for different application areas or endpoints. If one secret is compromised, the damaged area is reduced.
Observe that the article indicates things we should avoid. In some cases (sole-projects, proofs-of-concept or quick MVPs, etc), a sub-optimal approach might be acceptable.
There are basically two routes for implementation:
1. Managed services
This is my preferred choice, when financially feasible.
"... enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle. Users and applications retrieve secrets with a call to Secrets Manager APIs, eliminating the need to hardcode sensitive information in plain text"
It's a great service. There are two downsides:
Cost: $0.05 per 10,000 requests (depending on your traffic and profitability, it's unfeasible)
Scale limitation: up to 700 RPS by default; I believe you can ask for a limit increase, though
This will be tricky and I don't have enough expertise to advise on the best implementation from a security standpoint.
Nevertheless, one solution is using AWS Lambda to isolate my secrets and serve other parts of the application stack. A plugin for the Serverless framework makes it a bit easier.
Instead of calling a service like AWS Secrets Manager, I'd call my own AWS Lambda function, which will provide the secrets on-demand. It will be 10x cheaper: $0.004 per 10,000 requests.
Using IAM to control who has access to the secrets Lambda will provide reasonable level of security.
If I would work in a team using this approach, I'd completely isolate the Secrets Lambda from the rest of my stack (repo, infra-as-code, CI/CD workflow, everything). This would contribute to preventing leakage of secrets used in production.
You can get way fancier with this implementation, but it's already getting too lengthy... Hope this helps shed some light. 💡 😉
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great read! I have a question for you. Since storing credentials in the source code or cofig files is a big NO for all sorts of reasons, what do YOU do in cases where there is a SPA application that needs to authenticate with the backend (via JWTs) without any user interaction? I mean, lets say that we want only this app to be able to access specific back end resources, hence we must somehow provide the sourcecode of this app with some credentials to communicate to the back end to gain access (retrieve a JWT for future calls). For example, you have an application that accesses a backed web api and you want only this application to be able to access that particular API.
Hi Nikolaos, a critical topic you raised! This could easily render a dedicated article. But, as a quick overview:
It really depends on your infrastructure, environment and required security level.
Loading secrets on demand from an external, secure place, is recommended. Once it's loaded, the app can share it internally as an environment variable or keep it short-lived in a contextual variable to avoid leakage inside the app.
Once a secret is in the machine RAM and unencrypted, it's already exposed, though. Depending on how much security you need, it might be worth having secrets for different application areas or endpoints. If one secret is compromised, the damaged area is reduced.
There are basically two routes for implementation:
1. Managed services
This is my preferred choice, when financially feasible.
AWS, for instance, provides Secrets Manager:
It's a great service. There are two downsides:
Similarly, Azure has Key Vault and GCP has Key Management Service.
2. In-house secrets management
This will be tricky and I don't have enough expertise to advise on the best implementation from a security standpoint.
Nevertheless, one solution is using AWS Lambda to isolate my secrets and serve other parts of the application stack. A plugin for the Serverless framework makes it a bit easier.
Instead of calling a service like AWS Secrets Manager, I'd call my own AWS Lambda function, which will provide the secrets on-demand. It will be 10x cheaper: $0.004 per 10,000 requests.
Using IAM to control who has access to the secrets Lambda will provide reasonable level of security.
If I would work in a team using this approach, I'd completely isolate the Secrets Lambda from the rest of my stack (repo, infra-as-code, CI/CD workflow, everything). This would contribute to preventing leakage of secrets used in production.
You can get way fancier with this implementation, but it's already getting too lengthy... Hope this helps shed some light. 💡 😉