JavaScript Can't Keep a Secret
Learn why we should never store private information on the client, including in URLs.
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 secrets may be the most blatantly inappropriate offense we’ll discuss, but it’s often less obvious ...
Get hands-on with 1400+ tech skills courses.