1.6万个数据库公开可读：没被黑，是门没关

一天三起数据暴露：问题不在攻击，在配置

最新一期的网安日报梳理了三起典型的数据安全事件，共同点是：它们几乎都不是被高明的黑客攻破的，而是数据本身就摆在了公网上，任人取阅。

据B站UP主「老黄谈安全」的整理，当天最受关注的三件事包括：美国一家电力公司749万条客户记录被挂上暗网，但公司方面并未承认这一数字；华硕官方商店称订单信息和联系方式可能被访问；比利时的科研网络则因零日漏洞，导致三个月的邮件被复制并外传。

前两起指向数据泄露与外部漏洞，而真正暴露行业系统性风险的，是第三类——数据库配置错误导致的公开可读。

1.6万个数据库主动“交出”数据

安全研究者用工具扫描了约30万个 Supabase 网址，向它们询问一个简单的问题：有没有 users 表？结果，一万六千多个数据库直接把数据交了出来。

这里的关键在于，这些库没有一个是被“攻破”的。它们没有被暴力破解密码，没有被利用某个未公开漏洞，而是权限配置本身就允许任何人读取。换句话说，门根本没锁——甚至可以说，门就没装。

Supabase 作为开源的后端即服务（BaaS）平台，提供了数据库、认证、存储等一整套能力。它的行级安全策略（Row Level Security, RLS）是保护数据的核心机制，但默认状态下如果开发者没有正确开启和配置，数据表就可能对外完全开放。

最扎眼的案例：车牌、姓名、邮箱全在公网

在这批暴露的数据库里，最刺眼的是美国一家代客泊车（valet parking）公司。据披露，约七万八千条车牌记录、四万三千条邮箱和真实姓名，全都躺在公网上，无需任何认证即可访问。

车牌加住址、姓名的组合，意味着攻击者可以将一个人的车辆、身份和活动轨迹关联起来。对普通用户而言，这类信息的泄露远比一串抽象的“记录数”更具现实威胁——它直接指向线下的物理安全。

车牌与个人身份信息的组合之所以危险，在于它能实现"虚拟到现实"的追踪链路。单独的车牌号在许多国家可通过公开渠道查询到车辆登记信息，而当车牌与姓名、邮箱乃至历史泊车记录一同暴露时，攻击者便能构建出某人的出行规律、常去地点乃至住所。这类信息在地下市场被称为"可操作情报"（actionable intelligence），可用于定向跟踪、社会工程学攻击，乃至实体犯罪。代客泊车场景尤为敏感——用户通常将车辆和钥匙一并托管，服务记录天然包含车牌与联系方式，且往往对应高价值场所（酒店、餐厅、机场），使这类数据库成为犯罪者的优先目标。

两个趋势：AI复制与“默认安全扛不住默认不懂”

这期日报点出了两个值得警惕的趋势。

趋势一：AI 加速了“复制式”上线

借助 AI，开发者可以在极短时间内“一键生成”几十个网站或应用。问题在于，这些项目往往带着同一套默认设置批量上线。一旦这套默认配置存在安全隐患，风险就会被成倍复制——一个配置错误，瞬间变成几十个暴露在外的数据库。

趋势二：默认安全，扛不住默认不懂

平台可以把默认设置做得再安全，也架不住使用者根本不理解这些设置意味着什么。UP主的观点很直白：勾错框的确实是客户，但写提示词、搭系统的人，多半根本不知道还存在“行级权限”这回事。

当低代码、AI 辅助开发大幅降低了建站门槛，大量并不具备安全知识的人涌入开发链条，安全责任与安全能力之间就出现了明显的错位。工具越易用，这种错位越普遍。

核心观点：不是被攻破，只是被忘了

“这一万六千多个库，没有一个被攻破，只是被忘了。”这句话是整期内容最核心的判断。

UP主用了一个形象的比喻：我们花大钱买房子住，却没花钱看看门关没关。系统上线时的兴奋、对功能的追求，往往盖过了对配置的检查。而真正让数据裸奔的，恰恰是这最后一步的疏忽。

由此引出的判断颇具启发性：未来两年最值钱的岗位，未必是那些能造出复杂系统的工程师，而是在上线前肯回头看一眼配置的人。当建设能力被 AI 极大放大后，“确保安全”这一环反而成了稀缺环节。

给开发者的现实提醒

对使用 Supabase 或类似 BaaS 平台的开发者，这批案例是一记警钟：

• 确认每一张敏感数据表都启用了行级安全策略（RLS），并明确验证策略是否真正生效；
• 不要信任“默认就安全”，AI 生成或模板复制的项目更要逐项核对权限配置；
• 上线前做一次外部视角的访问测试，模拟匿名用户能读到什么；
• 把“配置审查”当作发布流程的必经环节，而非可选项。

数据安全的短板，正从“被攻击”悄然转向“自己没关门”。在 AI 大幅降低建设门槛的当下，谁能守住配置这道最基础的关，谁就守住了用户最敏感的信息。

背景补充

Supabase 的行级安全策略（Row Level Security，RLS）源自 PostgreSQL 的原生特性，允许开发者在数据库层面为每一行数据定义访问规则，例如"只有当前登录用户可以读取自己的订单"。与应用层的权限控制不同，RLS 在数据库引擎内部执行，即便应用代码存在逻辑漏洞，未授权的请求也会在数据库入口处被拦截。然而，Supabase 在早期版本中默认关闭 RLS，新建的数据表对持有项目 API 密钥的任何人完全可读。由于 Supabase 的匿名密钥（anon key）被设计为可以安全地嵌入前端代码，这意味着任何能访问某个网站源码的人，都可能拿到该密钥并直接查询后端数据库——前提是开发者没有手动开启 RLS 并编写相应策略。这种"默认开放"的设计初衷是降低上手门槛，却在大量开发者不了解其含义的情况下，演变成系统性的安全隐患。

这一现象在安全领域被称为"配置漂移"（configuration drift）的变体——只不过传统的配置漂移指系统在运行过程中偏离安全基线，而 AI 辅助开发带来的是从第一天起就携带错误配置批量上线。当开发者使用 AI 生成样板代码或直接复制模板项目时，安全设置往往以注释或文档的形式存在，而非强制执行的检查项。AI 工具本身通常也不会主动提示"你还没有开启 RLS"——它只负责生成能运行的代码，而非能安全运行的代码。这种生产力与安全意识之间的剪刀差，随着生成式 AI 的普及正在快速扩大。