Someone tells you "the database is open to the internet" and it sounds like weather, abstract and far away. It isn't. It means a specific door got left open, and I want to walk through exactly what that door looks like, using a made-up example so no real product gets dragged into it.
What "open to the internet" actually means
A lot of apps built fast right now don't have a custom server sitting between the browser and the database. The frontend talks straight to the database, over the internet, using a key that lives inside the app's own JavaScript. That part is normal. Plenty of modern app-building tools are designed to work exactly this way, and that key is meant to be public. The actual safety net is a set of rules attached to the database itself, usually called row-level security, that decide which rows a given request is allowed to touch. When those rules are on and configured correctly, the public key can only ever see data belonging to whoever is logged in. When they're off, or half set up, that same key can see everything in every table.
A made-up example
Picture a scheduling app for freelance contractors. Someone built it over a few days, hooked up a hosted database, wired up logins, shipped it. It works. People sign up, book jobs, see their own calendar. Nothing in the product looks broken.
The issue, if it exists, isn't visible anywhere in the interface. It only shows up once you stop using the app the way it was designed to be used.
How someone would actually find it
This is the part that surprised me the first time I watched someone do it, because there's nothing clever about it. Open the app in a browser, open the developer tools, click over to the network tab, use the app like a normal user for a minute. Every request the frontend sends to the database shows up right there, endpoint and key both, in plain text, because they have to be. That's how the app is built to work.
- Copy that endpoint and key straight out of the network tab
- Paste them into a basic request tool like curl or Postman
- Ask for a table the logged-in user has no business seeing, every booking instead of just their own
- See what comes back
If the rules are set up right, the request gets refused or comes back empty. If they're not, it comes back with every contractor's name, every client's booking, sometimes billing details, whatever that table holds. Nobody guessed a password. Nobody found a zero-day. Someone asked the database a question it should have refused to answer, and it answered.
Why this keeps happening
That number isn't a fluke. A separate security report from the same year ran AI-generated code through standard vulnerability checks and found it failed close to half the time. This isn't one careless developer somewhere. It's a default setting that's easy to leave switched off when the app already looks like it works and nothing on screen tells you otherwise.
What actually fixes it
None of this requires a security background. Turn on row-level rules for every table before launch, not after you notice traffic. Treat any key sitting in browser code as public information, because it is, and never let it carry a permission you wouldn't hand to a stranger. Then run the same test yourself before anyone else does: open the network tab, grab the key, ask for something that isn't yours, and see what comes back.
Most people building fast right now aren't ignoring security. They've just never been shown where to look. Once you know it's a network tab and five spare minutes, it stops being mysterious, and it stops being something you only think about the week a story like this makes the rounds.