A working screen is a poor security test. An app can sign a user in and show the right dashboard while still trusting a hidden button to protect another customer's records. It can also ship a private credential in browser code or leave an expensive API route open to repeated requests.
The build method alone does not tell you whether those faults exist. In Veracode's 2025 test of AI generated code, models introduced a known security flaw in 45% of the tested generation tasks. That is a result from defined tasks, not a claim that 45% of AI built apps are vulnerable. A 2022 Stanford study by Perry and colleagues, "Do Users Write More Insecure Code with AI Assistants?", found its participants wrote less secure solutions to the study's tasks and were more likely to believe their code was secure. Neither study measures your app. Both give you a reason to verify the result instead of trusting the demo.
A key in browser code may or may not be a secret
Anything delivered to a visitor's browser can be read by that visitor. OWASP's web security testing guide includes JavaScript, page content and public source maps in information leakage checks. That makes browser files a useful place to look for credentials and internal details.
The word key is not enough to call a finding. Supabase's API key guidance allows its publishable key in a browser. Its elevated secret key belongs in a controlled backend because it bypasses row level security. A reviewer needs to identify the key type, its privileges and whether it is live before describing the risk.
If a private credential is exposed, remove it from public files and revoke or rotate it with the provider. GitHub's remediation guidance says deleting the text from the codebase is not enough. Secret scanning and push protection can help catch leaks, but they do not replace a check of the shipped browser assets and repository.
A hidden button does not enforce permission
The customer interface can hide an admin action while the server still accepts the request. Access to a record or function must be checked when the request reaches the trusted service. OWASP's authorisation guidance recommends denying by default and validating permission on every request.
Test with two authorised customer accounts that hold different invented records. Try reading, changing, deleting and exporting the other account's data through the app's normal requests. Test a regular account against administrator functions too. Do this in an agreed test environment, without experimenting on live customer data. OWASP's authorisation testing guide describes the same horizontal and vertical checks.
If your backend uses Supabase, ask which row level security policies apply to each table that holds private data, and test the result with both accounts. A policy's existence is not proof that it denies the wrong user.
Public endpoints need limits
An open upload, generation or search endpoint may consume storage, compute or a paid third party API on every call. OWASP's API resource consumption guidance recommends limits on request frequency, payload size and expensive operations, plus spending limits or billing alerts where available.
Check the actual endpoint and its costs. Which user can call it? How large can the input be? What happens after repeated requests? The right limits depend on the work it performs. A single rate limit copied across every route can block customers without controlling the expensive action.
Prompts are instructions, not verification
Tell the coding assistant that private credentials belong on the server and that permissions must be enforced there. Then inspect the implementation and test the behaviour. Prompt wording cannot establish that the app did what you asked, especially after later edits.
Before customers rely on the app, record which public files, customer roles and costly routes were checked, what the result was and what remains unknown. For a fuller release gate, use our AI built app security checklist before launch.
If your app has a working public URL, request a free public app review. A VibeZero engineer checks the unauthenticated public surface and emails a PDF within 24 calendar hours of receiving that URL. The free review does not inspect code, sign in or verify customer account separation. If those are the questions you need answered, agree a separate paid vibe code audit with the access and scope required.