Check your vibe-coded app before you show anyone

When an agent needs an API to work, the fastest path is pasting the key right where the call happens. That is how live payment keys end up in browser code, readable by anyone who opens dev tools. A leaked key can mean real charges on your account and a database that answers to strangers. Exposed secrets are the most common real world failure in AI-built apps.

Check it yourself

• Open your live site, open the browser dev tools, and search the loaded JavaScript for key shaped strings: sk_live, service_role, AKIA, api_key.
• Search your repo for committed .env files and for env values copied into the build output.
• If a real key is exposed, removing it from the code is not enough. Bots scan public repos for fresh keys around the clock, so treat any key that was public even for a few seconds as compromised. Rotate it with the provider before the bots find it. Old commits and old copies of the build still hold the value.

What Seatbelt reads: the secrets surface. Key patterns and env looking names anywhere in the build you hand it. A secret in the public build is a must fix, and with the push gate wired that push parks on a pull request instead of main until the key is out and rotated. Publishable keys, like Stripe pk_ values, are expected in front end code and stay noted.

App platforms hand the browser a public database key and trust the database's own rules to keep users apart. Row level security is that rule set. When it is off, or the policy never checks who is asking, every row in the table is one API call away from any visitor. RLS can also be toggled on while a policy still allows everything, or while INSERT and UPDATE policies omit WITH CHECK: reads look scoped in the dashboard, but a signed-in user can still write rows as someone else. Real apps have leaked every user's private messages exactly this way.

Check it yourself

• Supabase: check each table in the public schema. Row level security on for every one, with a policy that filters by the signed in user's id rather than allowing everything.
• On INSERT and UPDATE policies, open the SQL. A USING clause alone is not enough: confirm the same policy has WITH CHECK so a user cannot write a row with another user's id.
• Firebase: read your Firestore and Storage rules. allow read, write: if true means open to anyone. It is the classic paste-over for expired test mode, and it ships to production more often than anyone admits.
• The blunt test: create a second account and use it to request the first account's data through your app's API. If it answers, the rules are not doing their job.

What Seatbelt reads: the databases surface. Code cues only: a service key shipped to the browser, rules files that allow everything, database URLs in public code, raw SQL built by string glue, database files sitting in public folders. The careless ones are must fix. Seatbelt never connects to your live database. It reads the build you hand it.

Agents are good at hiding buttons from signed out users. Hiding is not checking. If the API route behind the screen never asks who is calling, anyone can call it directly and skip your UI entirely. Next.js server actions are a second gap: the page can verify the session at render while the action file deletes or updates with no ownership check. The page check runs once. The action runs on every direct POST. A common AI auth pattern decodes a JWT payload without verifying the signature first, so a forged token can pass the middleware. Login handlers that return different messages for unknown email vs wrong password leak which addresses are registered. Forgot-password flows often ship plain reset tokens in the database with no expiry or single-use guard. A separate miss is unlimited login attempts: a 2026 study of vibe-coded apps found roughly 80% lacked rate limiting on at least one auth endpoint, so brute-force and account-enumeration scripts can run as fast as the network allows. A 2026 study of 100 vibe-coded apps found roughly one in five had API endpoints with no authentication at all.

Check it yourself

• Sign out, then call your API routes directly with curl or the address bar. Anything that returns user data while signed out is open.
• Sign in as a test user, find a request with an id in it, and swap the id for another user's. If their data comes back, the route checks that you are signed in but not what belongs to you.
• Read each API handler. The auth check belongs at the top of the handler, before the database read. A check in the page component protects nothing.
• Next.js: open each file with 'use server' that calls .delete(, .update(, or Prisma writes. The action should import your session helper and verify the caller owns the row before the mutation. Page protected does not mean action protected.
• In JWT middleware, search for jwt.decode or decode( on the token. The same function block should call jwt.verify (or jwtVerify) with an explicit allowed-algorithms list before you trust the payload. Decode-then-use-then-verify order is still a miss.
• Login enumeration: try a random email and a known email with a wrong password. If the API returns different messages, you are leaking which addresses are registered. Both paths should return the same generic invalid-credentials response. See auth account enumeration for why it matters.
• Password reset: open your forgot-password handler and user schema. A plain resetToken or passwordResetToken column without a hash, an expiresAt window, and a used or invalidated flag is account takeover if the row leaks. Practitioner audits in 2026 found reset tokens with no time bound in several of ten vibe-coded codebases reviewed.
• Rate limiting: open each login, register, and forgot-password route (or app/api/auth/ handler). Search the file and middleware.ts for rateLimit, @upstash/ratelimit, express-rate-limit, or an edge limiter. If bcrypt compare or JWT sign runs with no throttle before it, attackers can brute-force passwords or spray sign-ups. A common baseline is about 5 attempts per minute per IP on auth routes.

What Seatbelt reads: the login surface. Seatbelt notes where sign in lives and flags identity APIs and data handlers that read a store with no auth guard in the handler body. It also soft-flags distinct login error strings in the same handler and plain reset-token storage without expiry or single-use fields. Auth rate-limit cues are on the detector roadmap: use the hand-check above until repo read ships for that class. Open looking routes are marked worth a look, with the file and line, so your agent knows exactly where the check goes.

Builds accumulate scaffolding: an admin page for testing, a debug route that dumps state, an export endpoint meant for one internal use, a delete helper from an early reset flow. When an agent adds "export user data as CSV" late in a long chat, it often ships a handler that streams the whole table with no session check. The feature looked scoped in the prompt. The endpoint is public. A second class hides in link-preview and image-proxy features: a URL from the query string or form flows straight into fetch() on the server with no host allowlist, so your app can be tricked into calling 169.254.169.254, localhost, or internal VPC addresses. Georgia Tech's Vibe Security Radar lists SSRF among top AI-attributed CWE classes in 2026 advisories. Agents rarely clean these up on their own, and one public delete route can end a project in an afternoon.

Check it yourself

• Search your routes for admin, debug, test, export, dump, backup, reset, and delete.
• Open each export, dump, backup, or download-all route while signed out. If it returns rows, the handler needs getServerSession, getToken, or your auth helper before the query.
• SSRF: in server actions and route handlers, search for fetch( or axios.get( where the target URL comes from searchParams, formData, or the JSON body (url, target, webhookUrl, and similar). The handler should allowlist hosts, block private IPs and link-local ranges, and set redirect: "error" on outbound fetches. A UI that never shows a URL field is not a defense: server actions are direct POST endpoints.
• Open next.config (or next.config.mjs). images.remotePatterns with hostname: "**" turns image optimization into an open proxy. Tighten patterns to hosts you actually serve.
• Anything that changes or exports data goes behind auth. Anything destructive should not ship at all.
• Include the neighbors: a database admin UI deployed next to the app counts as an open admin route.

What Seatbelt reads: the risky shortcuts surface. Open admin pages, debug leftovers, and export or delete routes get flagged, and destructive ones are a hard stop that parks the push on a pull request until they are gone. Outbound-fetch SSRF cues are on the detector roadmap: use the hand-checks above until repo read ships for that class.