ON THIS PAGE (7 SECTIONS)
- ✓OWASP treats hardcoded keys, tokens, and passwords as a secrets-management failure, not a convenience.
- ✓Anything shipped to a browser or a mobile binary can be extracted. It is an identifier, not a credential.
- ✓The twelve-factor litmus test: you could open-source the repo without leaking a credential.
- ✓People should not have standing access to every secret. Rotation has to be possible without a code change.
The frontend needs to call a vendor, so the vendor key is placed in the bundle "just for now." Anyone who loads the page can read the bundle. The key is now their key, billed to you, until someone notices. The same thing happens when a database password is committed because a local config file was not ignored.
The OWASP Secrets Management Cheat Sheet starts from that pattern: keys, database credentials, and certificates end up in source and in config that people copy around. The twelve-factor config rule has a practical test. You should be able to publish the codebase without publishing a credential. If you cannot, the secret is in the wrong place.
Where a value is allowed to live
| Value | Allowed place | Not allowed |
| Database password, private key, vendor secret | A secret store the server reads at runtime | Repo, image layers, browser, mobile binary, chat logs |
| Publishable client identifier | The client, if the vendor designed it to be public | Treating it as if it authorized spending |
| User session | An http-only cookie or a memory the user controls | Local storage, if you can avoid it, and never the repo |
| Prompt or document a user typed | The server path that is allowed to see it | A third-party log you did not mean to enable |
A secret store still needs an owner and a way to rotate. OWASP notes that people who can read every secret become a leak path, and that manual copying is how values drift. Give the running service the secret. Give engineers a way to deploy without pasting it into a ticket. When a laptop is lost or a log is shipped too widely, rotation is the response. Rotation that requires a code change will not happen in a hurry.
Illustrative scenario
This scenario is illustrative. A team wants the browser to transcribe audio with a vendor. The vendor secret stays on the server. The browser uploads audio to your API, which calls the vendor. The browser receives a transcript, not a key. The cost and the quota sit where you can see them. Putting the key in the client would make every visitor a quota. The same rule applies to model keys. A prompt can be sent from the browser. The credential that pays for the model cannot.
Checklist
- Search the repo and the image build for tokens before calling a release done.
- Keep production secrets out of the files developers share for local setup. Provide local substitutes.
- Confirm the client bundle and the mobile binary do not contain server credentials.
- Restrict who can read production secrets. Access should be narrower than "everyone on the team."
- Make rotation a config change, then practice it once.
- Decide where prompts and documents are logged before you turn a vendor logger on. That policy is AI Data Retention.
Questions that usually come next
Are environment variables safe?
They are safer than a committed file, because they are not in git. They are still visible to anyone who can read the process environment or a misconfigured debug endpoint. A secret store with access control is the better home for production. Environment variables are a reasonable way for the process to receive the value at start.
What about encrypting the secret in the repo?
Encryption moves the problem to the key that decrypts it. If that key is also in the repo, you have two secrets and the same leak. If the key is outside the repo, you have reinvented a secret store. Use the store.
Direct answers
Are environment variables safe?
They keep secrets out of git. They do not replace access control. Prefer a secret store, and pass the value into the process at start.
Can we encrypt secrets into the repository?
Only if the decryption key lives outside the repository and is itself managed. A key committed beside the ciphertext is not protection.
References & Prior Art
Naveen
Infrastructure EngineerNaveen handles infrastructure, edge network resilience, chunked media pipelines, and deterministic CI/CD release verification at Vasiva.
