Vibe coded app audit: seven checks for an app an AI tool built
A vibe coded app audit reads the code, the database rules and the deployment that an AI tool chose for you, then tests the parts that decide who sees what. It looks hardest for what the tool never wrote, because a scanner cannot flag a check that is missing.
Auditing AI-built apps
- Covers
- Claude Code, Cursor, Bolt, v0, Replit
- Checks
- Seven, each with a pass test
- Starts with
- Who can see each record
- Ends with
- A test for every finding
- Digiton offer
- Free call, then paid review
The short answer
A vibe coded app audit works through seven checks: who can read or change each record, where keys and secrets live, how people sign in, what input the app trusts, how it behaves under abuse, what the deployment exposes, and whether anyone would notice a failure. Each check has a pass test you can run before real users arrive.
Why audit AI-written code at all
45 percent. Veracode's July 2025 report tested more than 100 models on 80 coding tasks and found security flaws in 45 percent of the results. Security results stayed flat as the models improved at writing working code.
100 percent. OWASP's 2025 Top Ten reports that every application tested had some form of broken access control, and it keeps the category at number one.
Your share. Replit's own security checklist says that although the platform provides many security features out of the box, you still have to add measures for your application. Bolt's audit works the same way and lists action items that you handle yourself, such as a setting in a connected payment service.
The seven checks
The checks run in this order because the first one does the most damage when it fails. Vendor documentation was read on 19 October 2026.
| Check | What AI-built apps often get wrong | Pass test |
|---|---|---|
| Who can read or change each record | Tables with no row-level rules, or an ID in the address that the server never ties to the signed-in user | Sign in as one user, request another user's record by its ID, and expect a refusal. On Supabase, every exposed table has row level security on and no stray grants |
| Where keys and secrets live | A service key or API key in code the browser downloads, or left in the repository history | Search the built bundle and the Git history for each key and rotate any you find. In Next.js apps only variables with the public prefix reach the browser, so check each one |
| How people sign in | Hand-rolled login code, email confirmation switched off, sessions that survive sign-out | Sign out and replay a saved request. Create an account with an unconfirmed email and see what it can reach |
| What input the app trusts | Uploads with no type or size limits, links the server fetches for visitors, user text drawn as HTML, SQL built by joining strings | Upload a script, paste markup into every text field and put quotes in every search box |
| How it behaves under abuse | No rate limits, and a route that calls a paid model that anyone can reach | Repeat sign-in attempts until something stops them, and call the model route without signing in |
| What the deployment exposes | Debug output on, public preview addresses, one shared environment, no way back to the last good release | Open the live site's network tab and look for debug output and source maps, then restore the previous release |
| Whether anyone would notice | Errors with no alert, and logs or error pages that print private data | Break something on purpose and time how long until a person is told |
A date to know if you use Supabase
On 30 October 2026, Supabase changes what a new table exposes by default.
Supabase announced on 28 April 2026 that new tables in the public schema will stop being exposed to its Data API automatically, with the change reaching every existing project on that date. Existing tables keep their current grants. Migration files that an AI tool wrote before then assume the old defaults, so read the grants on each new table instead of trusting the tool. Supabase's documentation also says that adding a policy does not take back an existing grant, so a table can stay writable by the anon role until someone revokes it.
What the tool's own check covers
Run the built-in check first and fix what it finds. A second reader then looks at what the first one was never built to see.
| Tool | Built-in help | What the documentation says it does |
|---|---|---|
| Bolt | A security audit from the Publish menu on paid plans, and a database security check on every plan | Reviews who can see and change data, what is public, sign-in, misuse, input and keys, fixes most problems and lists action items for you |
| Replit | A written security checklist | Lists front-end, back-end and ongoing measures, and says you still add measures for your own application |
| v0 | Security documentation and warnings | Warns about risky use of public environment variables and can move code to server-side contexts, where server variables stay out of the browser |
| Cursor | Guardrails on the agent | Requires approval for terminal commands and connected tools by default, which limits what the agent does while it writes. It describes guardrails on the agent and says nothing of reviewing the finished app |
| Claude Code | A security review command and a security guidance plugin | Runs an on-demand security pass over the changes on your current branch, and has Claude review its own changes during the session |
What automated checks do well
- Known patterns such as a missing row-level rule, a key in client code or an outdated package.
- Repeatable runs after every change.
- Coverage of every file, including the dull ones.
What a reviewer adds
- Intent. A discount code that works twice or a refund route anyone can call follows the app's own rules, so no pattern flags it.
- Two accounts. Access bugs show up when one real user tries to reach another's data.
- Cost and failure. What happens to the bill and the data when a route is hammered.
- A test for each finding, so the fix stays fixed.
A finding is finished when a test fails without the fix
The best audit finding ends with a test. When one of our agent actions could do harm, the rule that stops it is a function with unit tests, so a later edit that breaks the rule fails the build. Digiton's agent fleet is a public repository where every send passes unit-tested rails, and twenty-seven tests cover them.
An audit of a vibe coded app should leave the same thing behind. A first test signs in as one user and asks for another user's record. Another scans the built bundle for the service key, and a third fails when a new table appears without a row-level rule. A finding with no test comes back the next time the AI tool rewrites the file. The code behind our rails is on GitHub.
How Digiton audits an AI-built app
- Scoping call. Free, 25 minutes, about the app itself, and it decides whether the work fits.
- Production review. We read the real repository and infrastructure and give you a scorecard across ten layers with evidence for each, the result of one load test and a fix list with a cost on every line. The seven checks above sit inside it.
- Fixed-scope build. This follows only if you want us to do the work, and it ends when the acceptance tests pass.
The review is described on our production review page, and the full standard is on production engineering. Larger builds sit under custom AI development, and agents acting in your systems under AI agent development.
Teams using Claude Code can read what a Claude Code consultant should leave behind and the Claude Code governance policy. If the app was built on Lovable, the Lovable security audit and Lovable app to production pages cover its own scans.
Sources, checked 2026-10-19
11 sources
- Veracode's 2025 GenAI Code Security Report tested more than 100 models on 80 coding tasks and found security flaws in 45 percent of cases, and security performance had not improved over time.Source: veracode.com, checked 2026-10-19.
- In the OWASP Top 10 2025, broken access control stays at number one and every application tested had some form of it.Source: owasp.org, checked 2026-10-19.
- A table in an exposed schema without row level security is readable and writable by any role with a grant on it. Adding policies does not remove grants. The service role bypasses row level security.Source: supabase.com, checked 2026-10-19.
- Supabase stops exposing new public tables to the Data API by default on all existing projects on 30 October 2026. Existing tables keep their grants. The announcement is dated 28 April 2026.Source: github.com, checked 2026-10-19.
- Replit says it provides many security features out of the box and that you add measures for your own application. Its checklist covers input validation, secrets, authentication, authorization, SQL injection, headers, error handling, cookies, uploads and rate limiting.Source: docs.replit.com, checked 2026-10-19.
- Bolt offers a project security audit from the Publish menu on paid plans and a database security check on all plans. The audit covers data access, public information, sign-in, misuse, input and keys, fixes what it can and lists action items.Source: support.bolt.new, checked 2026-10-19.
- In v0, only environment variables with the NEXT_PUBLIC_ prefix reach the browser. v0 analyzes that usage and warns about risks, and can move code to server-side contexts.Source: v0.app, checked 2026-10-19.
- Cursor requires approval for terminal commands and MCP connections by default, calls Run Modes best-effort guardrails rather than a hard security boundary, and describes guardrails on the agent.Source: cursor.com, checked 2026-10-19.
- Claude Code has an on-demand security review command for the changes on your current branch and a security guidance plugin that has Claude review its own changes during the session.Source: code.claude.com, checked 2026-10-19.
- Denial of wallet, where high-volume use exploits the cost-per-use model of a model API, is a named risk in the OWASP LLM Top 10 under unbounded consumption.Source: genai.owasp.org, checked 2026-10-19.
- Digiton's public agent fleet repository: ten scheduled agents, five rails on every action and unit tests on the rails.Source: github.com, checked 2026-10-19.
Digiton Dynamics OÜ is registered in Tallinn, Estonia, and delivers from Lisbon.
Frequently asked questions
What is a vibe coded app audit?
A structured review of an app that an AI tool wrote most of. It covers data access, secrets, sign-in, input handling, abuse limits, deployment and monitoring, and it ends with a ranked list of findings and a test for each fix.
Is a scanner or the built-in security check enough?
It is a good first pass, and the tools document their own help: Bolt, Replit, v0, Cursor and Claude Code all describe some. A scanner reports patterns it knows. A reviewer tests with two accounts, reads intent and checks that the fixes hold.
Which tools does an audit cover?
Any of them. The checks apply to apps built with Claude Code, Cursor, Bolt, v0, Replit or a mix, because the failures sit in the code, the database rules and the deployment, whichever tool wrote them. Lovable apps have their own pages on this site.
What should I check myself first?
Sign in as one user and request another user's record by its ID. Search your built bundle and repository history for keys. Confirm that email confirmation is on, that sign-in has a rate limit, and that you can restore the last good release. Each takes little time and tests a layer where access control, secrets and abuse limits tend to fail.
Does the auditor need my production passwords?
No. A review starts from the repository and read-only access to the database settings. Any key the auditor sees in code or history should be rotated afterwards, and every account stays in your name.
Does a clean audit mean the app is secure?
It means the app passed the checks on the day they ran. The next prompt can rewrite a file and undo a fix, which is why each finding should leave a test behind and why the checks should run again before a big release.
Talk to an engineer about your system
Book a free 25-minute scoping call. We tell you what we would build, what it takes to keep it running, and whether we are the right fit.