PHI Data Leak in Supabase: How I Found and Closed It (Simply Explained)

I Found Medical Records Anyone Could Read

I built a private health dashboard for a family member. It takes real medical records, lab results, blood work, the kind of data with legal weight, and turns them into something easy to read and track over time.

During a routine review, I checked something I check on every project now. I looked at what a complete stranger could see if they knew the web address.

The answer was bad. The lab results were wide open. Anyone with the link could pull every record. No password. No login. Nothing.

Think of it like a doctor's office with the filing cabinet sitting on the sidewalk, unlocked, with a sign pointing to it. That is what I had built without realizing.

I caught it myself before anyone got hurt. No one accessed it. But that is not the point. The point is it should never have been live like that in the first place. And I built the thing. I knew it inside out. If I can miss this, almost anyone can.

Why This Happens to So Many Apps

This was not me being careless. It was two small shortcuts that quietly added up to a leak. Once you understand how it happens, you can check your own app in about ten minutes.

Here is the first shortcut. A lot of modern apps store their data in a system called Supabase. When you create a new place to store data in it, the security lock is turned OFF by default. Nothing warns you. You have to remember to turn it on yourself.

So if you forget, and most people do, the front door is just open.

The second shortcut is sneakier because it looks like you did the right thing. When you are building fast, it is common to turn the lock on but then set it to "let everyone in" so the app keeps working while you build. You tell yourself you will tighten it later.

You almost never tighten it later. "Temporary" becomes "live" the day you launch, and nobody circles back.

Here is the part that should make any business owner uncomfortable. If you built your app fast with AI tools, this is more likely, not less. AI assistants set these wide-open shortcuts on purpose so your app keeps running while you build. They are optimizing for "it works," not "it is safe to ship." Every shortcut is still there unless a human went back and locked it.

How to Check Your Own App This Afternoon

If you have launched anything that touches customer, health, or financial data, you do not have to lie awake wondering. You can get an answer today.

The test is simple. Pretend you are a random stranger with no login. Try to pull up your most sensitive information. Your customer list. Your records. Whatever you would least want printed on the front page of a newspaper.

If the data shows up, you have a leak. It is that black and white. There is no "technically possible but unlikely." If a stranger can see it, it is public.

Then do a quick audit. Go through every security rule in your app and flag two things. Any rule that says "let everyone in." And any place where the lock was never turned on at all. That second one is easy to miss, because there is no rule to read, just an empty space where protection should be.

This whole check takes about an hour. The problem is invisible until you go looking, and most teams never look.

How I Locked It Down

Once I confirmed the leak, the fix was methodical. I worked from a simple rule: start with everything locked, then open up only the few things that genuinely need to be public.

First, I removed every "let everyone in" rule across the whole system. No exceptions. Even on stuff that looked harmless. "Looks harmless" is a guess, and guessing is how leaks happen.

Then I gave the public side of the app permission to read only the truly public stuff, like app settings and reference info. And only read. It cannot add, change, or delete anything. There is no reason a random visitor should be able to write to your database, ever.

The medical records got the strictest treatment. The public side of the app cannot touch them at all. Not even to read. The only way to see that data now is through a secure check that confirms who you are and that you are allowed to see those specific records first.

One thing trips people up here. For medical records, just reading them is the whole problem. Reading the lab results is the breach. So locking them down completely is not paranoia. It is the bare minimum.

The Second Leak Nobody Talks About

Closing that hole fixed the live database. I thought I was done. I was not.

Digging further, I found the raw medical record sitting inside the project's files themselves, in plain text. That means it was copied onto every computer that had a copy of the project, and to anyone with access to it.

A locked database does no good if the same data is sitting in plain sight two folders over.

And here is the harder truth. Deleting that file does not actually erase it. These systems keep a full history of every change, so the data lives on in the record of past versions. Cleaning it up properly is real work, not dragging a file to the trash.

The lesson is bigger than one app. Data leaks are not only in the database. They hide in your files, your logs, your backups, even error reports that quietly captured sensitive information.

The Pattern Behind All of It

Step back and look at all three problems. The lock left off. The "let everyone in" rule. The records left in plain sight.

Every one came from a shortcut chosen for speed that nobody went back and reversed. None of them were malicious. None were even unusual. They are the natural state of anything built fast and shipped before someone ran a real security check.

The fix is not to slow down. Speed is the whole reason to build with AI. The fix is to run a deliberate security pass before anything touches real data. Treat it as its own step, not something you hope happened along the way.

I now do this on every project. I once ran this exact check across 58 different projects in a single day.

Here is my honest take. I built this app. I knew it cold. I caught the leak myself. And it was still sitting there, live. If someone who does this for a living can leave a hole like that, an in-house team shipping their first AI app almost certainly has one too. Probably more than one.

So the question every business owner should ask is simple. Do we actually know what a stranger can see right now? Not "we think it is fine." Not "the developer said so." Do you know, because someone actually checked?

The cost of finding it yourself is an afternoon. The cost of a customer or a regulator finding it is a fine, an awkward breach announcement, and a very bad week explaining to your board how it happened.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together