16,000 Databases Left Wide Open: Not Hacked — Just Never Locked

Three Data Exposures in One Day: The Problem Isn't Attacks, It's Configuration

The latest cybersecurity daily roundup covered three typical data security incidents, all sharing one thing in common: almost none of them were breached by sophisticated hackers. The data was simply sitting on the public internet, available for anyone to read.

According to a summary by Bilibili creator "Laohuang Talks Security," the three most notable events that day included: 7.49 million customer records from a US electric utility appearing on the dark web (though the company denied the figure); ASUS's official store acknowledging that order information and contact details may have been accessed; and Belgium's scientific research network suffering three months' worth of emails being copied and exfiltrated due to a zero-day vulnerability.

The first two point to data leaks and external vulnerabilities. But the one that truly exposes a systemic industry risk is the third type — databases left publicly readable due to misconfiguration.

16,000 Databases Voluntarily "Handed Over" Their Data

Security researchers used a tool to scan approximately 300,000 Supabase URLs, asking each one a simple question: is there a users table? More than 16,000 databases handed the data right over.

The critical point here is that not a single one of these databases was "breached." No passwords were brute-forced. No undisclosed vulnerabilities were exploited. The permissions were simply configured to allow anyone to read the data. In other words, the door was never locked — or more accurately, the door was never installed.

Supabase, as an open-source Backend-as-a-Service (BaaS) platform, provides a full suite of capabilities including databases, authentication, and storage. Its Row Level Security (RLS) is the core mechanism for protecting data. However, if developers don't properly enable and configure RLS, data tables can end up completely open to the public.

The Most Glaring Case: License Plates, Names, and Emails All on the Public Internet

Among the exposed databases, the most alarming belonged to a US valet parking company. According to the disclosure, roughly 78,000 license plate records and 43,000 email addresses with full names were sitting on the public internet, accessible without any authentication whatsoever.

The combination of license plates with addresses and names means attackers can link a person's vehicle, identity, and movement patterns together. For ordinary users, this kind of exposure poses a far more tangible threat than an abstract count of "records leaked" — it directly enables physical, real-world harm.

The reason license plate and personal identity combinations are so dangerous is that they enable a "virtual-to-physical" tracking chain. In many countries, a license plate number alone can be used to query vehicle registration through public channels. When a plate is exposed alongside a name, email, and even historical parking records, attackers can reconstruct someone's travel patterns, frequently visited locations, and even their home address. This type of information is known in underground markets as "actionable intelligence" and can be used for targeted stalking, social engineering attacks, and even physical crimes. Valet parking contexts are especially sensitive — users typically hand over both their vehicle and keys, service records naturally include license plates and contact information, and the locations involved tend to be high-value venues (hotels, restaurants, airports). This makes these databases a prime target.

Two Trends: AI-Driven Copy-Paste Deployment and "Default Security Can't Survive Default Ignorance"

This roundup highlighted two trends worth paying close attention to.

Trend One: AI Accelerates "Copy-Paste" Launches

With AI assistance, developers can spin up dozens of websites or applications in a very short time. The problem is that these projects often go live with the same default settings applied in bulk. Once that default configuration contains a security vulnerability, the risk is multiplied across every copy — one misconfigured setting instantly becomes dozens of exposed databases.

Trend Two: Default Security Can't Survive Default Ignorance

No matter how secure a platform makes its defaults, it can't compensate for users who fundamentally don't understand what those settings mean. The creator's take was blunt: yes, checking the wrong box is technically the customer's fault — but the people writing prompts and building these systems mostly have no idea that "row-level permissions" even exist.

As low-code tools and AI-assisted development dramatically lower the barrier to building applications, large numbers of people without any security background are entering the development pipeline. A clear gap has emerged between security responsibility and security competence. The easier the tools become, the more widespread this gap gets.

The Core Takeaway: Not Breached — Just Forgotten

"Not a single one of those 16,000-plus databases was breached. They were just forgotten." This is the central conclusion of the entire segment.

The creator used a vivid analogy: we spend a fortune buying a house to live in, but don't bother checking whether the door is closed. The excitement of launching a system and the focus on building features routinely overshadow a review of the configuration. And it's precisely that final, overlooked step that leaves data fully exposed.

This leads to a provocative conclusion: the most valuable roles over the next two years may not be engineers who can build complex systems, but people who are willing to look back at the configuration before hitting deploy. As AI dramatically amplifies the ability to build, "ensuring security" becomes the rare bottleneck.

A Practical Reminder for Developers

For developers using Supabase or similar BaaS platforms, these cases are a wake-up call:

• Confirm that Row Level Security (RLS) is enabled on every sensitive data table, and explicitly verify that the policies are actually working;
• Don't trust "secure by default" — AI-generated or template-copied projects need permission configurations reviewed item by item;
• Run an external-perspective access test before launch: simulate what an anonymous user can actually read;
• Treat "configuration review" as a mandatory part of your release process, not an optional step.

The weakest link in data security is quietly shifting from "being attacked" to "leaving the door open yourself." In an era where AI has dramatically lowered the barrier to building, whoever can hold the line on configuration is whoever protects their users' most sensitive information.

Background

Supabase's Row Level Security (RLS) is built on a native PostgreSQL feature that lets developers define access rules at the database level for each row of data — for example, "only the currently logged-in user can read their own orders." Unlike application-layer permission controls, RLS is enforced inside the database engine itself. Even if application code has a logic vulnerability, unauthorized requests are blocked at the database entry point.

However, early versions of Supabase disabled RLS by default, meaning newly created data tables were fully readable by anyone holding the project's API key. Because Supabase's anonymous key (anon key) is designed to be safely embedded in frontend code, this means anyone who can access a website's source code could potentially obtain that key and query the backend database directly — provided the developer hadn't manually enabled RLS and written the appropriate policies. The "open by default" design was intended to lower the onboarding barrier, but in the hands of large numbers of developers who don't understand what it means, it has evolved into a systemic security risk.

In security circles, this phenomenon is described as a variant of "configuration drift" — except that traditional configuration drift refers to a system gradually deviating from a secure baseline during operation, while AI-assisted development introduces misconfigured deployments at scale from day one. When developers use AI to generate boilerplate code or directly copy template projects, security settings tend to exist as comments or documentation rather than enforced checkpoints. AI tools themselves generally don't proactively warn "you haven't enabled RLS" — they generate code that runs, not code that runs securely. This widening gap between productivity and security awareness is accelerating rapidly as generative AI becomes mainstream.