Some Supabase customers — a cloud database service widely used by people building AI apps — are publicly exposing user data without realizing it. The problem isn't the platform itself, but the configuration: anyone who has had an app developed using AI tools or rapid approaches (so-called vibe coding, meaning prompt-driven development without deep technical review) risks having access permissions wide open to everyone.
If your company has commissioned an app, a client portal, or an internal tool in the last two years — especially if developed quickly or with AI support — it is worth doing a check. The risk is not only technical: in the event of a personal data breach, the implications under the GDPR are immediate.
This article explains the issue, who is actually at risk, and what practical steps to take in the next few days.
The problem: open database doesn't mean broken database
Supabase is an open source platform that offers ready-to-use databases, authentication, and APIs (interfaces that let an app talk to the database). It's popular with developers because it massively speeds up app building. It's also a favorite tool for people building apps using AI as a development co-pilot.
The critical point, documented by TechCrunch , this is it: Supabase has a security system called Row Level Security (RLS) — in Italian, sicurezza a livello di riga — which must be activated and configured manually. If you don't do it, the database is accessible to anyone who has the API URL. No password is needed. No account is needed.
Apps generated with AI tools or built in a hurry often skip this step. The person who developed the app might not have been a security specialist, or followed a quick tutorial, or used an AI agent that produced working code but left it unprotected.
Who is really at risk — and who can rest easy
Not all Supabase projects are vulnerable. The risk is focused on those who fall into these cases:
- Apps or portals commissioned in the last 24 months to freelance developers or small teams, without a formal security audit
- Internal tools built quickly with AI support (ChatGPT, Cursor, Copilot) without a review by a senior developer
- MVPs (minimum viable products, meaning initial versions of an app) never subjected to a check before launch in production
- Projects where the database contains personal data of customers, employees, or users — names, emails, orders, health info
On the other hand, those with a structured development team, featuring code review processes (code review before release) and security tests, likely already have this setup under control.
Why GDPR turns a technical problem into a legal one
An open database isn't just a reputation risk. If it contains personal data of European citizens, a breach — even an accidental one — triggers GDPR obligations: notification to the supervisory authority within 72 hours, potential notification to the data subjects, and the very real risk of fines.
This issue is part of a broader picture concerning data governance in AI projects. Those who have already read our analysis on what are the risks for companies using AI APIs without structured governance you spot the pattern: the speed of adoption beats the speed of securing things, and the bill arrives later.
The same goes for those using AI tools that handle company data: we’ve already covered how to turn off human review on ChatGPT to protect company data and what OpenAI contractors actually read in the conversations . The risk surface grows every time a new tool is introduced without a review process.
Four checks to run this week
If you have an active Supabase project — or suspect you might among the projects developed for you — here are the concrete steps:
- Map your active projects. Ask your team or external vendor for a list of all Supabase apps and databases in use. Companies often have more of them than they remember.
- Check the status of Row Level Security. In the Supabase dashboard, each table shows whether RLS is on or off. If it's off on tables with personal data, that's an immediate issue.
- Check your API key permissions. Database access keys must have minimal permissions (principle of least privilege): a key used by the app's frontend shouldn't be able to read or write everything.
- Commission an external audit if you don't have in-house expertise. An hour of code review by a senior security developer costs way less than a GDPR notification.
The typical mistake — and how not to repeat it in upcoming projects
The most common mistake isn't technical: it's organizational. You commission an app, test that it works, and go live. No one explicitly asks "is this database accessible only to those who need to access it?" because it's taken for granted that whoever built the app also thought about security.
With vibe coding — AI-prompt-driven development, where code is generated automatically and validated mainly on its visible behavior — this assumption is wrong. AI produces code that works, not necessarily code that is secure.
The structural solution is to include a security checklist as an acceptance requirement for any project: no release without checking permissions, exposed APIs, and database configuration. It is not a matter of distrusting suppliers: it is a matter of process.
The issue of governance in AI projects is central to the agenda of companies adopting these tools. If you want to dive deeper into the regulatory framework and operational implications, our cluster on regulation, privacy, and AI governance gathers the latest analyses. Among these, it is also worth reading what changes for governance when AI agents operate out of control : the core issue is the same — powerful tools, still immature supervision processes.
SHM Studio supports SMEs in reviewing digital and AI-generated projects with a compliance-oriented approach. If you have doubts about a specific project, Contact us for an initial assessment.
Related articles
Discover more articles exploring similar topics, selected to offer you a more complete and stimulating perspective. Each piece of content is carefully chosen to enrich your experience.
