Which security problem is typical of vibe-coded apps?

Missing or broken access control. Broken Access Control ranks first in the OWASP Top 10, which rates web application risks in general. For apps using Supabase or other backend-as-a-service providers, disabled Row Level Security is the classic case: without RLS enabled, anyone who knows the public anon key has full read and write access to the database.

What is Row Level Security and why does it matter?

Row Level Security (RLS) is a database feature that controls per row who may read or change which data. With Supabase, RLS must be enabled for every table in the public schema. Tables created via the table editor have RLS on by default, but tables created via raw SQL do not. Without RLS the data is freely accessible through the public API.

What is slopsquatting?

Slopsquatting is a supply-chain attack that exploits AI hallucinations. Language models sometimes suggest package names that do not exist. Attackers register these names in the package registries in advance. In a USENIX Security 2025 study, around 21.7 percent of the packages recommended by open-source models did not exist. Installing AI-generated dependencies unchecked risks executing malicious code.

Is it enough to just deploy the app to Vercel or Netlify?

For a prototype, yes; for production, rarely. Running in production needs more than a deployment: enabled access control, clean secrets management, patched dependencies, TLS, rate limiting, security headers, logging and monitoring. On top come data-location and GDPR questions that US platforms often leave open.

How do you make an AI-generated app production-ready?

With a structured review before go-live: audit access control, remove secrets from the frontend and repository, enforce RLS and server-side validation, check dependencies for known vulnerabilities, harden the deployment and establish ongoing patch and CVE monitoring. After that, operations are secured with monitoring and updates.

Is a deployment in an EU cloud GDPR-compliant?

An EU data location is a prerequisite, not a free pass. What also matters is the data processing agreement, access control, logging and the exclusion of third-country access. An app on European infrastructure simplifies the assessment considerably compared to US platforms that fall under the CLOUD Act. This is not legal advice; consult data protection counsel for concrete questions.

Deploying AI-Generated Apps Securely to the Cloud: What Companies Must Watch

Q: Are AI-generated apps insecure?

Not inherently, but the risk is measurably higher. A 2025 Veracode study found that around 45 percent of the code produced by more than 100 language models contained security flaws from the OWASP Top 10 class. AI tools optimise for code that works, not code that is secure. A running demo is therefore not yet a production-ready system.

Timo Wevelsiep03.06.2026Updated: 12.10.2026

#VibeCoding
#AISecurity
#CloudDeployment
#AppSecurity
#Supabase
#GDPR
#OWASP
#DevSecOps

Editorial note: The information in this article was compiled to the best of our knowledge at the time of publication. Technical details, prices, versions, licensing terms, and external content may change. Please verify the information provided independently, particularly before making business-critical or security-related decisions. This article does not replace individual professional, legal, or tax advice.

Review an AI-generated app before go-live - The Production Readiness Audit covers code, data, security and the operating path and delivers a prioritised go-live list at a fixed price. View the audit from €1,490 · View implementation and operations · Book an intro call

AI tools such as Lovable, Bolt, v0, Replit or Cursor have changed software development. An idea turns into a working app within hours, often without a single line written by hand. The demo runs, login works, the database is connected. The reflex is understandable: deploy quickly and go live.

That is exactly where the problem lies. A running demo is not a production-ready system. AI models optimise for code that works, not for code that is secure. A 2025 Veracode study found that around 45 percent of the code produced by more than 100 language models contained security flaws from the OWASP Top 10 class, and that newer or larger models did not perform any better (Veracode GenAI Code Security Report). The risk is not a transitional phenomenon but structural.

This article outlines what companies must watch when they want to bring an AI-generated app to the cloud securely: from access control to secrets and the database, through to deployment hardening and GDPR.

Why AI Code Is a Security Risk
Authentication and Access Control
Secrets and API Keys
The Database: The Supabase RLS Problem
Dependencies and the Supply Chain
Hardening the Deployment
GDPR and Data Location
Before Go-Live: The Checklist
Our Approach at WZ-IT
Further Reading
Sources

Why AI Code Is a Security Risk

The core problem is not that AI writes bad code. It writes plausible code that fulfils the intended function. What it systematically underestimates are the things that do not show up in the demo: what happens when an attacker calls the API directly? What if someone manipulates the user ID in the request? What if an input is not what the form expects?

The Veracode analysis shows the pattern clearly: for some vulnerability classes such as cross-site scripting, the failure rate exceeded 80 percent. A second risk compounds it: anyone who has an app fully generated often does not understand in detail what the code does. That removes the very basis for spotting security flaws in the first place.

For companies this means an AI-generated app is an excellent starting point, but it belongs on the test bench before going into production. The following sections are the areas where most problems hide.

Authentication and Access Control

In the OWASP Top 10:2025, Broken Access Control still ranks first. The list rates web application risks in general, not AI-generated apps specifically. In AI-generated apps, the problem shows up in typical patterns:

The interface hides a button, but the underlying API does not check the permission. Whoever calls the API endpoint directly gets through anyway.
A user can retrieve other users' data by changing an ID in the request.
Admin functions are not secured server-side but merely hidden in the frontend.

The rule: access control always belongs on the server, never only in the frontend. Every endpoint must check whether the authenticated user is allowed to perform the requested action. AI-generated code often implements this only halfway, because the demo works without a complete check.

Secrets and API Keys

The second classic is credentials in the wrong place. AI tools like to put API keys, database passwords or tokens wherever they are needed at the moment, and that is frequently the frontend code or a config file that ends up in the repository.

Anything that reaches the browser is public. An API key in the frontend bundle can be read out with developer tools. A secret committed to the Git history stays there, even if the next version removes it. The principles:

Secrets belong in server-side environment variables, never in the frontend and never in the repository.
Separate public and secret keys clearly. With services like Supabase the anon key is deliberately public, while the service-role key is strictly secret.
Accidentally exposed keys get rotated, not just deleted.

The Database: The Supabase RLS Problem

Many AI-generated apps use Supabase or a similar backend-as-a-service provider, because it lets you wire up a database backend quickly. That is convenient, but it has a sharp edge: Row Level Security (RLS).

RLS controls per data row who may read or write what. According to the Supabase documentation, RLS must be enabled for every table in the public schema. The catch: tables created via the graphical table editor have RLS enabled by default, but tables created via raw SQL do not. And that is exactly what AI-generated code likes to do, without setting the policies.

The consequence is drastic: without RLS enabled, anyone who knows the public anon key has full read and write access to the affected tables. The anon key sits in the frontend, so it is visible to everyone. A vibe-coded app with RLS disabled is effectively an open database on the internet. Before every go-live, therefore: check RLS on all tables, write policies, test with different user roles.

As of October 2026, Supabase is changing an important default: for new projects, new tables in the public schema have no longer been exposed to the Data API automatically since 30 May 2026, and from 30 October 2026 this also applies to existing projects (Supabase: breaking change on table grants). Tables that already exist keep their current grants. Access therefore depends on two layers: grants decide whether a role such as anon can reach a table at all, RLS policies decide which rows it sees. Policies do not revoke existing grants (Supabase: Securing your API). For older projects, both layers belong in the review.

Dependencies and the Supply Chain

AI-generated code pulls in third-party packages, and that creates a new risk. Language models occasionally suggest package names that do not exist at all. Attackers exploit this by registering these hallucinated names in npm, PyPI and other registries in advance and filling them with malicious code. The pattern has a name: slopsquatting.

A study presented at USENIX Security 2025 analysed 576,000 generated code samples with around 2.23 million package references (arXiv: We Have a Package for You!) and found that around 21.7 percent of the packages recommended by open-source models did not exist, and around 5.2 percent for commercial models (study, HTML version). Particularly critical: 43 percent of the hallucinated packages recurred in all ten repeated queries, making them predictable and therefore deliberately attackable (Snyk: Slopsquatting).

In the OWASP Top 10:2025, Software Supply Chain Failures rank third as a category of their own (A03). On top comes the usual problem of outdated packages with known vulnerabilities. Both are addressed the same way: check dependencies against the official registries and against known CVEs before deployment, and establish ongoing CVE monitoring in operation that does not go stale after four weeks.

Hardening the Deployment

Even if the application code is clean, the deployment environment decides security. The most important points:

TLS everywhere. No production service runs without encryption. A reverse proxy with automatic certificates is standard.
Rate limiting. Without limits, login endpoints and expensive API calls are open to abuse and brute force.
Set CORS and security headers properly. Correct origin restrictions and headers like Content-Security-Policy prevent a whole class of attacks.
No open admin or debug endpoints. What was convenient in development must not be reachable in production.
Logging and monitoring. Without logging, no one notices that something is happening. Security Logging and Alerting Failures are their own item in the OWASP Top 10:2025 (A09).

For running an app self-hosted, Coolify offers a sovereign deployment platform that provides TLS, reverse proxy and database provisioning from a single source. How to set an app up cleanly with it is shown in our article on Coolify v4.0.0.

Cloud deployment adds a layer that purely technical checklists often omit: data protection. Many AI tools deploy to US platforms by default. As soon as personal data is processed, that becomes a concern.

A data location in the EU is the basic prerequisite, but not sufficient on its own. It also requires the data processing agreement, clean access control, logging and the exclusion of third-country access. An app on European infrastructure considerably simplifies the data protection assessment compared to US platforms that fall under the CLOUD Act. To be on the safe side, plan the deployment from the start with GDPR compliance and data sovereignty in mind.

Before Go-Live: The Checklist

Before an AI-generated app goes live, these points should be checked. A structured, independent review surfaces exactly the gaps that get missed when building in-house (source):

Access control checked server-side for every endpoint.
Secrets removed from frontend and repository, exposed keys rotated.
Row Level Security enabled on all database tables and tested with multiple roles.
Inputs validated server-side, not just in the form.
Dependencies checked against known CVEs and for existing package names.
Deployment hardened: TLS, rate limiting, CORS, security headers, no open admin endpoints.
Logging and monitoring active, CVE monitoring set up for ongoing operations.
Data location and GDPR clarified.

Our Approach at WZ-IT

An AI-generated app is a good starting point, but the path from demo to a robust production system is handwork. Here is how we proceed:

Audit. We check the app against the points above: access control, secrets, RLS, validation, dependencies and deployment. The result is a concrete, prioritised list.
Hardening. We close the gaps found, separate secrets cleanly, enforce RLS and server-side validation, update dependencies and harden the environment.
Sovereign deployment. We bring the app onto European infrastructure, with TLS, reverse proxy, backups and monitoring. Whether self-hosted on Coolify or in a managed setup.
Managed operations. Updates, patch management and CVE monitoring in ongoing operation, so the app is still secure six months from now.

We bundle the entire path from vibe-coded app to production in our prototype-to-production support, complemented by AI software development for everything beyond that.