Seven security gaps decide whether a vibe-coded app is ready for real users, and none of them shows up while you click through your own account. Before you invite customers, check how your product handles access, sensitive data and unexpected requests.
This guide explains seven vibe coding security risks, the checks you can discuss with your builder, and how to decide which findings need attention before launch. The wider route from prototype to launch is covered in ai-generated code in production.
TL;DR
Before launching a vibe-coded app, verify the controls that protect customer accounts, data and connected services in the deployed environment.
- Check server-side login and permission checks, including separation between customer records and database access rules.
- Protect privileged keys, validate incoming data, prevent unsafe use of that data and review third-party packages.
- Verify security logging, protection against abusive requests and safe handling of errors.
- Postpone launch when testing confirms a weakness that exposes sensitive information, enables unauthorised actions or creates another unacceptable security risk.
Use test accounts and synthetic data for initial checks. Have a qualified engineer investigate warning signs and verify the relevant controls before release.
Why security gaps can survive a demo
Asking an AI tool to build an invoice dashboard may give you a working screen. You still need to define which invoices each customer can access, what happens when their login session expires, and which actions only an administrator can take. Developers need to build these rules into the app and test that it blocks requests users are not allowed to make.
A demo with one account gives little evidence that one customer cannot access another customer’s invoices. Hiding an admin button also does not prove that the action is protected. A regular user could bypass the screen and request the same action directly from the server. Tests need to check that the server rejects that request, alongside checking that customers can complete the actions they are allowed to take.
The generated code also needs review. Fu and colleagues examined 733 AI-generated code snippets from GitHub projects. They found security weaknesses in 29.5% of the Python snippets and 24.2% of the JavaScript snippets. These figures describe weaknesses in the snippets studied.
Seven vibe coding security risks to check
The risks below concern the application and its deployment, whether AI wrote some or most of the code. Run initial checks only in systems you own or are authorised to assess, using test accounts and synthetic data. Record unexpected results so your engineer can reproduce and investigate them.
Access to records belonging to another user
A signed-in customer should only retrieve or change records their permissions allow. The common failure is an insecure direct object reference (IDOR): the app accepts a record ID without checking who owns it. Broken access control in AI-built apps explains the pattern in depth; the two checks below show whether your app has it.
Initial check: Create separate test accounts with different records. Where the app uses record links, try opening a record from account A while signed in as account B. Record any unexpected disclosure.
Technical verification: Test permissions on the underlying requests, including updates and exports. A rejected page load alone does not establish that every operation is protected.
Session and role checks enforced only in the browser
A redirect to the login page controls what the visitor sees. The server must also validate the session and the permissions required for each protected request. Otherwise, someone may reach data or perform an action without using the intended screen.
Initial check: Open a protected page while signed out, then try an administrator page with an ordinary test account. Investigate any protected information that appears.
Technical verification: Request the protected data or action directly with no valid session and with insufficient permissions. Confirm that the server refuses both cases.
Privileged keys exposed to visitors
A secret key may authorise spending, access to data or administrative actions. Including it in files sent to the browser makes it available to visitors. Some providers also issue publishable keys intended for browser use, so the key’s purpose and permissions matter.
Initial check: Ask for a secrets scan of the repository and the files delivered to the browser. Have your builder identify which visible keys are publishable and which require confidentiality.
Technical verification: Check each key against the provider’s documentation and actual permissions. Revoke or rotate exposed secrets, secure their replacements and investigate possible misuse.
Database permissions that allow too much access
Hosted backends may expose data through APIs used by the browser. Their permissions must still limit what each user can read and change. An overly broad role or policy can make sensitive records accessible beyond the intended audience.
Initial check: Ask which data is available to anonymous and signed-in users, and request evidence that the permissions were tested with separate accounts.
Technical verification: Review grants and, where used, row-level policies together. Test the actual roles used by the app; some privileged roles can bypass row-level rules. The correct configuration depends on how requests reach the database.
Unsafe handling of user input
The server needs rules for the data it accepts, such as permitted values, lengths and formats. It also needs safeguards for how that data is used. Parameterised database queries and context-appropriate output encoding help prevent input from becoming database instructions or executable browser content.
Initial check: Try harmless values outside a field’s expected format, such as text in a numeric field. Record unexpected acceptance or errors.
Technical verification: Check server-side validation and the paths that use or display the submitted data. Confirm the relevant protections against injection and cross-site scripting. A form rejecting one invalid value is only an initial signal.
Unverified packages and vulnerable dependencies
Third-party packages run code within your development or application environment. An AI suggestion can name a nonexistent package or recommend a version with known vulnerabilities. Installing a package without checking its origin can introduce malicious or unsafe code.
Initial check: Request the dependency list, including versions, and ask how unfamiliar packages were selected and verified.
Technical verification: Confirm package identity and provenance, scan for known vulnerabilities and assess whether affected functionality is reachable in your product. Investigate suspicious packages even when a vulnerability scanner reports no findings.
Gaps in logging, rate limits and error handling
These controls serve different purposes. Security logs support detection and investigation. Request limits help contain automated abuse. Safe error handling prevents failures from revealing sensitive details or bypassing controls. Each needs its own check.
Initial check: Ask your team to demonstrate three things: a relevant security event appearing in the logs, a controlled test of login or API throttling, and a failed operation returning a safe response.
Technical verification: Confirm useful events and alerts, test abuse protections and inspect failure paths. Keep credentials and unnecessary personal data out of logs, and restrict access to the logs themselves.
| Recognised one or more of these in your own product? A self-check shows a warning sign, not a confirmed vulnerability or how deep it goes. An AI-built product review checks access control, secrets and data handling in your actual codebase and tells you, in plain English, which findings block launch and which can wait. → Book an AI-built product review |
Which risks block launch and which can wait
Not every finding carries the same release impact. Block launch when testing confirms unauthorised access to sensitive data, exposed privileged credentials, exploitable injection, compromised dependencies, or another weakness with unacceptable security or privacy impact. Prioritise the remaining findings by exploitability, exposure, data sensitivity and business impact. Timing matters because fixing access-control weaknesses after launch may also require changes to live permissions, existing customer records, and database migrations. Addressing these dependencies before customers rely on the product reduces the scope of remediation and the risk of disrupting live operations.
| Risk | When it should delay launch |
|---|---|
| 1. Access to records belonging to another user | Testing confirms that a user can retrieve or change another user’s protected records without permission. |
| 2. Session and role checks enforced only in the browser | A protected API request returns data or completes an action without a valid session or the required permissions. |
| 3. Privileged keys exposed to visitors | An active secret key is accessible to visitors and allows unauthorised access, privileged actions or chargeable use of connected services. Publishable keys intended for browser use require a separate assessment of their permissions and restrictions. |
| 4. Database permissions that allow too much access | Testing confirms that anonymous or signed-in users can read, modify or delete protected data beyond their intended permissions through the app’s actual data routes. |
| 5. Unsafe handling of user input | Testing confirms exploitable injection, cross-site scripting or another input-handling flaw with material security impact. |
| 6. Unverified packages and vulnerable dependencies | A dependency is confirmed malicious, or a known vulnerability is applicable and exploitable in the deployed product with unacceptable impact. |
| 7. Gaps in logging, rate limits and error handling | Automated abuse can cause material harm; error paths expose sensitive information or bypass controls; or missing security logs prevent detection and investigation required for the product’s risk level and obligations. |
Apply these criteria to confirmed findings in the planned deployment. Lower-impact findings may be scheduled after launch with a documented rationale, a named owner and a remediation deadline.
The threshold is simple: one confirmed launch-blocker is enough to stop release. In practice, warning signs from the self-checks should lead to an independent review before you onboard paying customers, because a review is what confirms or clears each warning sign. What such a review covers is explained in production readiness review.
What happens when a vibe-coded app leaks personal data
When a vibe-coded app leaks personal data, the GDPR treats it like any other personal data breach, because how the code was written changes nothing. Under GDPR Article 33 you notify the Autoriteit Persoonsgegevens (AP), the Dutch data protection authority, without undue delay. Where feasible, that means within 72 hours of becoming aware of the breach, unless the breach is unlikely to put people at risk. Under Article 34 you also inform the people affected when the risk to them is high. A leaked API key on its own is not always a personal data breach; leaked API keys in AI products explains how to assess it.
This is where missing logging, risk 7 above, turns into a legal problem. The notification has to describe the breach, including the categories and approximate number of people and records concerned (Article 33(3)), and Article 33(5) requires you to document every breach, including those you do not report. Without logs, nobody can say which records were read, so the report either overstates the breach or guesses.
Reporting late carries its own fine, and the Dutch regulator has used it. In a decision dated 10 December 2020 and published on 31 March 2021, the AP fined Booking.com €475,000 for reporting a personal data breach 22 days late.
Enterprise customers ask the same questions before anything goes wrong, because organisations covered by NIS2 must manage security in their supply chain under Article 21(2)(d). In practice, a Dutch enterprise prospect sends its suppliers a security questionnaire, and a vibe-coded product has to answer the same questions as any other software. If you cannot yet show logs, access rules and an incident procedure, fix that before the first questionnaire arrives.
How to reduce vibe coding security risks before launch
Start with these five checks to address common security weaknesses before launch. They provide a practical sequence, but they do not replace the risk-based assessment above. A confirmed injection vulnerability, compromised dependency, or unprotected login endpoint may also block release, depending on its exploitability and impact. The independent review determines which findings must be resolved before customer onboarding.
- Move every secret server-side, and replace any key that has ever appeared in frontend code. Moving a key does not help while the old one still works.
- Switch on database access rules and test them with two accounts, user A and user B, before any real customer signs up.
- Enforce login and permission checks on the server, for every page and every API call that returns user data.
- Remove packages nobody can explain, and ask your builder to add automated dependency scanning.
- Get an independent review before real users arrive, from someone who did not write the code.
Security-focused prompts can reduce some weaknesses in generated code, including during revision. In Bruni et al.’s tested configurations with GPT-4o and GPT-4o-mini, a security-focused prefix reduced vulnerabilities by up to 56% (arXiv 2502.06039). Prompting cannot establish that your particular app has correct permissions or secure deployment settings, so test and independently review those controls before release.
The full pre-launch list, including data handling and error handling, sits in the production readiness checklist.
How Sunbytes checks vibe-coded apps before launch
A vibe-coded app may already have access controls, protected API keys and database permissions in place. However, having these controls does not necessarily mean they work as intended. Before launch, the question is whether they have been tested against real user roles, data flows and potential security failures, rather than simply assumed to be working because the app runs as expected.
Sunbytes’ AI-built product review helps answer that question. Software engineers and security specialists assess the same codebase, examining access control, secrets, database permissions, dependencies, logging and deployment. The review identifies weaknesses, verifies how existing controls are implemented and prioritises findings by their impact on launch readiness. Each finding comes with supporting evidence and a plain-English explanation of what needs fixing before launch and what can be addressed later.
Reviews are conducted within Sunbytes’ information security management system, certified to ISO/IEC 27001:2022. Our team draws on 15+ years of software delivery experience and 300+ completed projects.
