DEV Community

Discussion on: How I Fixed JWT Security Flaws in 3 Steps

byrro profile image
Renato Byrro Author

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.

AWS, for instance, provides Secrets Manager:

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

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. 💡 😉