← All posts
exposed secretsJavaScript securityAPI keyssecret scanningclient-side securityvibe coding security

How to Find Exposed Secrets in JavaScript (2025 Guide)

O

OverMCP Team

TL;DR: Exposed secrets in JavaScript are API keys, tokens, passwords, or other credentials that are hardcoded or visible in your client-side code. To find them, check your browser's DevTools Network tab, search for common patterns (e.g., sk_live_, AIza), use automated scanners like OverMCP, and scan your git history. Fix them by moving secrets to environment variables, using a backend proxy, or implementing proper secret management.

---

What Are Exposed Secrets in JavaScript?

When you build a web app with AI coding tools like Cursor, Bolt.new, or v0, it's tempting to hardcode API keys directly into your JavaScript files. But any secret placed in client-side code is visible to anyone who opens your site. This includes:

  • API keys for third-party services (Stripe, OpenAI, Google Maps)
  • Authentication tokens (JWT, Firebase UID)
  • Database connection strings
  • Secret keys for encryption or signing
  • Even if you bundle or minify your code, these secrets remain accessible via browser DevTools, network inspection, or simply viewing the page source.

    Why This Matters

    Leaked secrets can lead to:

  • Unauthorized API usage – Someone uses your Stripe key to make charges.
  • Data breaches – A database connection string lets attackers dump your user data.
  • Account takeover – Exposed Firebase or Auth0 tokens allow impersonation.
  • Financial loss – You may get billed for unexpected usage.
  • According to a 2024 GitGuardian report, over 10 million secrets were exposed in public GitHub repositories, and JavaScript projects are among the top offenders.

    How to Find Exposed Secrets in JavaScript

    Step 1: Manual Inspection with DevTools

    Open your website in Chrome or Firefox, then:

  • View Source: Right-click → "View Page Source". Search for common prefixes like sk_, pk_, AIza, api_key, secret, token, password.
  • Network Tab: Go to DevTools → Network → reload the page. Look for API calls in the request headers or URLs that contain secrets.
  • Sources Tab: Look for JavaScript files (especially .js, .mjs). Open them and search for suspicious strings.
  • Example: If you find a line like const stripeKey = 'sk_live_4eC39HqLyjWDarjtT1zdp7dc'; in your bundle, that's an exposed secret.

    Step 2: Use Automated Scanning Tools

    Manual inspection is slow and error-prone. Automated scanners can quickly identify secrets across your entire codebase. Tools like OverMCP scan your deployed app for exposed secrets in JavaScript, configuration files, and environment variables. They use pattern matching for hundreds of known secret formats (Stripe, AWS, GitHub tokens, etc.) and highlight exact locations.

    Example output from a scanner:

    File: /static/js/main.abc123.js
    Line 42: const stripeKey = 'sk_live_...' (Stripe Secret Key) - HIGH RISK

    Step 3: Search for Common Patterns with grep

    If you have access to the source code, use a simple regex search:

    grep -rE '(sk_live_|sk_test_|AIza|ghp_|gho_|api_key|secret|token|password|eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+)' ./src --include='*.js' --include='*.ts' --include='*.jsx' --include='*.tsx'

    This will find most common secret patterns, including JWTs (which start with eyJ).

    Step 4: Scan Git History

    Secrets often get committed and then removed in later commits. Tools like git secrets or truffleHog can scan your entire git history:

    # Install truffleHog
    pip install trufflehog
    # Scan a local repo
    trufflehog git file:///path/to/repo --only-verified

    Step 5: Monitor with Real-Time Alerts

    For ongoing protection, set up a security scanner that monitors your deployed app continuously. OverMCP, for instance, automatically scans every deployment and alerts you if a new secret appears in client-side JavaScript.

    Common Places Secrets Hide

  • Inline in `<script>` tags in HTML files
  • Inside JavaScript bundle files (Webpack, Vite, Parcel output)
  • In environment files that are accidentally served (.env exposed via misconfigured static hosting)
  • In API request URLs or headers visible in Network tab
  • In source maps that are deployed to production (.map files)
  • How to Fix Exposed Secrets

  • Rotate the secret immediately – Generate a new key from the service provider and revoke the old one.
  • Move secrets to environment variables – Use server-side environment variables (e.g., in Vercel, Netlify, or your backend) and never expose them to the client.
  • Use a backend proxy – Instead of calling third-party APIs directly from the client, create a server-side endpoint that forwards requests with secrets stored server-side.
  • Use restricted keys – Many services allow you to create keys with limited permissions (e.g., read-only, specific IPs). Use those for client-side operations if absolutely necessary.
  • Implement secret scanning in CI/CD – Add a pre-commit hook or GitHub Action that scans for secrets before code is pushed.
  • Example fix:

    Before (exposed):

    fetch('https://api.openai.com/v1/completions', {
      headers: {
        'Authorization': 'Bearer sk-proj-xxxxxxxxxxxx'
      }
    });

    After (secure):

    // client-side
    fetch('/api/chat', { method: 'POST', body: JSON.stringify({ prompt }) });
    
    // server-side (e.g., Next.js API route)
    export default async function handler(req, res) {
      const response = await fetch('https://api.openai.com/v1/completions', {
        headers: {
          'Authorization': `Bearer ${process.env.OPENAI_API_KEY}`
        },
        method: 'POST',
        body: JSON.stringify({ prompt: req.body.prompt })
      });
      const data = await response.json();
      res.json(data);
    }

    Preventing Future Exposures

  • Use environment variables everywhere – Never hardcode.
  • Set up secret detection in your editor – VS Code extensions like "Secret Scanner" highlight secrets as you type.
  • Add a `.gitignore` for `.env` files – Ensure they are never committed.
  • Audit your codebase regularly – Run automated scans weekly or after every major change.
  • Educate your team (or yourself) – Understand that anything in client-side JS is public.
  • How OverMCP Helps

    OverMCP automates the detection of exposed secrets in your vibe-coded apps. It scans your deployed site, JavaScript bundles, and git history for hundreds of secret patterns, giving you a clear report of risks and exact locations to fix. It's designed for indie makers who ship fast but want to avoid security pitfalls.

    FAQ

    How do I check if my JavaScript has exposed secrets?

    Open your browser's DevTools (F12), go to the Sources or Network tab, and search for common secret patterns like sk_live_, AIza, ghp_, or Bearer. Alternatively, use an automated scanner like OverMCP to scan your entire site.

    What are the most common exposed secrets in JavaScript?

    The most common are API keys for Stripe, OpenAI, Google Maps, Firebase, and GitHub tokens. Also, JWT tokens and database connection strings appear frequently in client-side code.

    Can I safely use API keys in client-side JavaScript?

    No, you should never place API keys or secrets in client-side JavaScript. Use a backend proxy or serverless function to make API calls on behalf of the client, and store secrets in environment variables on the server.

    ---

    Found exposed secrets? Rotate them immediately and set up automated scanning to prevent future leaks. OverMCP can help you scan your app in minutes.

    Is your app secure?

    Free scan in 30 seconds. No signup needed.

    Scan My App Free