Some Supabase customers (Supabase is a cloud database service widely used by people building apps with AI) are publicly exposing user data without realizing it. The problem isn't the platform itself, but its configuration: if you had an app built with AI tools or fast-track approaches (so-called vibe coding, meaning development driven by AI prompts without thorough technical review), you may have access permissions open to anyone.
If your company has commissioned an app, a customer portal or an internal tool in the past two years, especially one built quickly or with AI support, it's worth running a check. The risk isn't only technical: if personal data is breached, the GDPR implications are immediate.
This article explains the problem, who is truly exposed and the concrete steps to take in the coming days.
The problem: an open database isn't a broken database
Supabase is an open source platform that offers ready-to-use databases, authentication and APIs (interfaces that let an app communicate with the database). It's popular with developers because it speeds up app development enormously. It's also one of the favorite tools of people who build apps using AI as a development copilot.
The critical point, documented by TechCrunch, is this: Supabase has a security system called Row Level Security (RLS) that must be enabled and configured manually. If you don't, the database is accessible to anyone with the API URL. No password needed. No account needed.
Apps generated with AI tools or built in a hurry often skip this step. Whoever built the app may not have been a security specialist, may have followed a quick tutorial, or may have used an AI agent that produced working code that wasn't protected.
Who's really at risk, and who can relax
Not every Supabase project is vulnerable. The risk is concentrated in these cases:
- Apps or portals commissioned in the last 24 months from freelance developers or small teams, without a formal security audit
- Internal tools built quickly with AI support (ChatGPT, Cursor, Copilot) without review by a senior developer
- MVPs (minimum viable products, meaning early versions of an app) never checked before going live in production
- Projects where the database holds personal data of customers, employees or users: names, emails, orders, health data
If you have a structured development team with code review processes (reviewing code before release) and security testing, you probably already have this configuration under control.
Why GDPR turns a technical problem into a legal one
An open database isn't just a reputational risk. If it contains personal data of European citizens, a breach, even an unintentional one, triggers GDPR obligations: notifying the supervisory authority within 72 hours, possibly notifying the individuals affected, and a real risk of fines.
The issue is part of a broader picture around data governance in AI projects. If you've read our analysis of what companies risk when they use AI APIs without structured governance, you'll recognize the pattern: adoption moves faster than security, and the bill comes later.
The same goes for AI tools that handle company data: we've already covered how to turn off human review in ChatGPT to protect company data and what OpenAI contractors really read in conversations. The risk surface grows every time a new tool is introduced without a verification process.
Four checks to run this week
If you have an active Supabase project, or suspect there's one among the projects built for you, here are the concrete steps:
- Map your active projects. Ask your team or external vendor for a list of all the Supabase apps and databases in use. Companies often have more 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 containing personal data, you have an immediate problem.
- Check your API key permissions. Database access keys should have minimal permissions (the principle of least privilege): a key used by the app's frontend should never be able to read or write everything.
- Commission an external audit if you don't have in-house expertise. An hour of review by a senior developer who specializes in security costs far less than a GDPR notification.
The typical mistake, and how to avoid repeating it in future projects
The most common mistake isn't technical. It's organizational. You commission an app, test that it works, and go live. Nobody explicitly asks, "Is this database accessible only to the people who should have access?" because everyone assumes whoever built the app also thought about security.
With vibe coding, where development is guided by AI prompts, the code is generated automatically and validated mainly on how it visibly works, and that assumption is wrong. AI produces code that works, not necessarily code that is secure.
The structural solution is to make a security checklist an acceptance requirement for every project: no release without a check of permissions, exposed APIs and database configuration. It's not about distrusting your vendors. It's about process.
Governance in AI projects is a top priority for companies adopting these tools. If you want to dive deeper into the regulatory framework and its operational implications, our cluster on AI regulation, privacy and governance collects the latest analyses. Among them, it's also worth reading what changes for governance when AI agents operate out of control: the underlying problem is the same, powerful tools with oversight processes that are still immature.
SHM Studio supports SMEs in reviewing digital and AI-generated projects with a compliance-focused 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.
