Abstract

Applications developed with vibe coding platforms are significantly lowering the barrier to entry for software creation. Tools like Lovable allow users to build complete applications, including frontend, backend, and database, without requiring deep programming knowledge.

However, this abstraction also shifts critical security responsibilities to configurations that are often overlooked by developers. In applications using Supabase as a backend, incorrect permissions in access policies can allow sensitive data to be accessed directly by unauthenticated users.

This article introduces Chupabase, a tool developed to automatically identify and exploit these insecure configurations in applications generated with Lovable. The tool analyzes the application’s JavaScript bundles, reconstructs the API endpoints, and checks which resources can be accessed by the public role.

Introduction

In recent years, artificial intelligence-based development platforms have been transforming how applications are created. Tools like Lovable [1] allow users to describe functionalities in natural language and obtain complete applications in a few minutes. This model, often called vibe coding, prioritizes speed and experimentation, significantly reducing the effort required to build new digital products.

The rapid adoption of these tools reflects this potential. Just months after its creation, Lovable achieved a market value of over a billion dollars [2], boosting the platform’s use in various organizational contexts.

However, the same ease that accelerates development can also introduce relevant security risks. In many cases, users without experience in software engineering or security end up publishing complete applications without fully understanding how authentication and authorization mechanisms are configured. When these controls are defined inadequately, or simply omitted, the application can expose data directly through public APIs.

By default, these applications use Supabase as their backend infrastructure. In this model, the database is exposed through automatic APIs, and access control depends on policies configured directly in the database. When these policies are poorly defined, the backend ceases to be just an internal component of the application and becomes a direct access point for attackers.

Interestingly, this scenario recalls a phenomenon known in Latin American folklore: the myth of the Chupacabra [3]. For decades, reports about the creature that would attack livestock in the interior of the Americas spread fear among animal breeders. Regardless of the veracity of these stories, the simple fear of the chupacabra’s presence led many producers to reinforce fences, protect their animals, and better guard their herds.

In the context of modern applications, something similar should happen. The risk of exploitation by malicious agents should encourage developers to better monitor their systems, review permissions, and adequately protect their data.

This article explores how applications generated with Lovable can inadvertently expose their backends when these protections are not configured correctly. Furthermore, it introduces the Chupabase tool, designed to quickly identify these exposures and demonstrate the impact of insecure configurations, functioning, as a “chupacabra” capable of draining data from poorly protected applications.

AnonKey and RLS Policies

Applications developed in Lovable use Supabase as a Backend-as-a-Service (BaaS) [4], which in turn provides a PostgreSQL database with real-time REST APIs connected directly to the database. This tool exposes its database via PostgREST, using an anonymous key called anonKey to allow interaction with the application through public access or unauthenticated users. The anonKey is not a security secret but a role identifier (the “anon” role), and its exposure alone is not considered a vulnerability. The problem occurs when this role has excessive permissions, turning it into an open invitation for the data chupacabra. The (default) exposure of the anonKey and the backend URL in a Lovable application can be seen in Figure 1.

Row-Level Security (RLS) [5] is a Supabase feature that allows defining granular policies that determine exactly which rows of a database table can be accessed or modified by a specific role (such as the “anon” or “authenticated” roles).

Below are examples of RLS policies applied to database tables to restrict or allow access:

Scenario	SQL Command (Policy)	Security Impact
Public Read	CREATE POLICY "Public Select" ON posts FOR SELECT TO anon USING (true);	Allows full read access on the posts table by any user with the anonKey.
Owner Restricted Access	CREATE POLICY "Owner Access" ON profiles FOR ALL TO authenticated USING (auth.uid() = id);	Ensures logged-in users only view/edit their own data (profiles table).
Anonymous Insert	CREATE POLICY "Public Insert" ON leads FOR INSERT TO anon WITH CHECK (true);	Allows visitors (leads table) to submit forms (e.g., Landing Pages), but without read permission.
Zero Privilege	ALTER TABLE sensitive_data ENABLE ROW LEVEL SECURITY;	Without additional policies on the sensitive_data table, all API access is denied by default.

Without active or properly configured RLS policies, a table can be completely exposed to anyone who possesses two requirements:

• PostgREST API Endpoints (application’s route map); and
• anonKey API Key.

Client-Side Route Map

By default, projects in Lovable typically use the following development stack:

• Frontend: React, Vite, Tailwind CSS, and shadcn/ui.
• Backend: NodeJS with Typescript.
• Database: Supabase with PostgreSQL.

Applications using the Vite Plugin PWA seek offline optimization and aggressive caching but often introduce a possibility of information leakage.

The sw.js file (Service Worker) acts as a route map for the application. In other words, the Service Worker ends up functioning as a treasure map of the application, and unfortunately, the treasure is sometimes the database itself. Through the precacheAndRoute command, the plugin generates a manifest of all application assets, including API endpoints. The sw.js allows bypassing file name hashing (e.g., index-D8f2k9.js), providing a direct index of the source code, as seen in Figure 2.

Even without the service worker, the main bundle (index.js) usually contains the API calls. By analyzing this file, it is possible to reconstruct the application’s endpoint map.

Reading route by route, it is possible to build a map of API calls. In possession of the map, an attacker can reach the application’s backend without needing to navigate through the screens (frontend), simply by reading what is available client-side. Just like the mythical Brazilian creature [6], a variation of Chupacabra, a map allows an adversary to reach remote places they should not have access to and frighten those who live there. The creature managed to reach Goianinha, and we reached the Supabase backend, only needing access to consume the endpoints.

The Risk of Public APIs

The attack surface of a Supabase project is not limited to tables. The misuse of the anonKey exposes three main vectors:

• REST Tables (PostgREST): If RLS is disabled or misconfigured, data extraction is direct.
• RPCs (Remote Procedure Calls): Postgres functions exposed as an API. They can be executed with elevated privileges depending on the execution mode (SECURITY DEFINER).
• Edge Functions: Server-side functions running in Deno. If there is no explicit JWT validation using supabase.auth.getUser() or an equivalent library, they become vulnerable public endpoints.

If any of these vectors are public (default configuration), it is possible to consume the endpoints directly, without needing to log into the application. With this, an attacker has the application map and the inadequate configuration to exploit without needing authentication, the equivalent, for a predator, of already smelling the herd.

Threat Modeling

To understand the attack scenario and the associated risks, a threat modeling diagram was constructed, as seen in Figure 4.

Threat Actor

The attacker considered is an unauthenticated external user, without privileged access to the application. The only requirement is the ability to access the public interface of the application or its static files distributed by the frontend.

Access to the original source code, internal credentials, or administrative access to the environment is not assumed.

Preconditions

For the exploitation scenario to be feasible, certain conditions need to be present:

• The application exposes JavaScript bundles containing references to the backend infrastructure.
• The project uses Supabase with automatically generated REST APIs.
• The application publicly provides the anonKey, which identifies the anon role.
• Authorization policies (RLS) or authentication validations are not configured correctly.

These conditions are common in applications generated by Lovable vibe coding tools, where the focus of development is on interface functionality.

Attack Surface

The attack surface considered in this study includes three main components of the Supabase architecture:

• REST APIs (PostgREST): Database tables automatically exposed via REST endpoints. If Row-Level Security policies are absent or permissive, data can be accessed directly by the anon role.
• RPCs (Remote Procedure Calls): SQL functions exposed as API endpoints. If they do not implement explicit authentication validation, they can execute sensitive logic without adequate restriction.
• Edge Functions: Server-side functions that can be invoked directly via HTTP. Without validation of the Authorization header, these functions can become public endpoints accessible by any client.

Potential Impact

Depending on the application’s configuration, an attacker can:

• enumerate internal API endpoints
• access data stored in database tables
• execute functions exposed via RPC
• extract large volumes of data without authentication
• automate exploitation using tools like Chupabase

In more severe scenarios, the absence of authorization controls can allow the complete extraction of the application’s database.

Chupabase – The Automated Exploitation Tool

To automate the ease with which a misconfigured backend can be exposed, Chupabase [7] was created, an automation tool inspired by analysis scripts for applications created by artificial intelligence in this manner. The name was inspired by the mythological creature Chupacabra (and similar) that drains the blood of animals, as the tool drains data from database tables when access control is misconfigured. Unlike the creature from Goianinha, which hinders and destroys what it sees, Chupabase was designed to assist in the detection and demonstration of the impact of poorly configured access policies.

The tool consists of a Python script that transforms a minified JavaScript bundle into structured documentation with swagger, effectively performing automated API reverse engineering.

Operating Flow

The tool operates through 6 steps:

1. Mapping: Searches for sw.js to identify precached assets (optional step, if the application has sw.js).
2. Identification: Locates the largest .js file (index), generally the application’s main bundle.
3. Secret Extraction: Automatically detects the Supabase URL and the anonKey.
4. API Reconstruction: Scans the code for .from(), .rpc() calls, and Edge Function URLs.
5. Swagger Generation: Consolidates all found endpoints into a swagger.yaml file. This allows the auditor to use tools like Swagger UI or Postman to test the API with one click.
6. Active Audit: If executed with the test flag, the script checks which endpoints respond with 200 OK under the anon role.

Usage Commands

As defined in the script’s logic, the tool operates with flexible flags:

• python run.py –url https://app.lovable.app (Complete analysis and download)
• python run.py –url https://app.lovable.app –skip-download (Audit without local persistence)
• python run.py –url https://app.lovable.app –skip-download –no-test (Documentation generation without probing)
• python run.py –url https://app.lovable.app –methods get (Specifies the HTTP method to perform the requests, for example, only GET)

Exploiting the vulnerability

During preliminary tests using the Chupabase tool, several applications were identified with tables accessible by the anon role, including user data, logs, and form records.

Figure 5 shows the execution of Chupabase on an application created and published on the Lovable platform, using the index to identify backend routes. Furthermore, it maps the API key and the Supabase URL for Swagger assembly.

With this, the tool tests the endpoints using the found API key (anonKey), which can be seen in Figure 6.

Eventually, the tests can perform data extraction that should not be public, as shown in Figure 7.

CVE-2025-48757

Researcher Matt Palmer identified this exploitation scenario through the vulnerability registered under CVE-2025-48757, initially reported in March 2025 and made public in May of the same year [8]. He exposed data from more than 170 applications generated by the Lovable platform due to the absence or misconfiguration of Row Level Security (RLS) policies. Although the problem has already been widely reported in the security community, centralized resolution is complex. As the platform’s architecture delegates access controls and database security directly to the end user, Lovable itself argues that each client assumes responsibility for protecting the data of their respective application. Therefore, since effective security needs to be implemented and validated individually in each project, it becomes extremely difficult for the platform to control and ensure that all generated applications are shielded against attacks.

Where to practice

Hacking Club [9] is a training and development platform for cybersecurity professionals. The Anomaly machine simulates a server with the vulnerability discussed in this post and can be used to reinforce the knowledge presented.

Prevention

Security should never rely on hiding public keys. It is natural for the anonKey to be public knowledge, so to protect the application from attacks like the one demonstrated in this post, permissions must be configured for the absolute minimum access. Ways to protect these endpoints involve some possible controls:

Authentication Verification within the Function (RPC)

Validate the user’s role within the SQL function code. Supabase provides auxiliary functions to identify if the user is authenticated, for example, adding auth.role() = ‘authenticated’ to ensure that only logged-in users execute the logic.

RLS

Add the TO authenticated directive to each table policy for data that should not be public. If the RPCs are defined as SECURITY INVOKER (the default), they will respect the RLS policies of the tables they access.

Revocation of Execution Permissions

By default, in Supabase, functions in the public schema can be executed by anonymous and authenticated users. This can be restricted via SQL through the command to revoke execution permission from the anon role for a specific function: REVOKE EXECUTE ON FUNCTION <function_name>() FROM anon. This ensures that the endpoint immediately returns an authorization error if the anonKey is used.

Edge Functions for Sensitive Logic

For operations that require maximum security and should not be exposed directly via database REST API, Edge Functions can be used. They are server-side functions that allow implementing personalized validations before interacting with the database, offering an extra layer of isolation. To implement, in the Supabase panel, within the SQL editor, it is possible to manage these permissions. Through the Lovable interface, it is possible to simply ask via chat (prompt): “Change the RPC function [name] so that only authenticated users can execute it,” and the tool will apply the necessary changes to the database.

Conclusion

Architectures based on Supabase and other Backend-as-a-Service models require an important change in mindset: in this type of architecture, the database ceases to be just an internal component and begins to act as the first and last line of defense of the application. When access policies are not defined correctly, the very infrastructure that should protect the data can end up exposing it directly through public APIs.

The Chupabase tool was developed precisely to demonstrate this risk in practice. By reconstructing application endpoints from the JavaScript bundle and testing access using the public role, it allows rapid validation of whether the backend is properly protected or if undue permissions are allowing unauthorized access to the data.

To reduce this attack surface, some practices are fundamental:

• Schema Protection: move critical tables to schemas outside of the public schema or drastically restrict schema usage permissions for the anon role.
• RLS Everywhere: enable Row-Level Security on all tables and use ALTER TABLE name FORCE ROW LEVEL SECURITY; to ensure policies are not ignored in API sessions.
• Principle of Least Privilege: the anonKey should have the minimum possible permissions—ideally none. Data access must be controlled by policies based on auth.uid() or auth.jwt().
• RPC and Functions Validation: never assume a function is secure just because it is hidden in the JavaScript bundle. JWT verification must occur explicitly within the function’s logic.
• Bundle Monitoring: regularly audit what the build process exposes through the Service Worker and production assets, using tools like Chupabase itself.

In Latin American folklore, stories about the Chupacabra led many breeders to reinforce fences and better guard their herds. Regardless of the creature’s existence, fear helped improve animal protection.

With modern applications, the logic should be similar. The possibility of exploitation by attackers should motivate developers to review permissions, validate authentication, and adequately protect their data.

If everything is configured correctly, Chupabase will only find 401 and 403 responses. Otherwise… the chupacabra will dine on your database.

References

[1] https://docs.lovable.dev/

[2] https://lovable.dev/pt-br/blog/company-news/200m-series-a-fundraise

[3] https://en.wikipedia.org/wiki/Chupacabra

[4] https://supabase.com/docs

[5] https://supabase.com/docs/guides/database/postgres/row-level-security

[6]https://en.wikipedia.org/wiki/Chupa-Cu

[7] https://github.com/hakaioffsec/chupabase

[8] https://nvd.nist.gov/vuln/detail/CVE-2025-48757

[9]https://app.hackingclub.com/