Find secrets in code: detect leaks and fix exposed keys

Where should you look for hardcoded secrets?

Start with the source your app actually deploys. A secret scanner can flag supported token patterns, but you still need to inspect how each value is used and where copies may exist.

• Application files: SDK setup, database connections, signing configuration and scripts.
• Tracked configuration: .env files, deployment examples and temporary debugging files.
• Git history: earlier commits may still contain a key removed from the current branch.
• Build outputs and live JavaScript: server credentials can reach the browser through public variables or bundled imports.
• Logs and shared material: CI output, issue attachments and screenshots need separate review.

A ZIP contains the files supplied in that archive; it does not establish coverage of the repository's commit history. For a repository scan, read the report's coverage notes before assuming older commits were analyzed. Never paste a real credential into a public issue to ask whether it is a secret.

How do you find secrets in code with SetRepo?

Use a repository scan to build a review queue, then confirm what each finding means for your application.

1. Choose a GitHub repository or upload a source ZIP. Include relevant source and configuration that you are authorized to share.
2. Review the scan setup, current pricing or credits, and choose Quick or paid Deep. Quick includes deterministic secret checks; Deep adds AI review of selected code for other security questions.
3. Inspect each finding's file and surrounding code. Identify the provider, intended use and permissions without copying the credential into another shared system.
4. Check the scan's coverage and skipped checks. Review history and deployment assets separately wherever the supplied input or analysis does not cover them.
5. Revoke or rotate confirmed exposed credentials, change the code and configuration, test the app, and rescan.

The GitHub security scanner also checks known vulnerable dependencies and supported risky code patterns. Those checks complement hardcoded secrets detection; they answer different security questions.

Which findings are private secrets rather than public keys?

Judge a value by the authority it grants, not just its name. A database password, signing key or privileged API token belongs on the server. A client identifier designed for browser use may be public, but its surrounding authorization still needs review.

Supabase is a useful example: its publishable key and legacy anon key are intended for client use with appropriate database permissions. Its secret keys and legacy service_role key grant elevated access and must stay out of the browser. See Supabase's API key documentation for key types and privileges.

For an AI-built app, inspect values placed in NEXT_PUBLIC_ or VITE_ variables. A private credential does not become safe because it came from an environment variable: public client variables can put it into the downloaded JavaScript.

The following example uses a deliberately invalid placeholder. The first pattern embeds a server credential in source; the second reads it from server-side configuration.

1// Unsafe location: a credential literal in a server source file.2const apiToken = "EXAMPLE_ONLY_NOT_A_REAL_CREDENTIAL";3 4// Better location: server-only configuration supplied by your host.5// Keep this module out of the browser bundle.6const serverApiToken = process.env.PROVIDER_API_TOKEN;7if (!serverApiToken) throw new Error("Missing server API token");

Moving a value into an environment variable does not invalidate a leaked copy. Review the exposed secrets remediation guide and Supabase RLS checks alongside the source finding.

What should you do after finding an exposed API key?

Contain the exposure at the provider. Removing a line of code leaves an already copied credential usable until it is revoked or expires.

Revoke or rotate the credential

Use the provider's supported rotation procedure. If immediate revocation is required to stop unauthorized use, prioritize containment. When safely possible, deploy a replacement credential and revoke the old one with minimal disruption. Review provider audit logs and the credential's permissions to assess possible misuse.

Remove the source of the leak

Replace the literal with server-only configuration, update deployment secrets and rebuild affected browser assets. Add local secret files to .gitignore, and untrack any already committed copies. Ignore rules do not erase previous commits.

Review history and other copies

GitHub recommends revoking or rotating exposed secrets as the first step. History cleanup may still be needed, but it requires coordination and cannot remove copies from every existing clone. Follow GitHub's sensitive-data removal procedure when cleanup is appropriate.

Test and rescan

Confirm that the old credential no longer works through the provider's management controls, that the replacement works in the intended server environment, and that public assets no longer contain the leaked value. Rerun source checks and review any remaining findings.

What should 2027's best security scanner help you verify?

When evaluating an exposed API keys scanner for 2027, look for supported credential patterns, understandable evidence, clear input coverage and practical remediation guidance. Check whether history and deployment assets require separate scans. These criteria are more useful than assuming that a product detects every secret.

Use SetRepo as part of that evaluation: scan supplied source, review its coverage notes and verify findings against the provider's permissions. Keep prevention in the workflow too: store private credentials outside source code, review changes before committing and use secret checks before publishing.

FAQ

Can a secret scanner detect every leaked credential?

No. Detection depends on supported patterns, available files and analysis limits. Custom formats, indirect values and copies outside the scan input can be missed. Review coverage and check other exposure paths.

Does deleting an API key from GitHub fix the leak?

No. Revoke or rotate the key with its provider. Then remove it from source and deployment assets, consider history cleanup, and investigate possible unauthorized use.

Do I need AI review to find hardcoded secrets?

Not necessarily. SetRepo's Quick scan includes deterministic secret checks. Paid Deep scans add AI review of selected code for access-control and business-logic issues; they do not guarantee detection of every credential.

What should I scan after fixing the repository?

Rescan the updated source and check the rebuilt deployment. A live website security scan provides additional observations from public responses and JavaScript. Logs, CI artifacts and older history may need separate review.