Did a private API key end up in my frontend?
Review environment-variable exposure, client-side imports and built assets to find credentials that crossed a trust boundary. If a live private key was exposed, revoke or rotate it with the provider, update the application and investigate use of the old credential.
Who this is for: Developers handling Stripe, Supabase, AI-provider and cloud credentials in web applications.
STEP 01
Decide whether the value is actually secret
Not every token-shaped string has the same privilege. Identify the provider, credential type, environment and permitted operations. Public project identifiers and publishable keys can be expected in a browser; privileged credentials cannot. Use a scanner's finding to investigate the value's role instead of copying the raw credential into tickets or chat.
Try this: For each finding, record the provider, scope and exposure location without reproducing the live credential.
STEP 02
Inspect what the browser actually receives
A source file may look server-only while an import or build setting causes sensitive configuration to reach a client bundle. Review public environment variables and generated assets. Check deployed source maps and error output where applicable. The relevant question is whether an untrusted visitor can retrieve a privileged value, not whether the repository itself is private.
Try this: Search the release artifacts and inspect client requests using safe placeholders or credential fingerprints.
STEP 03
Contain first, then prevent a repeat
Removing a secret from the latest commit does not invalidate copies that already escaped. Rotate through the provider, deploy the replacement securely and review relevant usage logs. Then fix the route of exposure and add a check to the development workflow. If historical repositories or artifacts might contain the value, examine those separately.
Try this: Verify that the old credential no longer authorizes requests, and that the application works with the replacement.
Your review checklist
- Identify the credential's provider, privilege and environment.
- Review public environment variables and client imports.
- Inspect release artifacts for privileged values.
- Revoke or rotate confirmed exposed credentials.
- Review usage logs and affected systems.
- Add a regression check for the original exposure path.
What Bryxe can check
Bryxe checks supplied source for recognized secret patterns and offers an environment exposure tool. Use the focused tool with placeholders when reviewing variable names and configuration.
What you still need to verify
Scanning the files you submit does not inspect all repository history, old deployments or provider logs. A finding does not rotate a credential, and absence of a finding does not prove that every possible secret was detected.
Common questions
Should I paste production secrets into a public scanner?
Use placeholders for configuration reviews. If a real credential is already exposed, rotate it with its provider. Review the service's security and privacy documentation before uploading proprietary files.
Is deleting the leaked key from Git enough?
No. Deletion does not revoke the credential or remove copies from previous artifacts. Rotate or revoke it, update deployments, and review relevant usage for unexpected activity.
Can a public variable contain a private key safely?
Treat values configured for client exposure as readable by visitors. Keep privileged keys in trusted server environments and call the privileged service through an authenticated, authorized server operation.
Documentation & further reading
These primary sources explain the platform behavior discussed above. Check the documentation for the versions and configuration you use.