An app can work beautifully and still expose a credential or another user’s data. Here is the research behind that concern, with the source, the test conditions, and the limits beside every number.
External research, not StackSnack scan results. These sources do not endorse StackSnack or measure our detection rate.
Different studies. A reason to verify.
of tested code-generation tasks introduced a risky vulnerability
Veracode’s 2026 report summary reports an average security pass rate of 56%. Its finding is about generated code under test, not the percentage of AI-built websites that are vulnerable.
Read it correctly: A controlled benchmark depends on its tasks, models, prompts, and security tests. It does not measure the risk of your particular app.
Read Veracode’s 2026 findings ↗The earlier 45% figure comes from the 2025 report: more than 100 models, across Java, Python, C# and JavaScript. The two figures are dated benchmark results, not live app vulnerability rates.
vulnerabilities reported across 5,600+ public apps
Escape also reported 400+ exposed secrets and 175 instances of personal-information exposure. The study examined publicly discoverable deployments associated with vibe-coding platforms.
Read it correctly: This was a one-time, Lovable-heavy sample, assembled from directories, search and community sources. Counts are findings, not counts of affected apps, breached customers, or unique people.
Read Escape’s findings and methodology ↗databases with publicly readable tables in the sampled dataset
UpGuard started with roughly 300,000 domains showing Supabase indicators. More than half of the exposed databases had schema indicators of personal information; researchers did not read every row.
Read it correctly: Databases, not people. Readable tables do not prove malicious access. This sample does not establish a failure rate for all Supabase apps or prove each app was AI-built.
Read UpGuard’s research and methodology ↗Also covered by TechCrunch on September 25, 2026.
What one missed boundary can expose.
API authentication tokens exposed in one application
Wiz reported a misconfigured Supabase backend exposing authentication tokens, 35,000 email addresses and private agent messages. Wiz says the Moltbook team secured it within hours after disclosure.
Read it correctly: Tokens are not unique people. A public Supabase publishable key is expected browser configuration; missing backend access controls made this incident possible. This is one case, not a platform-wide rate.
Read Wiz’s original disclosure ↗user records reportedly exposed in a showcased app
Researcher Taimur Khan reported an unauthenticated endpoint exposing user records in a Lovable-showcased education app. His disclosure described inverted authorization logic in database functions.
Read it correctly: One researcher-reported incident, not 18,697 separate apps or a rate for Lovable. Lovable told The Register that the project included code it did not generate and that the vulnerable database was hosted elsewhere.
Read the researcher’s original disclosure ↗Read The Register’s reporting and Lovable’s response ↗These cases illustrate why authorization needs testing. They do not establish that StackSnack would detect every flaw: our checks are bounded, and we do not perform destructive tests or audit arbitrary function logic. See what our scanner actually checks.
This concern has a research history.
These studies help explain why generated code needs review. They are historical evidence about the tools and tasks studied, not a scorecard for today’s coding assistants.
of 1,689 generated programs were vulnerable in the study
Asleep at the Keyboard? evaluated early GitHub Copilot across 89 scenarios chosen around security weaknesses. It tested generated suggestions in security-relevant situations, rather than a random sample of production applications.
Limit: Early Copilot, selected weaknesses, and historical tooling. Do not apply this percentage to current Copilot, every prompt, or an entire website.
Read the paper and its methods ↗of Python suggestions were vulnerable in the replication
The authors revisited a Python subset with newer Copilot and CodeQL versions. They reported a reduction from the subset’s 36.54% baseline to 27.25%, while still observing insecure suggestions.
Limit: A targeted Python comparison, not the full original multi-language benchmark and not an evaluation of current models. Improvement and remaining risk can both be real.
Read the replication study ↗Confidence can outpace security.
In this study’s security tasks, participants using an assistant based on codex-davinci-002 wrote less secure code overall and were more likely to believe their code was secure than participants without the assistant. It is evidence about one model and study setting, not proof that every AI-assisted workflow is less secure.
What actually deserves a closer look?
These are established application-security concerns, whether code comes from a person, an AI builder, or both. Official documentation explains why the controls matter; it does not provide a vulnerability rate for vibe-coded apps.
Who can read each record?
Supabase’s guidance combines grants, Row Level Security and access policies. It demonstrates matching the caller’s identity to a row’s owner, and warns against exposing administrative secret keys in the browser.
Our practical takeaway: Test anonymous access and the view of a second authorized test user. A working login alone does not prove that private rows are isolated.
Supabase: Row Level Security ↗ · Our Supabase check scopeDoes “signed in” grant too much?
Firebase explicitly cautions that rules allowing any authenticated user can expose an entire database. Rules should match the intended owner, role or data set when the content is private.
Our practical takeaway: Review database and storage rules against the actual access you intend. Cross-user testing in StackSnack is currently for approved Supabase backends, not Firebase.
Firebase: Avoid insecure rules ↗ · Our Firebase check scopeWhat did you publish by accident?
GitHub’s secret-scanning guidance identifies hardcoded API keys, passwords and tokens as targets for unauthorized access. Public app bundles are another place to review for privileged credentials.
Our practical takeaway: Check both your repository and the deployed public files. Public Supabase and Firebase client configuration keys are not automatically privileged secrets.
GitHub: Secret scanning ↗ · Understand exposed API keysLook beyond the generated code.
The OWASP Top 10:2025 ranks broken access control first, security misconfiguration second, and software supply chain failures third. These are broader risk categories, not an AI-specific prevalence survey.
Our practical takeaway: Review access policies, deployment settings and recognized dependency versions alongside code. A public scan cannot prove your business logic, every tenant boundary, or every dependency is safe.
OWASP Top 10:2025 ↗ · Work through the launch checklistUseful evidence needs honest boundaries.
- A code benchmark is not a breach rate. A vulnerable completion, a deployed finding, an affected app and a confirmed breach are different measurements.
- Do not average unrelated percentages. Model versions, prompts, tasks, languages and detection methods differ. Older research does not describe every tool available today.
- Vendor research is labeled. Veracode, Escape, UpGuard and Wiz sell security products. Academic papers are linked separately so you can inspect methods and limitations yourself.
- These are reasons to check, not proof of our coverage. StackSnack reports supported observations and skipped or limited work. The research does not establish our detection accuracy, certify your app, or replace a security review.
We link to original papers, first-party reports and official documentation. Sources were reviewed on . If a source changes or a claim needs correction, tell us.
See evidence from an actual scan.
Compare our controlled Supabase sample before and after an access-policy fix. Inspect what changed, what remains, and the limits of the checks.
Only test sites you own or have explicit permission to scan. Scans and full reports are free. Real reports stay private; the sample uses synthetic data. A clean scan cannot guarantee security.