Guides / Security

Vibe coding security: 12 checks before your app meets strangers.

The speed of AI coding tools is real, and so is the pattern in the audits: Veracode's testing found roughly 45% of AI-generated code introduces a security weakness, and scans of live vibe-coded apps keep surfacing exposed keys, open databases, and leaked personal data. This checklist is how you avoid joining that sample.

Dualbytes Engineering Updated July 2026 8 minute read

Why a checklist, not vigilance.

Nobody ships an open database on purpose. It happens because launch week is busy, the demo works, and the gaps are invisible from inside the app. A checklist externalises the paranoia: twelve concrete checks, most under ten minutes, each closing a failure mode we have seen in real AI-built apps. Run it before launch, and again after any big schema or feature change.

The twelve checks.

  1. No secrets in the client bundle. Build the app, then search the output for key prefixes like sk- and provider names. Anything found is already public; follow the leaked key response plan.
  2. Database access rules on, with default deny. Probe your own database signed out. The exact commands are in the Supabase RLS and Firebase rules guides.
  3. Authorisation enforced server-side. Signed-in is not allowed. Ownership and role checks live in database policies or server code, never only in the interface. See auth hardening.
  4. Every write validated. Types, ranges, and ownership checked at the boundary. Assume the client is lying; a tampered request should bounce, not persist.
  5. Public endpoints rate limited. Signup, login, password reset, and anything that sends email or calls a paid API. One hostile loop against an unlimited endpoint is a bill or an outage.
  6. File storage rules checked separately. Buckets have their own policies. Locked tables with an open bucket still leak every uploaded document.
  7. HTTPS everywhere plus baseline headers. Redirect HTTP, and set X-Content-Type-Options, frame-ancestors, and a Content-Security-Policy. An hour of work, permanent raise of the floor.
  8. Dependencies audited. Run npm audit (or your ecosystem's equivalent), commit the lockfile, and update anything with a known critical. AI tools pin whatever was current when they generated.
  9. Errors do not leak internals. Trigger a failure on purpose: users should see a plain message, while stack traces, SQL, and paths stay in your logs.
  10. Backups exist and restore. Automated backups on, and one restore actually performed into a scratch environment. Untested backups fail at the worst possible moment, by definition.
  11. Someone is watching. Error tracking and an uptime check, wired to a channel someone reads. Silent failure is how small incidents become long ones.
  12. Personal data mapped. Know every table and bucket that holds personal information, and why. If South Africans are in your data, read the POPIA guide; an open database is a legal event here, not just a technical one.

How to use the list without it decaying.

Checklists rot when they live in someone's head. Put this one in your repo as a markdown file, tick it in the pull request that ships each launch, and re-run items 1, 2, and 6 after every schema change; those three drift the most as AI tools add tables and buckets. The probes are one-line curl commands, so there is no excuse not to automate them into CI eventually.

The honest limitation A checklist catches the known failure modes. It does not catch the interaction between your specific data model, your auth flow, and that one edge function the AI wrote at 2am. That is what a human review is for: the checklist covers the standard gaps, a senior engineer covers yours.

Questions

Questions founders ask.

Is vibe coding inherently insecure?

No. The insecurity is in shipping unreviewed defaults, not in using AI to write code. Veracode's testing put a number on it: roughly 45% of AI-generated code samples fail basic security tests. Reviewed, hardened AI-built apps run in production safely. The failure pattern is skipping the review because the demo worked.

Which of the twelve checks matters most?

Secrets and database rules, checks one and two. They are where the catastrophic, minutes-to-exploit failures live: a leaked provider key or an open database needs no skill to abuse. Everything else on the list matters, but those two are the difference between an incident and a breach.

Do AI coding tools handle security automatically now?

They are improving, and some now scaffold auth and rules by default. But independent scans of live vibe-coded apps continue to find exposed keys, open databases, and missing access controls at scale. Treat anything the tool generated as unverified until you have run the checks; verification is cheap, assumptions are not.

Who should run this checklist if I am not technical?

Most checks are runnable by a technical friend in an afternoon, and each linked guide gives exact commands. If nobody in your orbit fits, that is precisely the gap a fixed-scope production-readiness review fills: senior engineers run all of it against your real app and hand you the ranked results.

Past the checklist

The checklist finds the standard gaps. A review finds yours.

Twelve checks cover the known failure modes. A production-readiness review covers the ones specific to your app: your data model, your auth flow, your infrastructure, reviewed by senior engineers, with a ranked fix list at the end.

Request a production-readiness review See what the review covers