- AI 帮忙写出来的应用确实能用，但在您开放给客户之前，还没有人试过攻破它。
- 常见的漏洞点有五个。企业主不用看代码，靠提问就能自己检验。
- 如果应用要存客户的姓名、电话或历史记录，那么在接收真实数据之前，应该先通过全部五项检查。
应用能正常使用，还说明不了它安不安全
假设团队里一位年轻同事用 AI 工具，一个周末就做出了一套预约系统。您试着预约、取消、打开报表，一切正常。这样试用只回答了一个问题：正常使用的人用不用得了。还没有人问过：存心乱用的人，能对这套系统做些什么？
Vibe Coding（氛围编程）是指用日常语言下指令，让 AI 写出全部代码。下指令的人通常不看生成的代码，而这类工具的设计目标，就是按指令一直改到界面能正常运行为止。如果指令里没提访问权限、密钥怎么存放、用户输入的数据要不要校验，生成的代码往往就不包含这些。界面依旧好看，每个按钮依旧能点，所以没有任何东西提醒您少了什么。
软件安全公司 Veracode 用 100 多个语言模型测试了 80 种编程任务，并于 2025 年 7 月发布报告：生成的代码虽然能完成任务要求，但在 45% 的任务中含有安全漏洞。同年披露的漏洞 CVE-2025-48757 显示，在 Vibe Coding 平台 Lovable 上搭建的 170 多个应用没有设置数据权限规则，外部人员不用登录就能读取和修改其数据库中的数据。
平台方辩称，设置权限规则是每个应用所有者自己的责任。对企业主来说，这意味着一旦数据泄露，要向客户交代的是您，用来搭建应用的工具不会和您分担责任。
Vibe Coding 应用最常出漏洞的五个地方
想象一家刚装修好的店：门面漂亮，收银机也能用，可还没人去看后门锁没锁、备用钥匙放在哪里、钱箱谁能打开。表中这五个地方就是应用的“后门”，每一项都附有一个问题，您现在就可以拿去问做应用的人。
| 检查点 | 出漏洞时的表现 | 企业主可以用来检验的问题 |
|---|---|---|
| 数据查看权限 | 以一位客户的身份登录，改一下链接末尾的数字，就看到了另一位客户的数据 | 如果改掉链接末尾的数字，会不会看到别人的预约单？请现在就演示给我看。 |
| 系统密钥 | 数据库或支付服务的连接密钥直接写在网页代码里，谁打开都能看到 | 我们付费使用的服务，密钥存放在哪里？哪些人能看到？ |
| 数据库 | 外部人员绕过应用，直接向数据库发送指令，整张表都能读出来 | 有没有不经过应用界面就能访问数据库的途径？每张表设置了什么访问规则？ |
| 用户提交的数据 | 输入框什么内容都接受，上传入口什么类型的文件都收 | 如果有人输入奇怪的指令，或者上传的不是图片，系统会怎么处理？ |
| 第三方代码包和操作日志 | 应用用了存在漏洞的代码包版本，出事时也没有日志可以回查 | 如果明天有人通知我们数据泄露了，我们能不能查出是谁、在什么时候进来、做了什么？ |
第一项最常见，也最难察觉。软件安全领域的非营利组织 OWASP 在 Top 10 榜单中，把访问控制失效列为 Web 应用的头号风险。登录验证（Authentication）确认用户是谁，权限控制（Authorization）决定这个用户能看什么。前者会出现在界面上，所以 AI 通常会把它做完整；后者需要在应用读取数据的每一个地方写好规则，一旦规则缺失，也没有哪个界面会提示。
第二项和第三项往往同时出现。赶工做出来的应用常常让网页直接连接数据库，连接密钥也就跟着发到了每个用户的浏览器里。新一代数据库可以支持这种连接方式，前提是每张表都设置了行级安全规则（Row-Level Security）。上文 Lovable 的案例，问题就出在没有这项规则的表上。
写给开发团队 · 技术检查清单
凡是接收数据引用 ID 的 Endpoint，都要在服务端校验 Authorization。每张表都启用 Row-Level Security 并配置 Policy。把 Secret 从前端 Bundle 和 Repository 的历史记录中清除，统一放进 Secret Manager。所有输入项使用参数化查询（Parameterized Query）和输入校验（Input Validation）。限制上传文件的类型和大小，登录页设置 Rate Limit。在 CI 中运行 Dependency Scan 和 Secret Scan，并为个人数据的读取和修改操作保留审计日志（Audit Log）。
模拟案例
理疗诊所的预约链接：改个数字，就能打开别人的预约单
一家有三家分店的理疗诊所，让一位分店经理用 AI 工具做了一套预约系统。系统通过短信把预约单链接发给患者，链接末尾是预约单的流水号，比如 1042。有位患者试着把数字改成 1041，结果看到了另一位患者的姓名、电话和病情。他截了图，发给了诊所的社交媒体账号。
诊所把系统停了一周，改回用本子登记预约。修复只花了几天：在服务端加规则，让预约单只有患者本人和该分店的员工能打开；把流水号换成随机编码；开始记录每次查看。诊所答不上来的是：在此之前，有人打开别人预约单的情况已经发生过多少次。旧系统从来没有记录。根据泰国《个人数据保护法》（PDPA），健康数据属于敏感数据，所以诊所必须请法律顾问评估，需要就这次事件通知哪些对象。
接收真实数据前，先查这五道门
- 列出应用存储的所有数据，标出其中属于个人数据或与钱有关的项目。
- 建两个测试账号，登录第一个账号，再逐一打开从第二个账号拿到的所有链接。
- 请一位看得懂代码的人，在网页代码和代码修改历史里搜索密钥。
- 逐张表查看数据库的权限规则。没有规则的表，一律当作敞开的门。
- 用一个问题演练事故：如果昨天有人把数据拖走了，我们今天能从哪里发现？
每一项都记下结果、检查日期和检查人姓名，留作公司在上线前做过检查的证据。这个方法能发现基础漏洞，但替代不了专业人员的渗透测试（Penetration Test）。收款或存储敏感数据的应用，还要再往前走一步。
检查要做多深，取决于应用掌握着什么数据
每户人家都该锁门，但只有一部分需要装保险柜。应用也一样，检查力度应该与数据的价值和敏感程度相匹配。给小工具做过头的检查，钱就花错了地方。
不涉及客户数据的内部工具，比如销售团队内部用的报价计算器，用 Vibe Coding 做好就可以直接用，只需确认代码里没有写入公司的密钥。存储客户姓名、电话或邮箱的应用，应当五道门全部查一遍，上线前还要请一位没参与开发的工程师审查权限和密钥。
收款的应用，或者存储健康数据、财务数据、身份证复印件的应用，要求更高。从设计阶段就应该做威胁建模（Threat Model），也就是提前梳理谁可能从哪条路径发起攻击、会造成什么损失；上线前请外部测试人员做渗透测试，系统有重大变更时再做一次。
如果应用里有会读取内部文档的聊天机器人（Chatbot），还会多一种风险：提示词注入（Prompt Injection），也就是用户输入暗藏的指令，诱使 AI 透露他无权查看的数据。有效的防法是把 AI 的权限限制在与提问者相同的范围内。
出现以下任何一种情况，先别接收真实数据
- 团队里没人说得清系统密钥存放在哪里
- 一个测试账号能打开另一个账号的数据
- 数据库里还有没设权限规则的表
- 系统不记录谁查看或修改了客户数据
- 出事时该通知谁，说不出具体的人
从成本看，上线前检查和修复，比出事后再修便宜。出事后，修复费用一分不少，还要加上系统停机的损失、团队应付客户所花的时间，以及法律上的责任。泰国的 PDPA 规定，数据控制者须在知悉个人数据泄露事件后 72 小时内，向个人数据保护委员会办公室报告，除非该事件不会对数据主体的权利造成风险。具体怎样执行，应咨询公司的法律顾问。
谁都能 Vibe Coding，工程师团队还有哪些地方用得上？
AI 照着指令做事，而安全方面的问题大多是下指令的人没想到的。真正在系统遭受攻击时维护过系统的人，知道动手写代码之前要问什么，也知道写完之后该拿系统试些什么。
今年，好的开发团队也和大家一样用 AI 写代码，区别在于代码之外的那套流程：动手前先设计权限；AI 写的代码要经工程师读过才合并进系统；每次改动都会运行漏洞扫描工具；交付文档上写明负责人的名字，出了事您可以直接打电话找他。
企业主可以要求查看的指标只有几项：按严重程度分类的未修复漏洞数、修复高危漏洞所用的天数、最近一次检查的日期，以及数据泄露应急演练的结果。如果没人答得出这些数字，说明这件事目前没人在管。
为已经做好的应用做安全检查和加固，或者从设计第一天就把安全考虑进去
哪些数据绝对不能出问题，您和公司的 IT 团队最清楚；法律有哪些要求，由公司的法律顾问来判断。DNA Maker 会先和这些人一起梳理：应用存储哪些数据、数据经过哪些环节、谁应该看到什么，再整理成数据流图、按角色分配的权限表，以及需要人工审批的环节清单。
已经用 Vibe Coding 做好的应用，我们会按本文的五个检查点做安全审查（Security Review），提交按严重程度排序的漏洞报告，然后与原团队一起修复，或者由我们接手修复。如果是新系统，权限、密钥存放、输入数据校验和操作日志从一开始就写进系统架构（Architecture）；AI 辅助写出的每段代码都由工程师审查，代码和第三方代码包在流水线（Pipeline）中扫描，正式上线前还会做好准备，让外部渗透测试人员进场检查。如果您有一个即将开始接收客户数据的应用，可以带上应用链接和它所存储的数据清单，来和我们的工程师聊一聊，就能知道上线前哪些地方必须先修。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
和开发团队谈安全问题时，会经常听到这些词。最右一列的问题，可以用来确认每一项是否真的有人在负责。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Authentication | 在用户进入系统前确认其身份，例如密码、短信验证码或人脸识别 | 患者输入手机号和短信收到的验证码，才能打开预约单 | 哪些用户需要双重验证？忘记密码时如何找回账号？ |
| Authorization | 确认身份之后，规定每个用户能查看或修改哪些数据的规则 | 患者只能打开自己的预约单，员工只能打开所属分店的预约单 | 每次读取数据时，权限规则是否都在服务器端校验？由谁负责测试？ |
| Secret Management | 把系统密钥（如数据库密码、支付服务密钥）存放在代码之外，并限制能看到的人 | 短信服务的密钥存放在密钥管理系统里，网页代码中没有这把密钥 | 如果密钥泄露，我们几分钟内能换上新密钥？由谁来换？ |
| Row-Level Security | 数据库中的规则，规定每个用户只能读取或修改哪些数据行 | 预约表只返回属于当前登录患者的数据行 | 哪些表还没有设置这项规则？原因是什么？ |
| Threat Model | 提前梳理谁可能从哪条路径攻击系统、会造成什么损失，据此决定先保护哪些地方 | 团队逐一分析患者、已离职员工和外部人员，各自可能通过什么途径接触到病历 | 我们系统排名前三的风险是什么？每一项由谁负责？ |
| Penetration Test | 在签订协议的前提下，聘请专业人员实际尝试攻入系统，赶在攻击者之前找到漏洞 | 外部测试人员在没有账号的情况下尝试获取患者数据，然后提交报告，说明他们能做到哪些事 | 最近一次测试是什么时候？覆盖了哪些部分？发现的漏洞都修复了吗？ |
| Dependency Scan | 检查系统引用的第三方代码包中，是否有已公开披露漏洞的版本 | 扫描工具提示处理文件上传的代码包有漏洞，团队在上线前完成了更新 | 每次修改代码都会运行这项扫描吗？告警发给谁？ |