How to Find Exposed Secrets in Your Code Before They Ship

Quick answer: Exposed secrets hide in three predictable places: frontend bundles, git history, and misprefixed .env files. Grep your code and built output for known prefixes like sk_live_, AKIA, and ghp_, then use an automated secret scanner to catch high-entropy leaks. If you find one, rotate the key immediately to end the exposure.

By Daniel A · Kraftwire Software

To find exposed secrets in your code before they ship, you must audit three specific areas: your frontend build bundles, your git history, and your .env files for incorrect prefixes. Start by running a manual grep for known patterns like sk_live_ or AKIA, then use an automated secret scanner to detect high-entropy strings that lack a standard prefix. If a secret is found, you must rotate the credential immediately; simply deleting the code does not invalidate the leaked key.

What Actually Counts as a Secret?

In the context of modern development, a secret is any string that grants programmatic access to data, compute, or financial resources. If an attacker can use the string to authenticate as you or your application, it is a secret. According to research from Cycode, exposed secrets like API keys and passwords remain one of the leading causes of security breaches today.

Common secrets include:

• Cloud Provider Credentials: AWS Access Keys, Google Cloud Service Accounts.
• Payment Gateways: Stripe Secret Keys (sk_live_), PayPal Client Secrets.
• AI and LLM Keys: OpenAI API keys (sk-), Anthropic, or Pinecone keys.
• Database Strings: Connection URLs containing user:password syntax.
• Authentication Tokens: GitHub Personal Access Tokens (ghp_), JWT signing secrets, and OAuth refresh tokens.

It is equally important to identify "public" identifiers that are safe to ship. For example, a Stripe publishable key (pk_live_) or a Supabase anon key are designed for client-side use, provided they are backed by proper Row Level Security (RLS). Confusing these with secrets leads to "security theater" where developers hide keys that don't need hiding while missing the ones that do.

The Rise of Vibe Coding and Secret Leaks

The era of "vibe coding" · building applications using AI tools like Lovable, Bolt.new, and Cursor · has accelerated development but also increased the risk of accidental exposure.

Because AI agents often generate code based on "vibes" or natural language prompts, they may inadvertently hardcode a secret during a "quick fix" session. Checkmarx notes that hardcoding access credentials is often the fastest way to write code during rapid development, which is exactly where AI tools excel and where human oversight often fails.

Which Key Formats Can You Recognize on Sight?

Most major service providers use specific prefixes to help automated scanners and developers identify keys. Memorizing these seven patterns allows you to spot a leak during a quick code review:

• AKIA · The start of an AWS Access Key ID.
• sk_live_ · A Stripe production secret key.
• sk-proj- · The modern format for OpenAI project-scoped keys.
• ghp_ · A GitHub Personal Access Token.
• eyJ · The standard Base64 header for a JSON Web Token (JWT).
• -----BEGIN PRIVATE KEY----- · The header for a PEM-formatted private key.
• postgres:// · The beginning of a database connection string that likely contains a password.

If you encounter an eyJ string, use a JWT debugger to see what claims it contains. A token with a service_role claim is a critical leak, while one with an anon role may be intended for the frontend.

Where Do Secrets Actually Hide?

1. Frontend Build Bundles

This is the most common leak for apps built with Vite, Next.js, or Nuxt. These frameworks use prefixes to determine which environment variables are "safe" for the browser. If you accidentally name a variable VITE_STRIPE_SECRET_KEY instead of STRIPE_SECRET_KEY, Vite will inline that secret directly into your production JavaScript files. Minification does not hide these; they remain searchable in plain text.

2. Git History

Deleting a secret in a new commit does not remove it from the repository's history. Anyone who clones the repo or views the commit history can find the key. Bots continuously monitor public repositories for these mistakes. According to KodeKloud, secret scanning within GitHub Advanced Security is a primary defense, but it must be enabled to catch these before they are exploited.

3. Misconfigured .env Files

The .env file is a double-edged sword. It keeps secrets out of your code, but if you forget to add .env to your .gitignore, the entire file is pushed to your repo. Furthermore, using a vibe-coded app security checklist is essential to ensure that your local environment setup matches your production security requirements.

4. Test Fixtures and Example Files

Developers often paste real keys into test-setup.ts or docker-compose.yml for "temporary" local testing. These files are frequently overlooked during security audits.

How to Grep Your Code for Secrets

Before deploying, run a manual check from your terminal. This is a "zero-cost" security audit that catches the most obvious mistakes.

Search the working directory:

Search your built assets (the most important check):

Search your entire Git history:

Why You Need an Automated Secret Scanner

While grep is effective for known prefixes, it cannot detect high-entropy strings that don't follow a pattern. A dedicated secret scanner uses entropy analysis to identify strings that are "too random" to be normal code or text. This catches internal API keys, custom tokens, and obscure provider formats.

Many of these were not obvious AKIA keys but rather high-entropy tokens hidden in configuration objects. Automated tools also check for code injection prevention and other vulnerabilities that manual searching will always miss.

What to Do When You Find a Leaked Key

If you find a secret in your code or history, follow this exact order of operations. Do not skip to step 4.

• Rotate the Key: Go to the provider dashboard (AWS, Stripe, OpenAI) and revoke the key. Generate a new one. This is the only way to stop an active leak.
• Audit Logs: Check the service's usage logs for any unauthorized activity. If an AWS key was leaked, check for new EC2 instances or S3 bucket access.
• Update Environment Variables: Place the new key in your server-side environment variables. Ensure it does not have a client-side prefix like NEXT_PUBLIC_.
• Clean the History: Use a tool like git filter-repo to scrub the secret from your Git history. This is for hygiene and compliance, but it does not replace rotation.
• Implement Guardrails: Use an .env file linter to prevent future misconfigurations and add a pre-commit hook to scan for secrets before they leave your machine.

Prevent Future Leaks with Better Architecture

Finding secrets is a reactive process; preventing them is proactive. Ensure your API security best practices include moving all sensitive logic to the backend. If your frontend needs to talk to a sensitive service, use a proxy endpoint or a serverless function to keep the API key on the server.

For those building with AI, the risk of "prompt-to-production" leaks is high. Always run a free security scan before you share your URL. SimplyScan grades 8 dimensions in 30 seconds, detecting exposed API keys, missing security headers, and performance bottlenecks that could cost you users and revenue.

FAQ

Is a Supabase anon key an exposed secret?

No. The Supabase anon key is designed to be public. Its security relies on Row Level Security (RLS) policies within your database. However, if you accidentally expose the service_role key, which bypasses RLS, your entire database is compromised. Always check the role of any JWT you find in your bundle using a JWT debugger.

How quickly are leaked keys on GitHub abused?

Bots monitor the GitHub "public timeline" and can detect and attempt to use a leaked key within seconds of a push. Many providers like AWS and GitHub now have "push protection" that attempts to block the commit, but this is not universal. Treat any committed key as compromised immediately.

Does deleting a leaked key from my code fix the problem?

No. Deleting the code only prevents the key from being in the *current* version of the file. The key remains in your .git folder and history. Furthermore, if the key was already built into a production bundle, it may still be cached on CDN edges or user browsers. You must rotate the key at the source.

What is entropy analysis in secret scanning?

Entropy analysis measures the randomness of a string. Standard English text and code have low entropy, while cryptographic keys and hashes have high entropy. Scanners use this to flag suspicious strings that don't match a known prefix, helping you find custom internal secrets or obscure third-party tokens.

How do I stop secrets from being committed in the first place?

The best defense is a multi-layered approach: add .env to your global .gitignore, use a vibe coding security checklist, and install a pre-commit hook that runs a local secret scan. Additionally, use an .env file linter to ensure you aren't using client-side prefixes on server-side secrets.

Are there free tools that scan for exposed secrets?

Yes. SimplyScan provides a free secret scanner where you can paste code snippets or file contents to check for leaks. For a more comprehensive check, our full site scan detects secrets that have already made it into your public-facing frontend bundles, along with other critical security and performance issues.