Third-party secret keys (OpenAI, Stripe, Resend) in client JS

Steps

1. Open your own production site → DevTools → Sources (or Network → JS bundles).
2. Search for sk-, sk_live, sk_test, sk-proj-, re_, Bearer tokens, and service_role.
3. If you find a secret, rotate it at the vendor immediately and treat it as leaked.
4. Move calls to a server route or edge function; keep secrets in server-only env vars (never NEXT_PUBLIC_ / VITE_ prefixes).
5. Confirm Supabase secret/service_role keys stay server-side; only the publishable key belongs in the browser — see https://supabase.com/docs/guides/getting-started/api-keys

Why it matters

Guides on securing Lovable/Bolt apps warn about keys in the client and misconfigured RLS: https://lorikeetsecurity.com/blog/securing-lovable-bolt-apps-production

A read-only scan of vibe-coded apps reported OpenAI project keys in public JS bundles and, via its ai-js module, flagged 38 apps across platforms with hardcoded API keys in JS bundles (17 of 251 Bolt.host apps / 6.8%; 18 of 67 Vercel AI apps / 26.9%): https://securityscanner.dev/blog/beyond-supabase-rls-five-other-crits

Self-check your own app only. VibeRescue does not scan third-party apps for you today — join the waitlist if you want a future check on an app you own.

Related patterns

• API secret keys shipped in your frontend bundle
• Exposed .env or .git on a deployed site