JavaScript Can't Keep a Secret
Explore the risks of exposing sensitive data in client-side JavaScript, including secrets, API keys, and business logic. Understand why secrets should never be stored in code or URLs, the role of minification versus obfuscation, and how globals and URLs can leak sensitive information. Learn best practices to safeguard data by using secret managers, avoiding storing private info in frontend code, and managing session tokens securely.
We'll cover the following...
Client-side secrets are common
In 2022, RedHunt Labs (an information security company) performed a study on secrets exposed via client-side web applications. They were able to capture a staggering number of secrets from the top one million internet domains, a staggering 395,713. Many secrets had to do with managing authentication like API keys or cryptographic secrets including Stripe tokens, Google reCAPTCHA keys, Google Cloud API keys, AWS keys, and Facebook tokens.
Client-side JavaScript code is public in every sense of the word. It is even stored on the user’s machine! Public files, of any kind, should never contain access tokens, secret keys, or user credentials. In fact, even server-side files should never contain secrets. Never think that it is fine to put sensitive information in server-side code because these files won’t be served directly to end users. It’s possible for hackers to get access to these files, especially if they live in some sort of hosted version control system like GitHub. Secret keys should always be decoupled from application code and stored in a centralized secret manager like AWS Secrets Manager, which helps to manage, retrieve, and rotate secrets.
We can use linting tools like Secretlint to help prevent secrets from ever being committed to source code in the first place. Remember, if version control is used and a secret is committed, it must be rotated since it’s hard to completely wipe it away even if the latest code no longer has sensitive information.
Business logic
Committing ...