北京
100个应用，14个已经打不开了，1个把OpenAI API 密钥直接写在了公开的 JavaScript 包里。这是 Vespez 创始人做的一次扫描结果——他把 Lovable 公开展示页上的 100 个应用全部跑了一遍自家工具。
他想回答的问题很直接：AI 工具让发布一个应用变得极其简单，那它有没有让发布一个安全的应用也变得同样简单？
扫描方式统一：无头浏览器加载页面，记录访客点击“同意”之前触发了什么，检查响应头，能找到隐私政策就读一遍。14 个应用在公开展示后几周内就已下线，被排除在评分之外，剩下 86 个进入统计。
平均安全分 77/100，平均 GDPR 分 38/100。两个数字摆在一起，差距比想象中大得多。
那个泄露密钥的应用没有被点名。处理方式是私下上报，不公开广播。任何人打开开发者工具就能读到那把密钥——这是扫描里最扎眼的一条，但不是最普遍的一条。
真正普遍的是响应头缺失：
- 96% 没有 Content-Security-Policy 头
- 92% 可以被其他站点嵌入（点击劫持）
- 这两项同时缺失的比例也是 92%
92% 不是 92 个独立决策，而是一个平台默认值。Lovable 不会替你设置这些头，除非有人明确知道要加，否则它们就不存在。同样的逻辑还出现在字体上：55% 直接从谷歌服务器加载 Google Fonts，模板默认，不是刻意选择，而这恰好是 GDPR 真正在意的那类第三方数据流。
隐私政策这一块则要归到构建者头上：57% 找不到隐私政策，63% 没有服务条款。
整组数据里最干净的一个结论，是同意横幅的预测力。有横幅的应用，只有 10% 会在用户同意前加载追踪器；没有横幅的，这个比例是 96%。横幅存在，它就起作用。缺口在于 86 个应用里有 23 个从来没加过。
86 个应用里，GDPR 一项拿到干净评分的数量是零。安全项零发现的只有 3 个。
还有一个值得留意的小模式：按域名拆分，仍挂在 lovable.app 子域名下的应用平均 GDPR 分 44，迁到自有域名的平均 34——更差，不是更好。样本量 36 对 50，作者自己的说法是“值得观察的模式，而不是定律”。他的解释是：迁到自有域名通常意味着你把它当成正经产品在做，那这些缺口的分量就更重了。
方法层面需要说清楚边界：安全项是对页面和响应头的确定性检查；GDPR 项在有隐私政策的情况下，由一个 AI 模型读政策文本，再对照站点实际行为。页面内容除分数和发现项外不做保留。这不是法律审计，只是一次扫描——低分意味着很可能有问题，不等于确认违规；样本来自公开的 AI 构建器展示页，不是随机抽取的互联网切片。
作者在文末抛出的问题是：有没有人扫描过自己 AI 生成的产出，看到过类似的模式，或者这套方法还有没覆盖到的角度。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
