How I Would Fix database rules leaking customer data in a Bolt plus Vercel client portal Using Launch Ready.

How I Would Fix database rules leaking customer data in a Bolt plus Vercel client portal Using Launch Ready

The symptom is usually simple and scary: one client logs into the portal and sees another client's invoices, files, messages, or profile data. In a Bolt plus Vercel build, the most likely root cause is not "the app is hacked", but that the database rules, API access pattern, or row-level authorization are too loose.

The first thing I would inspect is the exact data path from browser to database. I want to know whether the portal is reading directly from a backend with weak rules, whether a serverless function is exposing too much, or whether the frontend is trusting client-supplied IDs instead of enforcing ownership on the server.

Triage in the First Hour

1. Check the affected screens and reproduce the leak with two test accounts.

• Confirm what data crosses tenant boundaries.
• Note whether the leak is read-only or also allows edits.

2. Inspect auth state in the browser.

• Verify session cookies, tokens, and user identity claims.
• Check if the portal stores sensitive data in localStorage or exposes it in client state.

3. Review recent Vercel deploys.

• Look at deployment timestamps, commit hashes, and rollback options.
• Identify whether the issue started after a schema change, rule change, or frontend refactor.

4. Open database rule files or security policies.

• For Supabase-style projects, inspect row-level security policies.
• For Firebase-style projects, inspect Firestore/Realtime Database rules.
• For custom APIs, inspect authorization middleware and query filters.

5. Check logs for cross-tenant reads.

• Look for requests where user A requests records owned by user B.
• Review function logs for missing ownership checks.

6. Inspect environment variables in Vercel.

• Confirm no service role keys are exposed to client-side code.
• Check that production and preview environments are separated.

7. Review any recent "temporary" bypasses.

• Search for admin flags, wildcard rules, debug endpoints, or `allow read: if true` style shortcuts.

8. Freeze risky changes until you understand scope.

• Pause new deployments if customer data exposure is active.
• If needed, put the portal in maintenance mode for affected areas only.

A simple diagnostic command can help confirm whether policies are too open:

grep -R "allow.*true\|public\|service_role\|bypass\|admin" .

That will not find every issue, but it quickly surfaces obvious mistakes before I spend time on deeper debugging.

Root Causes

| Likely cause | What it looks like | How I confirm it | |---|---|---| | Missing row-level security | Any authenticated user can read all rows | Test two users against the same table and compare returned records | | Overbroad database policy | Policy filters by auth only, not tenant or owner | Review policy logic for `user_id`, `org_id`, or `account_id` checks | | Client-side filtering only | Frontend hides other users' data but API still returns it | Inspect network responses instead of just UI behavior | | Serverless function uses privileged key incorrectly | Vercel function can read everything without ownership validation | Audit function code for service role usage and missing auth guards | | Broken tenant mapping | Records are linked to wrong org IDs or null foreign keys | Query sample rows and verify ownership fields are populated correctly | | Preview/prod config mix-up | Preview env points to production DB or shared auth project | Compare Vercel environment variables across branches |

The most common failure I see in AI-built portals is this: the UI looks filtered, so founders think access control exists. In reality, the browser receives too much data and simply hides some of it on screen.

The Fix Plan

1. Stop the bleed first.

• If customer data is exposed broadly, disable public access paths immediately.
• Roll back to the last known safe deploy if that reduces exposure faster than patching live.

2. Move authorization to the server or database layer.

• Do not rely on React state or hidden UI controls to enforce privacy.
• Every query must be scoped by authenticated user ID, account ID, or organization ID.

3. Tighten database rules.

• Turn on row-level security where available.
• Write allow rules that require ownership match on every read and write path.
• Remove any blanket read policies used during prototyping.

4. Audit all privileged keys.

• Service role credentials must never reach client code in Bolt-generated frontend bundles.
• Keep them only in Vercel serverless functions or protected backend services.

5. Normalize tenant ownership fields.

• Ensure every customer-owned record has a required `user_id` or `org_id`.
• Backfill missing values before re-enabling writes if needed.

6. Patch API routes and server actions together.

• If one endpoint is fixed but another still leaks records through export/download flows, you have not solved it.
• I would review list views, detail views, search endpoints, exports, webhooks, and admin screens as one system.

7. Add defensive defaults in code.

• Reject requests when identity cannot be verified.
• Return 403 on unauthorized access and 404 where hiding existence makes sense for sensitive resources.

8. Re-deploy with a narrow blast radius.

• Ship the auth fix first.
• Do not bundle redesign work, new features, or performance experiments into the same release.

9. Verify logging does not expose secrets or personal data.

• Redact tokens, emails where unnecessary, invoice contents, file links with bearer access, and full payloads from logs.
• Keep audit logs useful but not overexposed.

10. If needed, use Launch Ready to get this stable fast.

• The goal is production safety in 48 hours, not a perfect rewrite.

Regression Tests Before Redeploy

I would not redeploy until these checks pass:

• Two-user isolation test
• User A cannot see User B's records through list views, detail pages, search results, downloads, or API calls.

• Unauthorized direct request test
• A request with a valid session but wrong resource ID returns 403 or safe 404.

• Empty session test
• Logged-out users cannot reach protected endpoints even if they guess URLs.

• Role-based access test
• Admins can do admin actions only when explicitly allowed; normal clients cannot inherit those privileges accidentally.

• Export test
• CSV/PDF/file exports contain only records owned by the current tenant.

• Preview environment test
• Vercel preview deployments do not point at production secrets unless intentionally configured for staging data only.

• Logging review
• No secret keys appear in logs; no raw tokens are echoed back to clients.

Acceptance criteria I would use:

• Zero cross-tenant reads in manual testing across at least 2 accounts and 10 sample records each.
• All protected endpoints return correct status codes within p95 under 300 ms for normal reads after auth checks are added.
• No customer-owned record can be fetched without matching ownership claims in both UI tests and direct API tests.
• Rollback plan documented before merge if any check fails.

I would also run one quick exploratory pass on mobile because broken auth often shows up differently there due to cached sessions and stale cookies.

Prevention

The real fix is not just better rules. It is making sure this class of bug cannot quietly return after the next Bolt prompt edit or Vercel deploy.

What I would put in place:

• Security code review gate
• Every change touching auth, queries, storage buckets, webhooks, or exports gets reviewed for tenant isolation first.

• Least privilege by default
• Use separate roles for app users, admins, background jobs, and deployment tooling.

• Monitoring on suspicious reads
• Alert when one account reads an unusual number of records from many tenants in a short window.

• Error budget for security regressions
• Treat another cross-tenant leak as a release blocker until root cause analysis is complete.

• Safer UX around account switching
• Make active workspace visible at all times so users do not think they are looking at their own data when they are not.

• Dependency hygiene
• Keep database SDKs and auth libraries updated because old versions often carry edge-case bugs around token handling and middleware behavior.

• Production observability
• Track failed authorization attempts separately from general errors so you can spot abuse without drowning support teams in noise.

• Small releases
• Ship auth fixes alone when possible so you can prove they work before layering more changes on top.

If this portal uses AI features later for support summaries or document search while keeping customer data private concerns high priority should include prompt injection defense too: isolate retrieval scopes per tenant never let model output decide access never pass raw secrets into prompts and add human review for any tool that can modify records

When to Use Launch Ready

Launch Ready fits when you already have a working Bolt-built portal but need me to make it safe enough to ship without guessing.

I would recommend Launch Ready if:

• Your portal works locally but breaks under real deployment conditions
• You suspect secrets were exposed during build time
• You need Cloudflare SSL DNS redirects and monitoring fixed fast
• You want one senior engineer to stop risk before customers see it

What you should prepare before booking:

• Access to Bolt project files repo and deployment settings
• Vercel team access plus environment variables list
• Database admin access or at least policy editing rights
• Domain registrar access if DNS needs changes
• A short list of affected pages tables roles and user types

My advice: do not wait until more customers notice leaked data. The cost of one bad release is usually higher than fixing it properly once with tight scope clear ownership checks and monitored redeploys within 48 hours

References

• https://roadmap.sh/cyber-security
• https://roadmap.sh/api-security-best-practices
• https://roadmap.sh/code-review-best-practices
• https://supabase.com/docs/guides/database/postgres/row-level-security
• https://vercel.com/docs

---

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.*