VibeAudits
Free tool · No sign-up

Free Vibe Code Security Check

Answer 15 questions about your AI-built app and get a risk score with a prioritized list of what to fix. It takes about three minutes. Your answers stay in your browser.

0 of 15 answered

Secrets

Are all API keys and passwords stored in environment variables, with none committed to your repo or its history?

Have you confirmed no secret keys (Stripe secret, service role, OpenAI) are bundled into browser code?

Authentication

Does login use an established provider or library (Supabase Auth, Clerk, Auth.js, Firebase Auth) rather than custom code?

Are login, sign-up, password reset, and OTP endpoints rate limited?

Are admin and paid-only features checked on the server, not just hidden in the UI?

Data access

Have you tested with two accounts that user A cannot read or edit user B's data by changing an ID?

If you use Supabase or Firebase, are row-level security policies or security rules enabled and restrictive on every table?

Are uploaded files private by default and validated for type and size?

Payments

Is paid access granted only after a verified payment webhook, with the signature checked?

Are prices and totals calculated on the server rather than sent from the browser?

AI features

Do AI features have per-user usage limits and a hard spending cap with your model provider?

If your AI can call tools or read user content, have you limited what it can do when given malicious instructions?

Deployment

Are detailed error messages and stack traces hidden from users in production?

Are dependencies up to date, with a committed lockfile and no packages you don't recognise?

Do you have automated database backups that you have restored at least once?

Answer every question to see your score.

Copy-paste security review prompt

Open your project in Claude Code, Cursor, Codex, or Windsurf and paste this prompt. It asks the model for a structured, read-only review instead of a vague "is this secure?", which produces findings you can actually act on.

You are a senior application security reviewer. Review this repository for
security issues before it goes live with real users and payments.

Work through these areas in order. For each finding, give: the file and line,
what an attacker could do, how to reproduce it, and a minimal fix.

1. Secrets: hardcoded keys, tokens, or passwords in code, config, or git
   history; secret keys exposed to the browser (NEXT_PUBLIC_, VITE_, etc.).
2. Authentication: custom password handling, session/JWT expiry, weak or
   hardcoded signing secrets, password reset and email verification flows,
   missing rate limits on login, sign-up, reset, and OTP endpoints.
3. Authorization: every API route, server action, and database query that
   reads or writes user data. Does it check the caller owns the record or has
   the role? Flag any check that only exists in the UI.
4. Database rules: Supabase RLS policies or Firebase security rules that are
   missing, disabled, or overly permissive (e.g. "using (true)").
5. Payments: webhook signature verification, access granted before payment is
   confirmed, prices or quantities trusted from the client.
6. Input handling: SQL/NoSQL injection, unsafe HTML rendering, file upload
   validation, server-side requests to user-supplied URLs.
7. AI features: prompt injection paths, tools the model can call and with
   whose permissions, missing per-user usage limits.
8. Dependencies and config: unknown or unused packages, permissive CORS,
   verbose production errors, debug endpoints left enabled.

Do not change any code yet. Output a table of findings sorted by severity
(Critical, High, Medium, Low), then list what you could NOT verify from the
code alone.

What an AI self-review can't catch

  • Configuration outside the repo. Supabase policies edited in the dashboard, Firebase rules, environment variables, and hosting settings are often invisible to the model.
  • Business rules nobody wrote down. The model cannot know that only team owners should export data or that trials must not unlock a feature unless you tell it.
  • Behaviour at runtime. Reading code is not the same as replaying a request with another user's session. Two-account testing finds access-control bugs that look correct on the page.
  • The model's own blind spots. If the tool that wrote the code misunderstood a security concept, it will often make the same mistake when reviewing it.

For a thorough manual pass, use the 25-point vibe-coded app security checklist, see platform-specific security audits for Lovable, Bolt, Replit, Supabase, and more, or explore our code audit services.

Frequently asked questions