Client-Side Secret Exposure

What Is This Vulnerability

Client-Side Secret Exposure is a vulnerability where secrets that should be server-side only are found in frontend JavaScript bundles, HTML source, inline scripts, or source maps. This includes database connection strings, SMTP credentials, OAuth client secrets, internal API keys, webhook signing secrets, and any other credential not designed for public consumption.

Modern frontend frameworks like Next.js, Nuxt, Vite, and Create React App use environment variable prefixes to control which variables are bundled into client code. Misunderstanding these conventions is the most common cause of this vulnerability.

Why It's Dangerous

Exposed secrets in frontend code are accessible to every visitor of your website:

• Database compromise — connection strings grant direct database access bypassing all application-level security.
• Email abuse — SMTP credentials allow attackers to send spam or phishing emails from your domain.
• Webhook forgery — signing secrets allow attackers to forge webhook payloads, triggering unauthorized actions.
• OAuth hijacking — client secrets enable attackers to impersonate your application in OAuth flows.
• Internal API access — keys for internal services (monitoring, logging, feature flags) expose operational infrastructure.
• Source map exposure — deployed source maps reveal the complete original source code, making it easier to find additional vulnerabilities.

The impact depends on the specific secret exposed, but any unintended client-side secret represents a security boundary violation.

How to Detect

Audit your frontend bundles for secret patterns:

// Common framework-specific issues:

// Next.js: ONLY variables prefixed with NEXT_PUBLIC_ should be in client bundles
// If you see these in the browser bundle, they are leaked:
process.env.DATABASE_URL           // Should never be client-side
process.env.SMTP_PASSWORD          // Should never be client-side
process.env.WEBHOOK_SECRET         // Should never be client-side

// Vite: ONLY variables prefixed with VITE_ are exposed
// Check: import.meta.env.SECRET_KEY should be undefined in browser

// Search built output for common secret indicators
// In your terminal after building:
// grep -r "mongodb+srv://" .next/static/
// grep -r "postgresql://" .next/static/
// grep -r "smtp://" .next/static/
// grep -r "whsec_" .next/static/       # Stripe webhook secrets
// grep -r "-----BEGIN" .next/static/    # Private keys

Check your source maps as well:

# If source maps are deployed, they reveal everything
curl https://example.com/_next/static/chunks/app/page-abc123.js.map

AuditYour.app performs deep analysis of JavaScript bundles and source maps, matching against hundreds of secret patterns and validating findings to reduce false positives.

How to Fix

Follow your framework's environment variable conventions strictly:

# .env.local — Next.js example

# Server-only variables (NO prefix — never bundled into client code)
DATABASE_URL="postgresql://user:pass@host:5432/db"
STRIPE_SECRET_KEY="sk_live_..."
RESEND_API_KEY="re_..."
WEBHOOK_SECRET="whsec_..."

# Client-safe variables (NEXT_PUBLIC_ prefix — bundled into client code)
NEXT_PUBLIC_SUPABASE_URL="https://project.supabase.co"
NEXT_PUBLIC_SUPABASE_ANON_KEY="eyJ..."
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY="pk_live_..."

Additional protections:

// next.config.ts — disable source maps in production
const nextConfig = {
  productionBrowserSourceMaps: false,

  // Validate that secret env vars are not accidentally exposed
  env: {
    // This would EXPOSE the variable — never do this
    // STRIPE_SECRET_KEY: process.env.STRIPE_SECRET_KEY,
  },
};

Add a CI check to scan build output for secrets before deployment. Rotate any secrets that have been exposed, and audit access logs for the affected services to determine if they were abused.