We Scanned 1,072 Vibe Coded Apps, 98% Had Security Flaws!

65,643 URLs crawled. 1,085 confirmed. 6,185 vulnerabilities found.

Automated security study on web applications generated by vibe coding platforms (Lovable, v0, Bolt.new, Replit, Windsurf, Tempo…) using Supabase as their backend.

Overview

Exposure Rates

98% of vibe coded applications have at least one security flaw.Only 26 out of 1,072 scanned sites had zero issues detected.

‍

Critical Vulnerabilities in Detail

Data deletion without authentication

172 sites allow anyone to delete records from the database without any authentication. A simple DELETE API call using the public key is enough to wipe entire tables.

Data modification without authentication

172 sites expose PATCH endpoints allowing modification of existing records (user profiles, settings, content) with no identity verification.

Data reading without authentication

39 sites have tables fully readable by anyone who holds the public Supabase key (which is exposed in the page’s JavaScript). All user data, payments, and private messages are accessible.

Sensitive columns exposed through the REST API

34 sites expose columns containing sensitive personal data: emails, hashed passwords, authentication tokens, phone numbers. These columns are directly queryable through the Supabase API.

Data insertion without authentication

14 sites allow writing new rows to the database without authentication. It is possible to inject fake users, fake orders, and fake content.‍

High Severity Vulnerabilities

Medium and Low Severity Vulnerabilities

The single most vulnerable site has 30 flaws including 4 critical ones allowing reading, writing, modifying and deleting data without any authentication. Site names are deliberately withheld for responsible disclosure.

‍

Worst Cases (anonymized)

Publicly Exposed Database Tables

The most frequently accessible tables without authentication across all scanned sites:

Tables like admin_users, payments, rading_user_portfolio and chat_messages should never be accessible without authentication.

Informational Data Collected

How Sites Were Discovered

The discovery pipeline crawled 65,643 candidate URLs across multiple cycles. After deduplication and Supabase verification (confirming each site actually connects to a *.supabase.co backend), 1,085 unique sites were retained.

The 19 discovery sources ran 2,052 queries in total. Most candidates were duplicates or sites without an actual Supabase backend. The dedup and verification pipeline reduced 65,643 raw URLs down to 1,085 confirmed targets.

The Scanning Pipeline

Overall Architecture

The scanner operates as an autonomous multi agent system running continuously, 24/7. It combines AI orchestration, multi source passive discovery, and active scanning across 80 security rules.

Step 1: Strategy (CrewAI + MiniMax)

A CrewAI agent powered by the MiniMax language model analyzes the overall system state: how many targets are pending, what types of vulnerabilities are emerging, what priorities should be set for the next cycle. It produces a strategic report that guides the next actions.

MiniMax 2.5 (230b) is a language model running locally on a dedicated server. Every strategic decision goes through it: this is not a simple script, but a contextual analysis that adapts to the evolving results.

Step 2: Discovery (19 sources in parallel)

The system simultaneously launches 19 discovery sources, organized in four categories:

Classic discovery (8 sources)

‍Certificate Transparency via crt.sh, search engines (DuckDuckGo, Bing), Common Crawl, GitHub Code Search, Wayback Machine, DNS subdomain bruteforce, urlscan.io, AlienVault OTX.

Technical fingerprint discovery (4 sources)

‍Detection of platform specific signatures in HTML and JavaScript source code. Searches for CSS classes, meta tags, CDN URLs and identifiers unique to each builder. Every candidate is verified: the scanner loads the page and confirms the actual presence of markers before adding it to the database.

Multi platform discovery (6 sources)

‍Targeted search by platform: v0.dev, Bolt.new, Replit, Windsurf, Tempo Labs, FlutterFlow. Each adapter looks for sites from its platform that use Supabase as their backend. A generic Supabase adapter catches any site using Supabase regardless of the builder.

Creative discovery powered by MiniMax (1 source)

When classic sources stop returning new results, MiniMax takes over. The model receives a system prompt describing all known technical fingerprints for each platform (Lovable, v0, Bolt, Replit, Windsurf, Tempo, FlutterFlow), along with real time statistics from the current cycle: number of targets in the database, number already scanned, platforms covered, results from the last discovery round.

From this context, MiniMax generates 15 original search queries, each paired with its target engine (DuckDuckGo, Bing, or GitHub) and the reasoning behind why this search might uncover new targets.

Here is a real example of queries generated by MiniMax during a cycle:

Each query is executed automatically. Results are filtered to exclude documentation sites, forums, and code platforms. Every candidate domain is then loaded and verified: the scanner only adds it to the database if it actually contains a Supabase URL (*.supabase.co) in its HTML or JavaScript source code.

Because MiniMax uses a temperature of 0.7, the queries vary from one cycle to the next. The model never repeats the same searches and explores different angles on every run: forums, template directories, exposed configuration files, indexed JWT tokens, blog posts with demo links.

All 19 sources run in parallel via asyncio.gather. A complete discovery cycle takes approximately 6 minutes.

Step 3: Scanning (10 modules, 80 rules)

Each discovered site passes through 10 specialized scanners, executed sequentially:

Key Extraction Scanner

‍Downloads the site’s JavaScript and extracts Supabase keys (anon key, service role key, project URL). Analyzes Vite, Webpack, and Next.js bundles to find environment variables compiled into client code.

RLS Probe Scanner

‍Attempts to read, write, modify, and delete data via the Supabase REST API using only the public anon key. If an operation succeeds, it means Row Level Security policies are missing or misconfigured.

Deep Supabase Scanner

‍Queries the PostgREST OpenAPI schema to enumerate all accessible tables and columns. Identifies sensitive columns (email, password, token, ssn, credit_card). Tests access to Supabase Storage (public buckets, anonymous uploads).

Header Scanner

‍Checks for the presence of HTTP security headers: Content Security Policy, Strict Transport Security, X Frame Options, Permissions Policy, Referrer Policy, X Content Type Options.

Secret Scanner‍

Searches source code for exposed third party API keys: Stripe, AWS, Firebase, SendGrid, Twilio, OpenAI, and others.

Endpoint Scanner

‍Tests the accessibility of Supabase endpoints: Auth (signup, login, password reset, magic link), Storage, Functions, GraphQL. Checks whether sensitive endpoints are open without rate limiting.

CORS Scanner‍

Sends requests with malicious origins to detect CORS misconfigurations: origin reflection, wildcard with credentials, null origin acceptance.

JWT Analyzer

‍Decodes Supabase JWT tokens to check: signing algorithm, excessive lifetime, assigned role (anon vs service_role), unusual claims.

Info Disclosure Scanner

‍Searches for information leaks: accessible JavaScript source maps, debug headers, detailed error messages, exposed framework versions.

Email Extractor Scanner

‍Extracts contact email addresses from scanned sites to enable responsible disclosure of discovered vulnerabilities.

Sites are processed in batches of 100. When all pending sites are scanned, the system automatically triggers a new discovery cycle to find fresh targets.

Step 4: Deep Analysis (MiniMax)

For each critical vulnerability detected, MiniMax performs a full contextual analysis. The model receives raw data from each finding and transforms it into structured assessments.

Business impact evaluation

The model receives a prompt containing the technical details of the vulnerability: rule identifier, name, severity, target URL, description, and evidence collected by the scanner. It produces a natural language assessment of the real impact: what data is at risk, what is the risk for end users, what is the regulatory risk (GDPR, CCPA, HIPAA depending on the data type), and which exploitation scenarios are most likely.

For example, when the scanner detects that the payments table is readable without authentication on an e-commerce site, MiniMax evaluates that customer billing data is exposed, that this constitutes a potential GDPR Article 32 violation, and that the exploitation risk is high because the anon key is already public in the JavaScript.

Exposed data classification

For each table accessible without authentication, MiniMax receives the table name, column list, record count, and a sample of data keys. It then classifies the sensitivity level:

This classification enables prioritized disclosures: a site exposing credentials or medical data is treated with absolute priority.

Responsible disclosure email generation

When the Email Extractor has found contact addresses on a site with critical vulnerabilities, MiniMax drafts a complete disclosure email. The model receives the site URL and a structured summary of all vulnerabilities found (identifier, name, severity, short description). It produces a professional email containing: an introduction explaining the security research approach, an accessible technical description of each vulnerability, the potential impact for the site’s users, and concrete remediation recommendations (enable RLS policies, configure security headers, restrict CORS).

Executive summary report

At the end of each cycle, MiniMax generates an executive summary from the global statistics and the most critical sites. This summary is sent via Discord webhook to enable real time monitoring of the discovered attack surface.

Continuous Loop

The system never stops. After each complete cycle (strategy, discovery, scan, analysis), it starts over. Every 5 scan batches, an intermediate discovery round is launched to immediately integrate newly found sites. The pause between two cycles is 2 minutes.

The Fundamental Problem

Vibe coding platforms let anyone create a full stack application in minutes from natural language prompts. The generated code is functional, the design is polished, the deployment is automatic.

But security is systematically absent.

Supabase exposes a REST API by default. When a table is created, it is immediately accessible via the rest/v1 API. Without explicitly configured Row Level Security policies, anyone can read, write, modify, and delete all data.

The anon key is public by design. It is embedded in client side JavaScript, accessible to any site visitor. Supabase is designed this way: security relies entirely on RLS policies, not on key secrecy. But code generators do not configure these policies.

Vibe coders do not verify. The code is generated by an AI, it compiles, it works. Why would anyone go check the database security policies? The result: production applications with real user data, completely open.

172 sites allow data deletion without authentication. 39 sites expose their entire database for reading to anyone. Tables named payments, admin_users, chat_messages are publicly accessible.

This is not a theoretical problem. These are production applications, with real users, real data, and zero protection.

Scanner Technical Stack

Methodology

All tests are performed in a passive or semi passive manner:

1. Passive discovery: no direct interaction with targets. Sources (crt.sh, Common Crawl, Wayback, DNS) are public databases.

2. Active but non intrusive scanning: the scanner sends standard HTTP requests to public Supabase endpoints. It does not exploit any vulnerability, does not modify any data, does not attempt any injection. It simply checks whether endpoints respond to unauthenticated requests.

3. Automated analysis: MiniMax analyzes results to assess impact and draft disclosure communications.

4. No data is exfiltrated. The scanner detects the presence of vulnerabilities, it does not exploit them. Examples of exposed data are limited to metadata (table names, column names, row counts)

Is your vibe coded app exposed?

98% of vibe coded applications have at least one security vulnerability. If you've built with Lovable, v0, Replit, Windsurf, or any platform using Supabase your app is likely at risk right now. Talk to our team