What counts as an exposed secret?
A secret is exposed when a credential that should remain private is committed to repository history, included in a public build, logged, or otherwise made available to an unauthorised person. Common examples include API keys, private keys, tokens, database passwords and privileged service credentials.
What to do when a key is exposed
Revoke or rotate the credential with its provider first. Remove it from the application, store the replacement in a proper secret manager or deployment environment, and check logs for misuse. Removing the latest line is not enough because the value may remain in Git history and existing clones.
Preventing repeat exposures
Keep .env files out of version control, commit a safe .env.example without values, use least-privilege credentials, add automated secret scanning to release checks, and avoid placing server-only credentials in browser code.
Limits of pattern matching
Secret scanners can miss custom formats and can report example values as possible credentials. Treat every result as evidence to investigate, and combine automated checks with provider alerts, code review and credential rotation procedures.
Frequently asked questions
Does deleting a secret from GitHub make it safe?
No. Revoke or rotate it because it can remain in Git history, caches, logs or existing clones.
Can a browser app safely contain a private API key?
No. Anything shipped to a browser can be inspected. Calls requiring a private key should normally go through a protected server.
Does Quick Scan First store discovered keys?
Repository code is processed for the scan and is not stored as a copy on Quick Scan First servers.