You built an app with an AI or no-code tool, it works, and somewhere in the setup you saw the word "Supabase." Maybe your builder connected it for you. Maybe a tutorial told you to paste in a couple of keys. Now you've heard, vaguely, that Supabase apps can be misconfigured in a way that leaves the whole database open to anyone who knows where to look, and you'd like to know whether that's true of yours.
This is a fair thing to worry about, and it's also something you can start to understand without becoming an engineer. This post explains what Supabase is in plain terms, why so many AI-built apps rely on it, and the one access-control setting that most often decides whether a solo builder's data is locked down or exposed. It's written to help you recognize the situation and know who to ask, not to hand you exploit steps or a false sense of safety.
One note before we start: nothing here is a security guarantee, and no single check makes an app "secure." If your app handles payments, logins, or personal data, treat this as a first look and plan to verify with a professional. More on that threshold below.
What Supabase is, in one plain paragraph
Supabase is a hosted "backend" for apps. When you build something, the part the user sees (buttons, forms, pages) is the front end. Behind it, most apps need a place to store data, a way to sign people in, and a way to save uploaded files. Supabase bundles those services together so you don't have to assemble them yourself. At its core is a database, which is just an organized set of tables (think spreadsheets with rules) that hold your app's records: users, orders, posts, whatever your app is about. Supabase runs that database in the cloud, gives your app a way to read and write to it, and provides a dashboard where you can log in and see everything. If you want a broader picture of the pieces involved, we walk through where your app's data actually lives in a companion post.
Why AI and no-code tools keep choosing it
If several AI builders and tutorials nudged you toward Supabase, that's not a coincidence. A few practical reasons come up again and again:
- It does a lot in one place. Database, sign-in, file storage, and auto-generated connection points come together, so an AI tool can wire up a working app with fewer moving parts.
- It's approachable for generated code. Supabase exposes a clean, well-documented way for code to talk to the database, which makes it a comfortable target for AI code generators.
- There's a usable free tier and a friendly dashboard. A solo builder can get started without a purchase and can see their data in a browser.
- It's familiar in tutorials. The more it shows up in examples, the more AI tools reproduce it, which keeps the cycle going.
None of that is a knock on Supabase. It's a capable, widely used platform. The catch is that flexibility comes with responsibility, and the most important responsibility is deciding who is allowed to read and write each piece of data. That's where the next section comes in.
Row Level Security, explained without jargon
Supabase can be reached by your app through connection keys. One type of key is meant to be usable from the public front end, which means, in effect, that anyone using your app (and anyone who opens the browser's developer tools) can see that key and send requests to your database with it. That is by design. The key alone is not supposed to be enough to see everything.
What decides what that key can actually do is a database feature called Row Level Security, usually shortened to RLS.
Here's the plain-English version. Imagine your database table is a filing cabinet, and each row is a folder. RLS is the rule that says which folders each person is allowed to open. With RLS turned on and sensible rules written, a request might be allowed to see only the folders that belong to the person making it ("you can read your own orders, not everyone else's"). With RLS turned off, the public key can potentially open the whole cabinet, every row, for anyone who asks.
That's the crux of the "Supabase left my data exposed" stories. It's rarely a dramatic hack. More often, a table was created, RLS was never enabled (or was enabled with no real rules), and the public-facing key could read data it was never meant to. Because AI builders move fast and don't always set this up for you, it's worth checking rather than assuming.
Two things to hold onto:
- RLS being on is necessary but not sufficient. On with weak or wide-open rules can still expose data. It's one signal among many, not a finish line.
- The fix is never "turn RLS off to make the error go away." If your app breaks after RLS is enabled, that usually means the rules need attention, which is a job for someone comfortable with database policies, not a reason to remove the protection.
How to tell whether your data is actually locked down
You can check the status of RLS from inside your own Supabase dashboard, using the account you (or your builder) control. This is looking at your own settings, the same way you'd check whether your front door is locked. It is not probing anyone else's app, and you should never try to test exposure by poking at a live app's data. Here's the safe, detection-first path:
- Log in to your Supabase dashboard. Use the account tied to your project. If you don't have the login, whoever set up the app does, and getting your own access is step one of owning what you built.
- Open your project and find the tables. There's a section (commonly the Table Editor or Database area) that lists the tables your app uses. These names usually mirror your app's data: users, profiles, orders, messages.
- Look at each table's RLS status. Supabase surfaces whether Row Level Security is enabled per table, and it typically flags tables where RLS is off. You're looking for tables that hold anything sensitive (people's emails, names, messages, payment-related records) with RLS disabled.
- Note, don't fix. Write down which tables have RLS off and what they contain. Resist the urge to start flipping switches. Enabling RLS without the right policies can lock your app out of its own data, and disabling it to "fix" a bug can quietly open the door. This is a mapping exercise, not a repair.
If reading the dashboard feels murky, that's normal, and it's a good moment to pause. Understanding what you're looking at is part of the goal; you can find a gentler on-ramp in our guide to understand what you built. For a wider sweep of your setup, this post is one piece of a larger non-engineer security self-audit.
What to do if it isn't, and when to get a professional
Say you find a table full of personal data with RLS switched off. What now?
First, don't panic and don't improvise. The instinct to jump into the dashboard and start writing rules, or to disable something to stop an error, is exactly what causes accidental exposure. A misstep here can either lock you out of your own app or leave data open while looking "fixed."
Second, decide whether this crosses the professional threshold. Some situations you can reasonably keep learning about on your own. Others call for expert help before you rely on your own read of the situation.
| Situation | Reasonable to keep investigating yourself | Get a professional involved |
|---|---|---|
| App stores only non-sensitive data (e.g., public content you'd happily show anyone) | Yes, keep learning and mapping | Optional |
| App has user logins / accounts | Map it, then | Yes, before relying on your own check |
| App stores personal data (names, emails, messages, addresses) | Map it, then | Yes |
| App touches payments or anything financial | Map it, then | Yes, do not go it alone |
If your app handles payments, authentication, authorization, or personal data, have a qualified security professional verify the design and findings. A dashboard glance is a starting point, not a clearance. This is educational information, not legal or security advice.
When you do bring someone in, you'll get more for your money if you can hand them a clear picture: which tables exist, which have RLS off, and what each one stores. Our guide on when to hire a security professional covers how to find the right person and what to ask for, so you're not paying an expert to do discovery you could have prepped yourself.
There's also a longer-term lesson here about tool choice. The platforms you build on shape how much of this responsibility lands on you. If you're weighing what to build on next, choosing a tool you can live with is worth reading, and it's.
In Plain English
What this means: Supabase is the storage-and-sign-in engine behind a lot of AI-built apps. Whether your data is private or exposed usually comes down to one setting, Row Level Security, being properly on for the tables that hold sensitive information.
Who this helps: Solo founders and non-technical builders who discovered their app runs on Supabase and want to know, without learning to code, whether their data is locked down.
When to use it: As soon as you realize your app uses Supabase, and especially before you launch to real users or start collecting anyone's personal information.
What to do next: Log in to your own Supabase dashboard, look at each table's RLS status, and write down which sensitive tables have it turned off. Don't flip switches. If the app touches payments, logins, or personal data, take that map to a security professional.
The single setting to verify today: open your dashboard and confirm Row Level Security is enabled on every table that holds anything you wouldn't want a stranger to read. Finding it on is a good sign, not a guarantee, so treat it as the first check, not the last.
Do this next
Ready to look beyond this one setting? Work through the rest of your setup with the Security self-audit toolkit, a step-by-step, non-engineer way to check your data exposure without touching anything unsafe. When you're ready to act on what you find, secure what you shipped walks you through the next moves at your own pace.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.