Grok 应用默认公开，敏感数据暴露

用 Grok 生成应用，风险可能出在点击「发布」的那一刻。安全公司 Claroc 检查了 37,571 个仍在线的应用，其中 35,578 个无需登录就能访问，占 94.7%。暴露内容包括患者化验值、明文密码，以及开发商自己的销售资料。

这篇报道值得程序员读的地方，在于它把三件容易混淆的事拆开了：链接是否公开、地址能否被发现、登录后到底能做什么。AI 把页面写出来了，这三道边界却可能一道也没守住。

「拿到链接才能访问」为什么挡不住陌生人

原文称，SpaceXSI 前身为 xAI，其 Grok「Build」模式允许用户通过聊天描述应用，再由模型生成代码。应用需要创建者点击「Publish」才会获得 grok.me 地址，并非生成后立即公开。

问题出在发布时的默认选项。Claroc 使用付费账号测试，发现「Anyone with the link」已经被预选。用户可能只想打开成品看看，实际却发布了一个任何持有链接的人都能访问的应用。

而链接并不一定只在用户主动转发后流出。

每个应用都有独立子域名。报道指出，应用首次被访问后，其域名会进入商业被动 DNS 数据库，研究人员可以按模式搜索。被动 DNS 可以理解为对域名解析记录的持续收集，随机-looking 的地址也可能留下可查询的痕迹。

地址难猜，不能代替访问权限。

Grok 实际提供了「Only you」选项。Claroc 将测试应用切换到这个设置后，外部访问被阻止。作为对照，他们新建的一个 ChatGPT 应用默认使用「Only me」；地址同样可能出现在 DNS 数据里，但访问者仍然打不开应用。这个对照只覆盖测试样例，不能据此推断两家产品的整体安全水平。

94.7% 可以公开访问，不等于全部泄露隐私

报道中最醒目的比例，需要和后面的内容分类一起读。

Claroc 称，大部分开放应用是游戏、落地页或计算器。约十分之一包含敏感材料、内部业务数据或个人信息，约 2% 被归为尤其严重的情况；研究人员估计，650 到 800 个应用含有私密数据。报道没有充分展开这些类别的划分和重叠关系，不宜把它们直接当成同一种泄露口径。

不过，已确认的案例足够具体：

• 一份 ICU 简报包含患者化验值，一份医院集团名单涉及超过 3,500 名员工，还有消防部门的排班表。
• 一个工时应用的脚本中包含 18 个账号及明文密码。
• 来自 SpaceXSI 和 X 员工的 24 个开放应用中，有保密入职计划，包含内部系统地址和 19 个聊天频道。
• 一张销售区域图覆盖 594 个战略客户、六个销售区域及销售管线数据；另有八份 X 广告提案，其中一份面向美国联邦机构，并标注保密。

除 SpaceXSI 和 X 外，Claroc 还识别出 30 家受影响组织，其中六家属于 Fortune 500，但没有公开名称。

这里也要区分「数据可以被访问」和「已经被恶意利用」。报道证明了暴露情况，没有给出攻击者实际窃取这些数据的证据，也没有完整交代数据暴露了多久。

加了 Google 登录，为什么仍然能被外人删数据

发布权限之外，Claroc 在自己的两个测试应用里发现了代码层面的问题。

一个联系人应用连接了没有登录要求的数据库，匿名访问者可以添加记录。另一个销售团队客户列表更有迷惑性：Grok 主动加入了 Google 和 X 登录，看起来已经有了身份验证。

但生成代码的顺序是：先把每个完成登录的用户加入团队，再检查用户是不是团队成员。

检查当然会通过。Claroc 用一个外部 Google 账号，就能读取、修改和删除记录。他们表示，写入和删除测试仅在自建应用上进行。

身份验证只回答「你是谁」，授权还要回答「你能访问谁的数据」。

对前端和全栈开发者来说，这比「有没有登录按钮」更值得检查。团队成员资格应该来自已有授权关系；如果登录动作本身就能创建这层关系，后续成员检查便失去了作用。

SpaceXSI 回应称，应用在用户分享前保持私有，发布需要多个步骤并包含法律提示，员工账号则默认「Only you」。Claroc 的反驳是：最终一步仍预选公开访问，多点几次并不能消除误操作；24 个员工应用暴露，也说明更严格的默认值仍需要其他措施配合。

据报道，SpaceXSI 已下线这 24 个员工应用，其他用户和组织的开放应用尚未被移除。由于公司没有承诺联系受影响所有者，Claroc 开始直接通知他们。

我的判断

我赞同把私有访问设为默认值，并在发布前明确显示谁能访问。法律提示要求用户理解风险，安全默认值则直接减少错误操作，两者作用不同。

Claroc 还建议：应用带数据库却没有登录时应告警；用共享主机上的难猜路径替代独立子域名，减少名称进入 DNS 数据库的机会。后一个建议可以减少发现入口，但无法修复匿名数据库、明文密码和错误授权。

这份报告也有边界。Claroc 销售 AI 应用安全产品，有商业利益；报道未给出完整抽样方法，也未说明公开应用中有多少原本就打算公开。94.7% 是其检查样本中的开放比例，不能直接解释为 Grok 应用的隐私泄露率。

报道还列出此前事件：2025 年 8 月，超过 370,000 条共享 Grok 对话进入 Google Search；2026 年 7 月，终端工具 Grok Build 未经询问上传用户文件，包括 SSH 密钥和密码数据库。爱尔兰数据保护机构也因 Grok 生成的性化深度伪造内容，调查 X 是否忽视数据保护设计。

类似分享风险也出现在其他产品中。Claroc 在 10 月通过被动 DNS 找到约 6,800 条 Meta Muse 共享对话；另据报道，7 月有共享 Claude 对话和 artifacts 出现在搜索引擎，包括用户创建的应用。问题有共性，但这些事件不足以证明各产品风险程度相同。

能拿来做什么

• 发布 AI 生成的内部工具前，先确认访问范围，再用未登录窗口和外部账号打开实际地址，检查页面及数据是否都受到限制。
• 审查 Google、X 等登录后的处理逻辑，尤其检查是否自动创建团队成员关系，并分别验证外部账号能否读取、修改和删除数据。
• 检查生成的前端脚本和交付代码是否包含密码、员工名单或客户资料；一旦发现明文密码，应处理已暴露凭据，单纯隐藏页面不够。
• 在团队发布流程中默认选择私有访问；对连接数据库却没有身份验证的应用单独检查，并把分享权限作为上线检查的一项。