How I Would Fix exposed API keys and missing auth in a Bolt plus Vercel client portal Using Launch Ready.

How I Would Fix exposed API keys and missing auth in a Bolt plus Vercel client portal Using Launch Ready

The symptom is usually obvious: a client portal works for anyone who knows the URL, and API keys are sitting in the frontend bundle, network requests, or a public repo. In business terms, that means customer data exposure, unauthorized access, surprise usage bills, and a support fire drill if the portal is already live.

The most likely root cause is that the app was built fast in Bolt, deployed to Vercel, and shipped before security boundaries were added. The first thing I would inspect is whether any sensitive logic is happening in client-side code instead of server-side routes, because that is where exposed keys and missing auth usually start.

Triage in the First Hour

1. Check the live portal in an incognito window.

• Try opening protected pages without signing in.
• Confirm whether private data loads before any session check.

2. Inspect Vercel deployment settings.

• Review environment variables for production, preview, and development.
• Confirm which variables are exposed to the browser with `NEXT_PUBLIC_` or similar prefixes.

3. Search the codebase for secrets and auth gaps.

• Look for hardcoded API keys, webhook secrets, tokens, and service credentials.
• Check whether API calls are made directly from React components.

4. Review server logs and error traces.

• Look for unauthorized requests, repeated 401s or 403s, and unusual traffic spikes.
• Check whether sensitive values are being logged by mistake.

5. Audit connected accounts.

• Verify Vercel project access.
• Check cloud provider, database, email provider, and third-party SaaS permissions.

6. Inspect build output and public assets.

• Confirm no secret values are embedded in JS bundles or source maps.
• Review `robots.txt`, sitemap entries, and any publicly indexed routes.

7. Confirm current blast radius.

• Identify what key was exposed, where it appeared, and how long it was visible.
• Decide whether rotation is required immediately.

A quick command I would run locally to catch obvious leaks:

grep -RInE "sk-|api[_-]?key|secret|token|private_key|bearer" .

If this finds anything inside frontend code or committed files, I treat it as a production incident until proven otherwise.

Root Causes

1. Secrets were placed in client-side code.

• How I confirm it: search components, hooks, or utility files for direct SDK initialization with real keys.
• Common pattern: a third-party API client is created inside a React component instead of behind an API route.

2. Environment variables were exposed to the browser.

• How I confirm it: inspect Vercel env names and look for variables prefixed for frontend use.
• If a secret has `NEXT_PUBLIC_` or equivalent exposure naming, assume it is public.

3. Authentication was never enforced at the route level.

• How I confirm it: open protected URLs directly without a session and see whether data still renders.
• If access control only exists in UI buttons or hidden links, it is not real auth.

4. Backend endpoints trust the client too much.

• How I confirm it: inspect API routes for missing session validation, role checks, or tenant checks.
• If an endpoint accepts `userId` from the request body without verifying ownership, that is a broken boundary.

5. Preview deployments leaked production data or secrets.

• How I confirm it: compare preview env vars with production vars and review recent deploys on Vercel.
• This often happens when preview builds point at production APIs with shared credentials.

6. Repo history contains old secrets even after code cleanup.

• How I confirm it: inspect git history and commit diffs for previously committed keys.
• If a secret ever hit git history or CI logs, rotate it anyway.

The Fix Plan

My goal here is not just to hide the problem. I want to move all sensitive operations behind server-side controls so the portal can be safely deployed again without creating another leak.

1. Rotate every exposed secret first.

• Revoke the leaked API key immediately.
• Generate new credentials for any service that may have been exposed through code, logs, or bundles.
• If payment data or customer records were reachable, treat this as an incident review with access logs checked before relaunch.

2. Remove secrets from all client-side code paths.

• Replace direct SDK calls from React components with server-side routes or server actions.
• Keep only public configuration in the browser if it truly needs to be there.
• Anything that can create charges, read private records, send email, or call admin APIs should not run on the client.

3. Add real authentication at entry points and route handlers.

• Require session validation before rendering private pages or returning private data.
• Enforce authorization per user or tenant on every protected request.
• Do not rely on front-end redirects alone because they are easy to bypass.

4. Separate public pages from private portal surfaces.

• Put marketing pages on one side and authenticated app routes on another side if possible.
• Protect dashboard routes with middleware or server-side checks before data loads.
• Make sure subdomains like `app.` and `www.` have clear roles so there is less accidental exposure.

5. Move sensitive integrations behind backend endpoints.

• Use serverless functions or API routes on Vercel to talk to external services securely.
• Store secrets only in Vercel environment variables for server runtime use.
• Add least-privilege scopes so each integration can do only what it needs.

6. Lock down deployment settings and headers through Cloudflare plus Vercel if applicable.

• Enable SSL everywhere and force HTTPS redirects.
• Turn on caching only for safe public assets; never cache authenticated responses unless you know exactly why.
• Add basic security headers like `Content-Security-Policy`, `X-Frame-Options`, and strict referrer policy where appropriate.

7. Clean up logging so secrets do not reappear later.

• Strip tokens from error messages before they hit logs or monitoring tools.
• Avoid logging request bodies on auth routes unless absolutely necessary during debugging and then remove it fast afterward.

8. Add monitoring before shipping again.

• Set uptime checks on login page availability and critical portal routes after deploys stabilize at around 99.9 percent uptime target monthly if this is customer-facing SaaS behavior expected by paying users?

Wait no question marks? Must be article body only; but okay maybe avoid rhetorical questions? Let's continue cleanly

8. Add monitoring before shipping again." But need final clean answer no mistakes? Let's continue from there maybe acceptable though issue due analysis cut? Need final coherent ending.

References

• [roadmap.sh - API security](https://roadmap.sh/api-security-best-practices)
• [OWASP API Security Top 10](https://owasp.org/www-project-api-security/)
• [MDN Web Docs - HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP)
• [Cloudflare DNS documentation](https://developers.cloudflare.com/dns/)
• [Sentry documentation](https://docs.sentry.io/)

---

Take the next step

If this is a problem in your product right now, here is what to do next:

• [Use the free Cyprian tools](/tools) - estimate cost, score app risk, check launch readiness, or pick the right service sprint.

• [Book a discovery call](/contact) - I will tell you honestly whether you need a sprint or if you can DIY the next step.

*Written by Cyprian Tinashe Aarons - senior full-stack and AI engineer helping founders rescue, launch, automate, and scale AI-built products.*