Skip to content

Secure vibe coding: a review checklist

To secure a vibe-coded app, work through one checklist of seven areas: access, data rules, secrets, dependencies, input handling, logging and AI features. A non-developer builder can do the first column, a technical reviewer checks the second, and the third says how each item is checked when there's no build pipeline. Most real exposures come from configuration, not clever attacks, so the checklist starts there.

Who this is for

Builders who want to know their app is safe to share, technical reviewers doing the Important-tier technical check, and security leads deciding what to automate. You get one checklist in seven sections, with fixed links other pages use. Reading time: about 15 minutes; the tables are for reference.

Jump to: access · data rules · secrets · dependencies · input handling · logging · AI features

Why do AI-built apps need a security checklist?

AI tools write code that works and looks finished, and they confidently choose insecure defaults. In a 2025 vendor benchmark of more than 100 models, the generated code introduced a security flaw in 45% of tasks that offered a secure and an insecure choice, and newer or larger models did no better1. See what the studies of AI-generated code actually show. In a controlled study, people using an AI assistant wrote less secure code and were more confident it was secure2. So a builder's feeling that "it looks fine" isn't evidence. The fix is checks that a machine or a second person runs, at a depth set by the app's risk.

The UK National Cyber Security Centre made the same point in June 2026: a prototype on no sensitive data needs light checks, while anything with sign-in, personal data or secrets needs much more3. Here, that calibration is the risk tier. This page lists what to check. Which checks are required at each tier, and when, is set only in the gate matrix; the verify step says how deep a review goes.

How to use this checklist

  • Builder: work through the first column of every section before you share the app. Most items take a minute. In the third column, items marked "(reviewer)" are the technical reviewer's; the rest are yours.
  • Technical reviewer: at Important and above, check the second column as part of the 30–45 minute technical check, plus the automated exposure scan and the data-rule negative tests.
  • No pipeline? That's the default for most worker-built apps. The third column says how to check each item by hand or with the platform's own tools.
  • Not relevant? Mark an item N/A with a one-line reason (for example, "no database"). A blank isn't an N/A.
  • Record it under Tests and checks in the one-page app record, or keep the filled-in spreadsheet with it. The reviewer's check goes in technical_check_on.
  • How deep? The tier sets the depth: Sandbox and Team apps use the builder's column as a self-check; Important and Critical apps add the technical reviewer's column and, for Critical, a security review, as set in the gate matrix.

Download the checklist as a spreadsheet: security-checklist.csv. It has one row per item, with the builder's check, the reviewer's check, how to check it with no pipeline, and columns for the result and notes. Prompt to Prototype, Secure vibe coding: a review checklist, https://prompt-to-prototype.com/security/, as of October 2026. Licensed CC BY-SA 4.0. Using or adapting it inside your business isn't distribution under the licence.

A failed item is a finding, not a failure of the builder. Fix it, re-check it, and record it.

Access: who can reach the app?

Who can reach the app, and what can each person do once they're in?

Builder can check Technical reviewer checks How it's checked with no pipeline
The app needs company sign-in (single sign-on) to open. Nothing is reachable from the internet without it, unless the app is approved at Important or Critical on a public-facing pattern (Floor 2) Sign-in is enforced on every page and every API route, not just the home page Open inner pages and API addresses in a private browser window, signed out
The app is built and hosted on a business account, not a personal one (never-do 3) The owning account belongs to the business and has a second admin Check the workspace or project owner in the platform's settings
Roles exist and the lowest role can't open admin pages Every action checks the role on the server side, not only by hiding buttons Sign in as a low-role test account and type an admin page's address directly
Share links aren't set to "anyone with the link" No public share links, guest profiles or anonymous access remain Review sharing settings and guest or anonymous profiles in the platform

Data rules: who can read and change each record?

Can anyone read or change data they shouldn't? This is where most documented exposures happened. Details and test commands are on stop vibe-coded apps exposing data.

Builder can check Technical reviewer checks How it's checked with no pipeline
Row-level security (or the platform's equivalent) is on for every table before any data goes in Rules are deny-by-default: no rule that allows "everyone" or "any signed-in user" to read all rows Read the rules in the platform's console; run the platform's security advisor if it has one
A second test account can't see the first account's records (a negative test) Negative tests cover every table and storage bucket, including ones the screens don't use, and inserts, updates and deletes as well as reads Two test accounts, plus a direct request with only the public key against a table holding a test row (the test on the exposed-data page)
Storage buckets and file folders are private No publicly readable bucket, folder or database exists (reviewer) External exposure scan before launch and on a schedule: read-only requests against production; anything that writes only against a test copy you're authorized to test
The app holds only the data it needs The data class matches the tier, and Confidential or Restricted data has data-owner sign-off Compare the fields stored with the app record's data entry

Don't: trust the platform's defaults (AP1: public-by-default data; AP3: \"the vendor secured it\")

Power Apps portals exposed about 38 million records in 2021 because table permissions were off by default, and the vendor first called it "by design"4. A CVE filed in 2025 against an AI app builder's generated projects, which the vendor disputes, describes missing row-level security that let unauthenticated users read and write tables5. Check the rules yourself; the default isn't a control.

Secrets: where do keys and passwords live?

Are keys, passwords and tokens kept out of the code, the front end and the prompts (AP11)? In February 2026 a vibe-coded app shipped its database key in front-end JavaScript with no row-level security, and 1.5 million API tokens were exposed6. The site's full guidance, including where secrets leak and what to do when one does, is in secrets.

Builder can check Technical reviewer checks How it's checked with no pipeline
No key, password or token in the code, the front end or any prompt (never-do 2) No secret in client-side code or the repository history Search all the app's files for common key formats, including backend service-role keys (the key search, step 4); (reviewer) run gitleaks or TruffleHog over the exported code
Secrets are held server-side, in the platform secret store or a secrets manager. For standard downgrade 3, the platform store must meet the conditions listed there Each secret is scoped to the least it needs, owned by the app (not a person), and recorded in the app record (secrets_location) Review the credential list in the app record against the platform's settings
You know how to rotate each key Rotation has been tested at least once (reviewer) Rotate one key in a test environment and confirm the app still works

Dependencies: are the packages real and safe?

Are the packages the AI added real, current and safe? AI models sometimes suggest packages that don't exist. In a 2025 study of 16 models, at least 5.2% of suggested packages from commercial models, and 21.7% from open-source models, were hallucinated7. Attackers can publish malware under those invented names (slopsquatting). A researcher who registered one such name, empty, saw more than 30,000 downloads in three months8.

Builder can check Technical reviewer checks How it's checked with no pipeline
Every package the AI added exists, has a real project page, and wasn't created in the last few weeks No hallucinated, typo-squatted or abandoned package; versions are pinned in a lockfile Look each one up on the package registry's website, or run npm view PACKAGE_NAME time.created or pip index versions PACKAGE_NAME
You didn't install anything just because the AI suggested it No known vulnerabilities above the agreed severity (reviewer) Run a dependency scanner by hand: npm audit, pip-audit or OSV-Scanner
The platform's own components are on a supported version Builder-tool extensions and plugins come from the approved list, at pinned versions Compare installed extensions with the approved-tools list

Don't: install whatever the model suggests (AP9)

Hallucinated package names are common and predictable, so attackers register them7 8. Check that a package exists and is reputable before installing it, or install only through a registry proxy that allows approved packages.

Input handling: what happens to what users type?

Can someone type something into the app that makes it do something you didn't intend? In plain words, an injection attack is when text a user (or a document, email or web page) supplies is treated as an instruction instead of as data. A search box whose text ends up inside a database query can be made to return every row. A comment field that gets shown to other users can carry a script that runs in their browsers. For AI features, the same idea is prompt injection: text the AI reads carries instructions it then follows.

Builder can check Technical reviewer checks How it's checked with no pipeline
Using a test record, or a test copy of the app, type unusual input into every field: a single quote ', the text <script>alert(1)</script>, a very long string, an empty value. The app should reject it or show it as plain text, never break or pop up a box. Delete the test record afterwards Queries use parameters (never text pasted into the query); output is escaped; file uploads are type- and size-checked (reviewer) Run a free static scanner over the exported code (for example Semgrep or CodeQL), plus the manual input test
Forms ask only for what the app needs Server-side validation exists; checks in the browser alone don't count (reviewer) Send a request that skips the form and confirm the server rejects bad input
Links and redirects go only where you expect No open redirects; the app doesn't fetch arbitrary URLs a user supplies Manual test with a URL pointing elsewhere

Logging: can you see what happened?

If something goes wrong, can you find out what happened, without the logs becoming a leak themselves?

Builder can check Technical reviewer checks How it's checked with no pipeline
The app records sign-ins, admin actions, exports and deletions Logs record who, what, when and from where, are kept for the agreed period, and can't be edited by the app's users Perform each action with a test account, then find it in the platform's audit log
Logs don't contain passwords, tokens or full personal records No secrets, full card numbers or full request bodies in logs or error messages Search a day's logs for password, token and Bearer
You know where the logs are and who reads them Someone is named to look at alerts, and the logs reach whoever handles incidents Check the app record names the log location and the reader

AI features: what can the model be tricked into doing?

Does the app call an AI model at runtime, or act as an agent? If so, it has extra risks, and the AI modifiers apply. The full guidance is on AI feature security and in the MCP and agent security baseline; the checks here are the minimum.

Builder can check Technical reviewer checks How it's checked with no pipeline
The AI service is approved for the data class it receives (the M1 approval gate) The provider's data terms match the data sent Compare the service with the approved-tools list
The feature doesn't combine private data, untrusted content and a way to send data out (the trifecta rule) At least one leg is removed by design, not by instructions in the prompt Do the two-minute trifecta check and record the result
No secrets or confidential rules are hidden in the prompt Consequential actions need a person's approval; tool permissions are the narrowest that work Read the prompt and the tool grants
No AI agent or automation holds write access to live systems without a sandbox run first, a scoped credential and a restore you've tested; no permission-bypass modes (never-dos 4 and 5) The agent's identity, grants and tokens are in the app record, scoped to what it needs, and none is a person's own login Read the agent's grants in the platform or identity provider; see safe permissions for AI coding agents
Every MCP server or connector the app or agent uses is on the approved list, at a pinned version Each server has its own credential and narrowest scopes, no token passthrough, and the trifecta check is recorded Compare the tool's MCP and connector settings with the approved list (finding shadow MCP servers)
From Team up, an eval set with a pass threshold exists Evals pass before launch and after any model or prompt change See evaluate an AI feature

How the sections map to the root causes

The documented failures come down to six root causes (see failure patterns). Each section closes at least one.

Root cause Sections that close it
Public-by-default configuration Access, data rules
Keys in the client Secrets, data rules
Standing permissions for apps and agents Access, secrets, AI features (the agent and MCP rows)
No test Data rules (negative tests), input handling
No review All sections, via the technical check
No owner Logging (who reads the logs); the app record and app registry

Automated scans

Automate what you can, because human review alone doesn't catch AI-generated flaws2.

Depends on your circumstances (C6)

If you already run a platform team or build pipelines, run secret, static-analysis and dependency scans on every change and block merges on high-severity findings, as set out in guardrails, C6. Put security requirements into the coding assistant's standing instructions too, as the OpenSSF guide recommends9.

Without a pipeline (the default): turn on every security check the platform has built in, and run the manual checks in the third columns. The exposure scan is part of the technical check from Important (gate matrix). IT (or the technical reviewer it delegates to) also repeats it on a schedule, monthly by default, for every app at Important and above, and records last_exposure_scan_on and its result. Including Team apps is good practice where IT can: it's the only check that catches a Team app's Floor 2 breach after launch.

How does this map to the OWASP Citizen Development Top 10?

OWASP's Citizen Development Top 10 covers low-code and no-code platforms, AI-assisted coding and AI agents. It succeeds the earlier Low-Code/No-Code Top 10. As of October 2026 its owasp.org project page is unreliable and states no version or date, so the item list below was read from the project's source repository10.

The ten OWASP items and the sections that cover them
OWASP item Section here
CD-SEC-01 Blind Trust All sections; why this checklist exists
CD-SEC-02 Account Impersonation Access, secrets
CD-SEC-03 Authorization Misuse Access, data rules
CD-SEC-04 Sensitive Data Leakage and Handling Failures Data rules, logging, AI features
CD-SEC-05 Authentication and Secure Communication Failures Access
CD-SEC-06 Vulnerable and Untrusted Components Dependencies
CD-SEC-07 Security Misconfiguration Data rules, access
CD-SEC-08 Injection Handling Failures Input handling, AI features
CD-SEC-09 Asset Management Failures The app registry and retirement
CD-SEC-10 Security Logging and Monitoring Failures Logging

What should you do if you find something?

  • Data is exposed, or a secret is public: save the logs, contain it (close public access, revoke the key), then follow if your data was exposed and incident response. If it broke Floor 2 by mistake, the floor-breach rule applies.
  • Anything else: fix it before you share or release, re-run the check, and record it in the app record. If you can't fix it, ask your champion or technical reviewer; don't ship around it.

Assumptions and evidence

  • A-015 (Medium): we expect most exposures of worker-built apps to come from configuration, so a checklist that starts with access and data rules catches most of them; test this by recording which section each finding falls under for two quarters.

Evidence: controlled studies and vendor benchmarks of AI-generated code, government security guidance, OWASP community lists, and incident reports; no controlled study of checklists used by non-developer builders. Facts on this page are as of October 2026.

  1. Veracode, "2025 GenAI Code Security Report", Jul 2025 (October 2025 update). https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/ [vendor], accessed 2026-10-21. ↩

  2. Perry, Srivastava, Kumar and Boneh, "Do Users Write More Insecure Code with AI Assistants?", ACM CCS 2023 (a durable finding; the tools studied are older). https://arxiv.org/abs/2211.03622 [research], accessed 2026-10-21. ↩↩

  3. UK National Cyber Security Centre, blog post on the "vibe coding spectrum" approach to AI-assisted software development, 18 Jun 2026. https://www.ncsc.gov.uk/blogs/the-vibe-coding-spectrum-approach-to-ai-assisted-software-development [regulator], accessed 2026-10-21. ↩

  4. UpGuard, research on Power Apps portals exposing about 38 million records, 23 Aug 2021. https://upguard.com/breaches/power-apps [vendor], accessed 2026-10-21. ↩

  5. Tenable, CVE-2025-48757 record (published 30 May 2025; the vendor disputes it). https://www.tenable.com/cve/CVE-2025-48757 [primary], accessed 2026-10-21. ↩

  6. Wiz Research, "Exposed Moltbook database reveals millions of API keys", 2 Feb 2026. https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys [vendor], accessed 2026-10-21. ↩

  7. Spracklen et al., "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs", USENIX Security 2025. https://arxiv.org/abs/2406.10279 [research], accessed 2026-10-21. ↩↩

  8. Lasso Security, research on AI package hallucinations, Mar 2024. https://www.lasso.security/blog/ai-package-hallucinations [vendor], accessed 2026-10-21. ↩↩

  9. OpenSSF, "Security-Focused Guide for AI Code Assistant Instructions", 1 Aug 2025. https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions [primary], accessed 2026-10-21. ↩

  10. OWASP, "Citizen Development Top 10" project, source repository (no version or date stated; the item list is read from here). https://github.com/OWASP/www-project-citizen-development-top10-security-risks [primary], accessed 2026-10-21. The owasp.org project page, https://owasp.org/www-project-citizen-development-top10-security-risks/, redirected to a "not found" page when checked on 2026-10-21. ↩