How to Tell If an App Is Vibe Coded (and Why It Matters for Security)

"Is this site vibe coded?" has become a common question, sometimes out of curiosity and sometimes as a criticism. There is no reliable vibe code detector, and being built with AI is not a flaw on its own. Plenty of excellent software is written with Claude, Cursor, and Copilot.

The signs are still worth understanding, for one practical reason: the same patterns that make an app recognisable as AI-built are often the ones that make it easy to probe. If you built your app this way, this guide shows you what an outsider can see and what to check on your own app.

A note on scope: everything below is about observing what any visitor's browser already receives. Use it to review apps you own or are authorised to test. Probing someone else's app for weaknesses without permission is illegal in many places and not something we help with.

---

Visual signs

These are the weakest signals, because good designers use the same tools.

• Default component library styling. Many AI builders generate interfaces with shadcn/ui and Tailwind CSS. Untouched defaults, such as the same card shadows, rounded buttons, and neutral palettes, are a common tell.
• Generic hero copy. Headlines like "Transform your workflow with AI-powered insights" paired with three feature cards and a gradient.
• Placeholder leftovers. Lorem ipsum, "Your Company", example testimonials, or broken links in the footer.
• Builder badges. Some platforms add an "Edit with Lovable" or "Made with Bolt" badge to apps on free plans or default settings.

None of these say anything about security. They are just recognisable.

---

Technical signs in the browser

These are stronger signals, and they are the ones that matter for security, because they show how the app talks to its backend.

Requests straight to a hosted database

Open the Network tab in your browser's dev tools and use the app. If you see requests going directly to a *.supabase.co URL or to Firebase endpoints, the front end talks to the database itself rather than through your own API.

This is a normal, supported architecture. It also means your database's access rules are your entire security model. If Supabase row-level security is off or too permissive on a table, anyone with the public anon key, which is in every visitor's browser by design, can query it. Our Supabase row-level security guide shows how to check this on your own project.

Public environment variables in the bundle

In Next.js, any variable prefixed NEXT_PUBLIC_ is compiled into the JavaScript sent to the browser. Vite uses VITE_ the same way. These are meant for values that are safe to be public, such as a Supabase URL and anon key.

Vibe-coded apps sometimes put the wrong things there: NEXT_PUBLIC_OPENAI_API_KEY, a Stripe secret key, or a Supabase service role key. If those are in the bundle, they are public. See the Next.js environment variables documentation for how bundling works.

Hosting and framework fingerprints

Response headers and asset paths often reveal the host and framework: x-vercel-id, /_next/static/ paths, Netlify or Replit domains, and so on. These are not vulnerabilities, and plenty of hand-written apps use the same stack.

Verbose errors

Error messages that include stack traces, file paths, SQL, or raw API responses are common in apps that went from prototype to production without hardening. They help attackers understand how the app works.

---

Signs in behaviour

Some patterns show up when you use the app normally.

• Authorization in the UI only. Admin buttons hidden for regular users, but the underlying request still works if sent directly. You can only verify this safely on your own app.
• Sequential IDs in URLs. /invoice/1042 invites someone to try /invoice/1041. Sequential IDs are not a vulnerability by themselves, but combined with a missing ownership check they become one. See the IDOR bug in AI-generated API routes.
• No rate limits. Login or OTP forms that accept unlimited attempts.
• Paid features unlocked by redirect. Access granted when you land on the checkout success page rather than after the payment provider confirms.

---

Why it matters: recognisable means targetable

Attackers automate. If a set of apps share the same stack and the same common mistakes, it is cheap to scan many of them for the same issue: public Supabase tables, exposed keys in bundles, or unsigned webhook endpoints.

That is the real reason to care whether your app looks vibe coded. Not the aesthetics, but whether you have left the default doors open that automated scanners look for first.

---

Check your own app in 20 minutes

Run these against an app you own:

1. Search your deployed bundle. Open dev tools, go to Sources, and search across files for sk_, sk-, service_role, secret, and the prefixes of any API keys you use.
2. List direct database calls. In the Network tab, note every request to Supabase or Firebase. For each table involved, confirm the access policy restricts rows to their owner.
3. Replay a request as another user. Create a second account and replay a request for the first account's data. It should fail. The full method is in our guide on how to test vibe-coded apps.
4. Trigger an error. Submit a malformed request and confirm the response does not include a stack trace or internal details.
5. Remove builder badges if you do not want to advertise the stack, and replace placeholder content.

For a broader pass, take the free vibe code security check or work through the 25-point vibe-coded app security checklist.

---

If your app is vibe coded, that is fine

Being built with AI is not the problem. Unreviewed is. If you built with Lovable, Bolt, Replit, or Cursor, our platform security audit pages explain what we check for each one, including the Lovable security audit. For any stack, our code audit service reviews the logic automated tools miss.

---

FAQ

Is there a tool that detects vibe-coded apps?

Not reliably. Some tools guess based on UI patterns or hosting, but AI-assisted and hand-written code look the same once a developer has edited them. The useful question is whether the app is secure, not how it was built.

Is it bad if my website looks vibe coded?

Not by itself. It can affect how customers perceive polish, and recognisable defaults can attract automated scanning for common misconfigurations. Customise the design and fix the defaults.

Can people see my Supabase key in the browser?

Yes, the anon (publishable) key is meant to be public. That is safe only if row-level security is enabled with correct policies on every table. The service role key must never reach the browser.

How can I tell if my own app has vibe coding security issues?

Search the deployed JavaScript for secrets, check database policies, and run a two-account access test. Our guide on how to test vibe-coded apps walks through each step.