Database Exposed Publicly: I Found 9 Open by URL (Simply Explained)

A Lock With a Sticker That Says "Locked" Isn't a Lock

Imagine a storage unit with a sticker on the door that reads "Locked and Secure." You'd glance at it and assume your stuff was safe.

Now imagine the door was never actually locked. The sticker was the only thing protecting it.

That's what I found inside one of my databases. A security setting with a reassuring name, sitting right there in the dashboard, looking perfectly fine. Except the actual setting underneath it let anyone in. Not a hacker. Not someone with stolen passwords. Anyone with the website address and a key that every website hands out to every visitor by design.

So I checked all of them. I'm responsible for 29 databases. I went through every single one.

Nine were wide open. Anyone could read everything inside them.

What "Wide Open" Actually Meant

Let me be clear, because this isn't theoretical. I'm not saying "a clever attacker could maybe get in under the right conditions."

I'm saying a total stranger could paste a public key into their browser and download entire tables of private information.

Here's what was sitting out in the open across those nine databases:

Job applicants' personal info (names, contact details, the stuff that gets companies in legal trouble). Client emails and payment details from a financial advisory app. Personal body-measurement data from a fitness app. Customer records from a window-treatment business. And one of my own e-commerce systems, because nobody gets a pass, including me.

Five completely different businesses. Different developers, different years, different tools. The exact same mistake in every one.

That's the part worth sitting with. This isn't a rookie error. It's a pattern. The tools make the unsafe shortcut easy and the safe path a little harder, so people take the shortcut to ship faster. Speed favors the open door.

Why the Dashboard Lied to Me

Every database has a setting that controls who can see what. Think of it like a bouncer at a club. The bouncer has a name tag, a job (who he reports to), and a list of rules about who gets in.

Here's the trap. The name tag means nothing. You can call the bouncer "Members Only Security," but if his actual rule list says "let everyone in, always," then everyone gets in. The name on his shirt is just decoration.

That's exactly what happened. The settings had sensible names like "authenticated read only." Reassuring. But the actual rule underneath said "anyone, anytime, everything."

The dashboard showed green. Security was technically "on." Every developer who looked at it assumed the door was locked.

It wasn't. And I only caught it because I stopped trusting the names and read the actual rules.

This is the kind of thing that never shows up in a meeting. Nobody reports "our database is wide open," because nobody knows. The system says everything's fine. Reality says the opposite.

How I Fixed It Without Breaking Anything

When you find one open door, the instinct is to slam every door shut immediately. That's how you crash a live business at 2 in the morning.

I didn't change a thing at first. I read.

I went through all 29 databases and sorted them into three piles.

Locked. Already set up correctly. Nothing to do.

Clean. Open, but on purpose. A product catalog is supposed to be public. Your marketing pages too. Open isn't always wrong.

Held. Open AND holding private data, but the business actually depended on that open access to function. Slam this door shut without thinking and you take the whole app offline.

For the nine that were genuinely exposed, the actual fix took minutes each. I changed the rules so only logged-in users could see their own data.

But the fix wasn't the important part.

The important part was the test. After each change, I sat in the attacker's chair. I used that public key, hit the database, and tried to pull the data myself.

Every time, I confirmed I got back nothing. Zero records. That's the proof.

This is the step almost everyone skips. They change the setting, see green in the dashboard, and call it done. They trust the tool to grade its own homework.

Don't. The dashboard tells you what you set up. Trying to break in yourself tells you what an attacker actually gets. Those are two different things, and the gap between them is exactly where leaks happen.

How to Check Your Own Business This Afternoon

You don't need to be technical for this. Hand your developer a short list and ask them to walk through it with you.

One, pull up every security rule and ignore the names. The names will lie to you. Look at who the rule applies to and what it actually permits.

Two, flag anything that lets the general public read data. That's your suspect list.

Three, for each flagged item, ask one honest question: is this supposed to be public? A product catalog, sure. Customer emails, payments, personal info, absolutely not.

Four, before you lock anything down, make sure the app doesn't secretly rely on that open access. Otherwise you fix the hole and break the business at the same time.

Five, after the fix, have them try to break in using the public key and confirm they get nothing. This is non-negotiable. Skip it and you've just changed a setting and crossed your fingers.

If your developer pushes back and says "security is on, we're fine," that is the exact false comfort that left nine of my databases open. Security being "on" is necessary. It's nowhere near enough.

Who's Reading Your Data Right Now

Here's the uncomfortable truth. Most companies have never had anyone test their database from a stranger's point of view. They have security turned on, a setting with a reasonable name, and a comfortable assumption that those two facts add up to safe.

They don't. I just proved it across nine of my own systems.

This is exactly the kind of thing I catch as a Chief AI Officer, because I build these systems and I audit them the same week. I'm not dropping a slideshow on your team and walking out. I'm in the database, reading the actual rules, trying to break in myself, and confirming nothing leaks before I call it fixed.

If you've shipped software fast, especially anything built with AI, the same mistake is statistically likely sitting in your business right now. Not maybe. Likely. My base rate is nine out of twenty-nine.

A door with a "Locked" sticker isn't a locked door. The only way to know which one you have is to test it.

Want to explore what AI could do for your business?

Book a free 30-minute strategy call. No pitch deck, no sales team, just a real conversation about your operations and where AI fits.

Book a Discovery Call