Vercel Environment Variables: What Is Actually Safe to Expose and What Is Not

The NEXT_PUBLIC_ Problem

Next.js uses a simple naming convention to determine which environment variables are available in the browser: any variable starting with NEXT_PUBLIC_ is inlined into the client-side JavaScript bundle at build time. Variables without this prefix are only available in server-side code (API routes, getServerSideProps, Server Components).

The same build-time rule decides which API address your browser code calls. If that address is a hardcoded localhost URL instead of a variable, every call fails once the app is deployed.

This design is intentional and useful - your app needs some values in the browser (like a Supabase anon key or a Google Analytics ID). The problem is that AI coding tools do not distinguish between browser-safe and server-only secrets. According to GitGuardian's 2024 report, 12.8 million new secrets were leaked publicly on GitHub in 2023. Client-side bundles are an even more direct exposure vector because they are served to every user.

Apiiro's 2025 research found that AI-assisted developers exposed cloud credentials nearly twice as often as their non-AI peers. In a Next.js app, one easy way to expose a key is to give it the NEXT_PUBLIC_ prefix.

What Is Safe vs. Dangerous

How AI Tools Create This Problem

# ❌ BAD - AI puts secrets in NEXT_PUBLIC_ variables
# .env.local (what AI generates)
NEXT_PUBLIC_SUPABASE_URL=https://abc.supabase.co
# This is the SERVICE key!
NEXT_PUBLIC_SUPABASE_SERVICE_KEY=eyJhbGci...
NEXT_PUBLIC_STRIPE_SECRET=sk_live_abc123
NEXT_PUBLIC_OPENAI_KEY=sk-abc123

# ✅ GOOD - Only browser-safe values get NEXT_PUBLIC_
# .env.local (corrected)
NEXT_PUBLIC_SUPABASE_URL=https://abc.supabase.co
# Anon key is safe
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGci...

# Server-only (no NEXT_PUBLIC_ prefix)
SUPABASE_SERVICE_KEY=eyJhbGci...
STRIPE_SECRET_KEY=sk_live_abc123
OPENAI_API_KEY=sk-abc123

How to Check for Exposed Secrets on Vercel

1. Open your deployed site in a browser and go to DevTools > Sources tab.
2. Search across all sources for strings like sk_live, sk-, service_role, and eyJhbGci.
3. Check your Vercel dashboard > Settings > Environment Variables. Look for any variable with NEXT_PUBLIC_ prefix that contains a secret value.
4. Search your codebase for process.env.NEXT_PUBLIC_ and verify each usage is browser-safe.

Vercel-Specific Environment Variable Features

Vercel provides environment scoping that AI tools do not use. Variables can be set per environment (Production, Preview, Development), which prevents preview deployments from using production secrets. Vercel also lets you save a variable as a Secret (the type that replaced "Sensitive"): its value is write-only after saving, and Vercel redacts it from build logs when it is 32 characters or longer. Always save secret values as the Secret type in the Vercel dashboard.

What to Do If Your Secrets Are Already Exposed

1. Rotate immediately. Generate new keys/secrets from each provider's dashboard (Supabase, Stripe, OpenAI, etc.).
2. Update Vercel env vars. Remove the NEXT_PUBLIC_ prefix, add the new keys, redeploy.
3. Check access logs. Review your Stripe dashboard, Supabase logs, and OpenAI usage for unauthorized activity.
4. Set up monitoring. Enable billing alerts on paid API services to catch unauthorized usage early.
5. Scan your codebase. Tools like VibeDoctor's Vibe Check flag code that reads a public-prefixed variable with a secret-sounding name, such as process.env.NEXT_PUBLIC_STRIPE_SECRET (SEC-006), and run Gitleaks to find key values committed in your files, each with its file and line. Free to sign up.

Your host can also leak environment variables you never exposed. In October 2026 an attacker read 3,218,965 environment variable records from the Zeabur hosting platform. Our Zeabur breach guide covers the order to rotate keys in and how to limit the next leak.

FAQ