Vibe coding security: what to check before an AI-built app goes live

Vibe coding security before an app goes live

A vibe-coded app, one built by describing it to an AI tool, is safe to hand to colleagues or customers only after a security check, because the AI writes what the prompt asks for and often leaves out the access checks nobody asked for. Check seven things before go-live: keys and passwords in the code and the browser bundle, sign-in, access rights enforced on the server, database rules such as row-level security, every package the AI added, prompt injection if the app calls a language model, and logging. Free scanners find keys in the code and packages with known vulnerabilities, and a language model on your own workstation reads the code as a second reviewer without the code leaving the company. Sign-in, access rights and database rules need manual tests, a person decides on every finding, and an internet-facing app with customer data also needs a professional security test.

This guide is for the person who built the app with Dyad, bolt.diy, Lovable, Cursor or a coding agent, and for the IT lead who has to approve it. Building such apps is the subject of our guides to internal tools built without developers and to self-hosted Lovable alternatives. Apps on a self-hosted low-code platform are compared in our guide to Power Apps alternatives, and agencies find the client side in our article on client prototypes built with AI.

Why AI-built apps need a security check

A typical prompt says "add a login page"; it rarely says "check on every request that this user may see this record". The app then works in the demo, and the gap shows only when someone sends requests to the backend directly, past the buttons of the interface.

Veracode tested more than 100 language models on 80 coding tasks and reported on 30 July 2025 that the models introduced security flaws in 45 per cent of the cases. For cross-site scripting they failed to produce secure code in 86 per cent of the cases, for log injection in 88 per cent, and larger models did not perform significantly better than smaller ones. The models in that test are older than today's, so the figures show the pattern; current rates may differ.

The OWASP Top 10:2025, OWASP's list of the main risks in web applications, puts Broken Access Control first and states that "100% of the applications tested were found to have some form of broken access control". Four more of its categories map directly onto the checks below: A03 Software Supply Chain Failures, A05 Injection, A07 Authentication Failures and A09 Security Logging and Alerting Failures.

The vibe coding security checklist at a glance

OWASP Top 10:2025 and OWASP Top 10 for LLM Applications 2026, Vite and Supabase documentation, tool READMEs, read 30 October 2026; the selection of checks is our recommendation.

Keys and passwords in the code, the history and the browser bundle

App builders put API keys where the code needs them, and a prompt such as "connect to the payment service" can end with a key in a file that is shipped to every browser. The documentation of Vite, a build tool for JavaScript web apps, states that variables prefixed with VITE_ "will be exposed in client-side source code after Vite bundling" and "should not contain sensitive information such as API keys". Supabase writes about its secret key: "Never use a secret key in the browser or expose it to customers."

Gitleaks, an MIT-licensed secrets scanner, checks a repository's whole history with gitleaks git and any folder with gitleaks dir, so it can also scan the folder with the built app. Its README describes a pre-commit hook that stops a new secret before it is committed. As of October 2026 the README states that Gitleaks is "feature complete" and that future releases "will be security patches only"; its maintainer's focus has moved to Betterleaks, an MIT-licensed scanner from the makers of Gitleaks that can also test online whether a key it finds is still active.

A key that was committed once stays in the git history after the line is deleted. Revoke it at the provider and issue a new one.

Sign-in and access rights belong on the server

OWASP's prevention advice for Broken Access Control is plain: "Access control is only effective when implemented in trusted server-side code or serverless APIs", "Except for public resources, deny by default", and access controls should "enforce record ownership". For an AI-built app, that means three tests:

1. Every API route and every database query checks who is asking. A hidden button in the interface protects nothing.
2. A user cannot open someone else's record by changing an ID in the address bar or in a request. Create two test accounts, copy a request made by the first and send it with the session of the second.
3. Sign-in uses the login service of the backend or the company's existing accounts. A password check that the AI wrote from scratch is the part to replace; OWASP lists Authentication Failures as A07:2025. With company accounts, a leaver also loses access on the day IT disables the account.

Exposed databases and row-level security

Many app builders connect the app to a hosted database that the browser talks to directly; Dyad's documented integrations for data and login, for example, are Supabase and Neon. The browser then holds a public key, and the only thing between that key and your data is the database's own access rules. In Supabase, these are row-level security (RLS) policies: rules inside the database that decide which rows a user may read or change.

Supabase's documentation says to "Enable RLS on every table in an exposed schema" and warns that without RLS such a table is readable and writable by any role holding a grant. With RLS on and no policy yet, "no data is accessible through the API when using a publishable key, until you create policies". Adding policies does not remove grants that already exist, and the secret key uses the service_role, which bypasses RLS.

CVE-2025-48757, published on 30 May 2025 with a CVSS 3.1 score of 9.3, describes insufficient RLS policies in sites generated by a hosted app builder that let unauthenticated attackers read or write arbitrary tables. The record is tagged as disputed: the supplier's position is that each customer is responsible for protecting their own application's data. Either way, check the policies yourself. List every table, confirm that RLS is on, read each policy, and try to read each table with the public key while signed out. Supabase's documentation points to event triggers that switch RLS on for every new table.

Tell us which backend and app builder your apps use, and we suggest the review tools and the workstation that fit them.

Packages the AI invented

Language models sometimes name software packages that do not exist. A study accepted for the 2025 USENIX Security Symposium generated 576,000 code samples in Python and JavaScript with 16 models. On average, at least 5.2 per cent of the packages suggested by commercial models and 21.7 per cent of those suggested by open-source models were hallucinated, with 205,474 unique invented names. The authors call this "a novel form of package confusion attack": whoever registers an invented name on the public registry has their code installed by everyone who follows the AI's suggestion.

The models in that study date from 2024, and the gap between open and commercial models in it is a reason to check every package a local model adds. Before anything is installed, confirm that each new package exists, who publishes it and how long it has been there. OSV-Scanner, an Apache 2.0 scanner built on the vulnerability data of osv.dev, then reads the lockfile and lists known vulnerabilities, sending package names and versions to osv.dev or, in offline mode, using a local copy of the database.

If the app calls a language model

When the app summarises tickets, answers from documents or drafts replies, the OWASP Top 10 for LLM Applications applies too. Its 2026 edition, published on 3 August 2026, keeps Prompt Injection first, moves Excessive Agency up to third and renames System Prompt Leakage to Hidden Context Exposure. Before go-live:

• Keep keys, passwords and access rules out of the system prompt; assume a user can read it.
• Let the model act with the rights of the user who asked, never with an administrator key, and require a confirmation before it sends mail or changes records.
• Treat model output as untrusted input: encode it before display and never run it as code or SQL unchecked (LLM10, Improper Output Handling).
• Set per-user limits on requests, since Unbounded Consumption is now LLM06.

Our article on prompt injection and the OWASP Top 10 for LLMs covers each risk with examples, and our guide to MCP server security covers the tools an agent calls.

Logging and error messages

OWASP lists Security Logging and Alerting Failures as A09:2025 and Mishandling of Exceptional Conditions as A10:2025. Record sign-ins, failed sign-ins, changes of rights, exports and deletions with time and user, and keep the log where the app itself cannot overwrite it. Leave passwords, keys and full personal records out of it, and clean user input before it is logged: log injection was the weakest category in Veracode's test, at 88 per cent. Error pages show the user a short message and keep the technical details in the log. Logs with personal data fall under the GDPR, and your data-protection officer confirms how long they are kept.

Checking with tools that keep the code in-house

Secrets, packages and risky code patterns have free tools that run on your own hardware; sign-in, access rights and database rules still need the manual tests described above.

GitHub READMEs of Gitleaks, Betterleaks, OSV-Scanner, Semgrep and ZAP, Hugging Face card of Qwen3.8-27B, read 30 October 2026; Ollama minimum version from our coding-assistant guide (CVE-2026-103663).

Semgrep states that it "analyzes code locally on your computer or in your build environment: by default, code is never uploaded." For Ollama, the setting OLLAMA_NO_CLOUD=1 described in its FAQ removes the cloud models and web search, so the review model cannot send code out by mistake.

A language model adds a reviewer that reads the app at once, as far as its context allows. It should run locally, because the code under review holds the database schema, the configuration and, before the clean-up, possibly the very keys you are looking for. Dyad's built-in security review also uses AI; its documentation calls the feature experimental, says it "may not catch all relevant security issues" and recommends using it together with other security products. For apps kept in GitLab or GitHub, the open-source PR-Agent can add a security section to every merge request review, as our guide to self-hosted AI code review describes. Its documentation, in a passage dated January 2025, calls local models suitable for "experimentation and learning purposes" and "not suitable for production-level code analysis tasks". We found no published measurement of how many real security issues local models find, so a person confirms each finding.

You can order the workstation alone, the setup of Ollama, the review model, Gitleaks and OSV-Scanner alone, or both together: the workstation delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

Hardware for a local review model

A security review reads a lot of code at once, so the model needs a long context: Ollama's documentation says coding tools should be set to at least 64,000 tokens. Memory decides the configuration. We size it with our users-per-card rule: 90 per cent of the memory the driver reports, less 3 GiB per card, must hold the model plus a cache for every review that runs at the same moment. We count that cache in 16-bit, Ollama's default; for Qwen3.8-27B it is about 8.1 GiB per 128K-token session, as our guide to vibe coding workstations calculates.

Our estimates by the users-per-card rule with usable memory of 25.7, 61.5 and 83.0 GiB per card, Ollama's 4-bit (18 GB), 8-bit (30 GB) and 16-bit (56 GB) files and a 16-bit cache, as on ollama.com on 30 October 2026; not measurements.

On the entry tier the 4-bit model (16.8 GiB) leaves 8.9 GiB, enough for one review of 128K tokens. Ollama answers one request per model at a time until OLLAMA_NUM_PARALLEL is raised, and each parallel slot reserves the full context, so the setup sets both for the reviews in the table. One RTX PRO 6000 Workstation Edition or Max-Q also holds Qwen's FP8 checkpoint in vLLM with six reviews of 128K, or 13 with an FP8 cache. When a development team wants a review on every merge request and coding agents on the same hardware, the model moves to a rack server, as our guide to a server for coding agents sizes. The scanners need no GPU; they run on the processor of the same machine.

For speed, StorageReview's review of 14 October 2026 gives a reference: Qwen3.8-27B in NVIDIA's NVFP4 format, served with vLLM 0.27.1, wrote between 17 and 22 tokens per second for a single request on every card that ran it, from the RTX PRO 4500 Blackwell Server Edition and an L40S to an RTX PRO 6000 Blackwell Workstation Edition. At that rate a review report of 2,000 tokens takes about one and a half to two minutes by our arithmetic. Reading a large code base before the answer adds time that depends on its length and the card; we found no published figure for this task.

By our estimate (the card, a 350 W processor and 15 per cent for the rest), a workstation with one RTX PRO 4500 draws about 0.6 kW at full load, one RTX PRO 5000 about 0.75 kW and one RTX PRO 6000 Workstation Edition about 1.1 kW, each on an ordinary 230 V circuit. A server with two RTX PRO 6000 Server Edition cards draws about 1.8 kW and belongs in a server room.

A go-live rule for AI-built apps

Someone has to own the decision. A short rule in the company's AI usage policy can sort apps by who uses them and what they hold.

Our recommendation.

Code written with AI also raises questions of licences and ownership, which our article on an AI coding assistant policy covers, and our list of security questions for management helps when the review model itself runs on a company server.

Send us the number of people who build apps and the tools they use, and we propose the workstation for the review.

FAQ