434项实锤缺陷：AI写的应用"能跑不能守"，数量第一的不是SQL注入而是它

三天上线一款应用，代价可能是三天攒下一年的安全债务。

对着AI说一句"帮我做一个客户管理系统"，几分钟后，数据库结构、接口逻辑、登录页面便自动生成。再补上几句自然语言指令，文件上传、会员订阅、数据看板、邮件通知也陆续到位。过去需要产品经理、前端、后端和运维协同数周才能完成的应用，如今一个完全不懂编程的业务人员，可能几天内就能做出一个可以公开访问的版本。

这就是近两年迅速走红的"Vibe Coding"，国内常译作"氛围编程"或"凭感觉编程"。在这种开发模式里，人不再逐行写代码，而是用自然语言描述目标，由AI编码工具完成生成、修改与部署。开发者的角色，从"如何写代码"变成了"告诉AI想要什么"。

它把软件开发的门槛压得很低，也把原型验证的速度提得很快。但一个越来越尖锐的问题也随之浮现：当应用开发速度提升十倍，企业的安全审查能力,是否也跟着提升了十倍？

SecurityWeek在2026年7月22日刊发的一篇报道,给出了一个令人警惕的答案。安全研究团队对一批由AI生成或改造的应用进行分析,最终保留了434项经过复核、被判定具有安全影响和利用条件的缺陷。资源耗尽与拒绝服务、越权访问、路径穿越、服务端请求伪造、密钥泄露,是其中最常见或最严重的问题。

这些发现共同指向Vibe Coding的一个核心风险:AI非常擅长把功能"做出来",却未必会主动去想,这个功能一旦遭遇恶意访问、异常输入、批量请求和权限绕过,会发生什么。

一、434项缺陷是怎么被找出来的

根据SecurityWeek引用的Xint研究报告,研究团队测试了三种常见的AI辅助开发方式。第一种是"详细需求驱动",研究人员向AI提供相对完整的规格说明,让它开发一款URL缩短服务,模拟有经验工程师主导需求、AI负责实施的场景。第二种是"随口提出需求",只给出类似"帮我做一个简单的讨论板"这样的简短指令,不附加任何安全约束,更贴近普通业务人员使用Vibe Coding工具的真实状态。第三种是"用AI改造现有系统",研究人员选择一款已有的内容管理系统,将其迁移到Laravel和React架构,并要求AI进行加固,以观察AI在大型复杂代码库中的表现。

研究共涉及28个应用实例,包括27个新建应用和一个经过AI重构的大型应用。扫描最初产生8827条原始检测结果,经过重复项合并、源码复核、触发条件分析和可利用性判断,研究团队最终保留434项发现,其中196项来自新建应用,238项来自大型重构应用。

这里有一个容易被媒体标题忽略的方法学边界。Xint报告在摘要中把这些问题描述为经过验证的真实漏洞,但在"研究限制"部分也明确说明,并非所有问题都在真实线上环境中完成了攻击利用,部分结论是基于源码证据、触发条件和复现路径得出的。报告同时承认,单个模型的样本数量较少,没有设置完全由人类开发的对照组,大型应用样本也只有一个。

因此,这组数字适合用来识别AI代码的典型风险模式,却不宜被简单解读为"所有AI生成应用平均都有多少漏洞"。

即便如此,434项经过严格筛选的发现,已经足以说明:Vibe Coding的安全问题并非偶发的语法错误,而是存在具有规律性的系统缺口。

二、最常见的不是SQL注入,而是应用被"用垮"

很多安全人员一听到"AI生成代码",第一反应往往是SQL注入、跨站脚本攻击和命令执行。研究结果却出现了一个值得关注的转向。

在434项发现中,数量最多的是资源耗尽和拒绝服务问题,共93项,占比约21%;授权和不安全直接对象引用问题88项;访问边界、路径穿越和服务端请求伪造相关问题54项。

资源耗尽类缺陷有一个隐蔽的特点:它通常不会让应用立刻报错。正常使用时,页面能打开,按钮能点击,数据也能成功返回。只有当请求数量增加、数据规模扩大,或者攻击者刻意构造批量操作时,问题才会暴露出来——查询接口没有分页上限,登录、注册、搜索和AI调用接口没有速率限制,文件上传没有尺寸和数量限制,CPU密集型任务在Web请求中同步执行,数据导出操作可以被无限重复触发,数据库查询没有结果数量限制,第三方API调用没有预算和配额控制,异常连接没有及时关闭,队列任务没有超时和重试边界。

AI为什么容易忽略这些问题?因为使用者提出的往往只是功能性目标:"帮我增加一个搜索接口""支持用户批量导出数据""增加一个调用大模型生成报告的功能"。只要功能能成功执行,AI就容易判断任务已经完成。至于这个接口一分钟能被调用多少次,一次最多处理多少条数据,恶意用户能否借此制造巨额云计算账单,往往从未出现在提示词里。AI于是交付了一个"可以运行"的接口,却没有交付一个"能够在敌对环境中运行"的接口。

三、严重程度最高的问题:密钥藏在代码里

虽然拒绝服务问题数量最多,但在23项被判定为"关键"严重等级的问题中,密钥和凭证暴露占据了最大比例。其中11项与硬编码、默认或可预测的应用密钥有关,另外6项涉及调试模式或依赖组件导致的远程代码执行风险。

这类问题在AI生成代码中格外典型。为了让示例程序快速跑起来,互联网上大量教程会直接在源代码中填写API密钥,使用固定的JWT签名密钥,采用默认数据库账号密码,在配置文件中保留演示凭证,开启调试模式,把管理接口暴露在公网,或者用一个简单字符串当会话密钥。这些"快速开始"示例大量存在于AI模型的训练资料中,当使用者要求"做一个能登录的应用"时,AI很可能优先选择最容易达成目标的模式——固定密钥不妨碍程序启动,调试模式甚至方便排错,普通的功能测试根本发现不了问题。

但应用能登录,不代表身份体系安全;令牌能生成,不代表令牌不能被伪造;接口能调用,也不代表调用者真的拥有对应权限。OWASP Top 10:2025依然把访问控制失效列为首要Web应用风险,认证失败类别中也明确包含硬编码密码和硬编码凭证。

四、案例复盘:三天上线的客户看板,如何一步步失守

下面的组合案例综合了多种常见问题,不对应某一家真实企业。

某科技公司市场运营团队需要一款客户项目看板,由于研发排期紧张,运营负责人决定自己动手,用AI编码平台开发。第一条指令是"帮我开发一个客户项目管理系统,需要用户登录、创建项目、上传合同、添加成员,并生成项目总结"。几个小时后基础页面完成,随后不断追加需求:增加管理员角色、支持链接邀请成员、增加批量导出、让AI自动总结项目进展、部署到云端。第三天,系统正式上线,页面简洁、功能正常,管理层非常满意,甚至计划推广到销售、客服和合作伙伴团队。但没有人做过威胁建模,没有安全人员审查代码,也没人明确哪些数据属于敏感信息。

第一个问题出在权限。前端会根据角色决定是否显示"编辑""删除"按钮,看起来实现了权限控制,但后端接口没有对每次操作重新校验用户是否有权访问对应项目,只是确认请求者已登录,再按参数直接查库。这意味着只要改动请求中的项目编号,普通用户就可能读取或修改别人的项目数据——这是典型的不安全直接对象引用(IDOR)。问题根源不是没有登录功能,而是开发者把"已经登录"和"有权访问这个对象"混为一谈。研究发现,这类问题会随应用规模扩大而增加:小型新建应用中,授权和IDOR问题占比约11%,大型重构应用中这一比例升至28%。简单的所有权检查AI容易正确实现,但权限规则分布在大量接口、角色和业务对象之间时,遗漏就变得难以避免。

第二个问题出在密钥。为实现登录状态,AI生成了JWT令牌,并在配置中设置了一个固定签名密钥,直接写在代码仓库里,没有进入专门的密钥管理系统。任何能读取代码、构建产物或错误日志的人,都可能接触到它。更危险的是,运营负责人曾把整个项目打包发给外部服务商,代码仓库也曾短暂公开。密钥一旦进入仓库,即便之后删除,也可能继续存在于历史提交、构建缓存、日志、开发者电脑和备份中。

第三个问题出在AI总结接口。系统允许用户点击"生成项目总结",后台调用外部大模型服务,但没有设置用户级速率限制,也没限制同一项目短时间内重复生成。正常情况下员工每天只点几次,但一旦自动化脚本持续调用,系统会不断消耗第三方模型额度,应用可能还没宕机,公司就先收到一张异常账单。这正是研究中数量最多的资源耗尽风险的缩影——它不一定窃取数据,却能消耗CPU、内存、连接、带宽、存储和按量付费的API额度。对接入生成式AI服务的应用而言,"拒绝服务"与"经济资源消耗"往往同时发生。

第四个问题出在文件功能。合同上传只检查了文件扩展名,没有验证实际类型,也没限制大小;新增的"从网络地址导入附件"功能让服务器可以根据用户提交的地址主动下载文件,一旦缺少目标地址校验和网络出口限制,就可能被诱导访问本不该被外部触及的内部服务,大文件和并发下载还会进一步放大资源耗尽问题。

第五个问题出在调试信息。为方便排错,AI在部署配置中保留了调试模式,接口异常时会返回代码路径、组件版本、数据库字段和调用栈等详细信息。这些信息未必能直接攻破系统,却能帮助攻击者摸清内部结构,寻找后续攻击路径。

最终,这款三天完成的应用不得不紧急下线。真正花费团队时间的,不再是开发功能,而是清点已上传的数据、轮换密钥、检查访问日志、通知相关部门、重新设计权限模型、重构部署环境。开发节省下来的时间,最终以安全事件处置和技术债务的形式重新支付。

五、为什么AI写出了正确功能,却给出了错误的安全答案

一项关于Vibe Coding应用安全性的学术预印本指出,AI生成应用中反复出现占位逻辑、输入过滤不足和秘密信息暴露等问题,部分原因在于AI开发过程中的上下文遗失、局部目标优化以及安全知识不足。改进模型能力和提示策略可以降低漏洞发生率,却无法完全消除风险。

从实际开发流程看,这些问题可以归纳为四种错位。

其一,使用者描述的是功能,不是威胁。"创建一个文件上传功能"说明了用户要做什么,却没说攻击者可能上传什么;"增加一个管理员角色"说明系统存在不同身份,却没定义每个角色能访问哪些对象。没有被明确表达的安全要求,很容易被AI当成不存在。

其二,AI优化局部任务,安全却依赖全局一致性。它可能在一个接口中正确检查了项目所有权,却在另一个导出接口中忘记同样的检查;可能在注册功能里限制密码长度,却在重置密码功能里用了不同规则。功能往往是局部的,权限和安全边界却必须全局一致。

其三,训练资料偏爱"快速开始"。公开教程通常强调如何十分钟跑通程序,而不是如何在生产环境中安全运营,默认密钥、宽松权限、调试模式在演示环境里被视为便利设置,AI一旦直接模仿,就把演示代码当成了生产代码。

其四,功能测试只验证"允许",很少验证"拒绝"。团队通常测试正确账号能否登录、项目能否创建、文件能否上传,但安全测试更关心错误账号是否被拒绝、A用户能否读取B用户的数据、同一接口被调用一万次会怎样、过期令牌是否还能用。AI生成应用经常能通过正向功能测试,却在负向测试中暴露问题。

六、企业能做的七件事

第一,先判断什么应用可以"凭感觉做"。可以按是否联网、是否处理敏感数据、是否涉及资金、是否影响关键业务,把项目分成四级:个人本地无敏感数据的应用可以走轻量流程;内部低敏感应用需要基础身份认证和权限;互联网开放或涉及内部敏感数据的应用必须经过专业代码审查、威胁建模和上线审批;涉及资金、医疗、身份、核心生产的高敏感应用,Vibe Coding只能作为受控的辅助手段,不能"AI生成后直接部署"。决定安全流程的,不是应用由谁开发,而是应用一旦失守会造成什么后果。

第二,把安全要求写进需求,而不是上线前补一句"请检查安全"。身份认证要用经过验证的框架、设置会话过期和速率限制;授权控制要求每个后端接口都执行服务端权限验证、默认拒绝访问;密钥必须从环境变量或密钥管理服务读取,绝不出现在代码和日志里;资源控制要为所有公开接口设速率限制、为分页设最大返回量、为高消耗任务设配额;错误与日志方面,生产环境必须关闭调试模式,详细错误只写入受保护的内部日志。

第三,建立"权限矩阵",逐个测试对象级授权。研究表明权限问题会随系统规模扩大而增加,企业不能只问"这个应用有没有登录",而要为每个角色和每个操作画出允许与拒绝的边界,并为每个后端接口至少创建三类测试:合法用户执行合法操作、已登录用户访问未授权对象、未登录用户直接调用接口。批量接口、导出接口、搜索接口、后台任务接口尤其容易遗漏权限检查。

第四,把"资源耗尽"作为AI应用的必测项目。对外开放前,至少要测试连续高频调用是否触发限流、单次查询要求返回全部数据时系统是否拒绝、上传超大文件会发生什么、队列积压时系统是否具备降级能力。对接入大模型、短信、地图等按量计费服务的应用,还要建立单用户额度、异常调用告警、自动熔断等成本防护机制。在AI应用时代,云成本异常本身就是一种安全信号。

第五,让AI生成的每一行代码都经过安全流水线。NIST的安全软件开发框架强调,安全实践应被整合进软件开发生命周期,而不是发布前的临时补救。可以在提交代码时做密钥扫描和静态分析,合并代码时做依赖分析和软件物料清单生成,部署测试环境后做动态测试和权限测试,进入生产前由具备能力的人员完成人工审查。发现关键漏洞、硬编码密钥或调试模式时,应设明确的阻断条件,不允许上线。

第六,不要只让AI"检查安全",要进行独立验证。生成阶段遗漏的安全假设,复核阶段也可能继续被忽略。更可靠的做法是分层验证:AI自查,不同工具或模型独立审查,静态动态扫描,人类工程师检查业务逻辑,最后在隔离环境中做攻击面测试。工具擅长发现已知模式,人类更擅长判断业务逻辑是否合理,两者不能互相替代。

第七,让安全团队看见"影子应用"。员工可能用个人账号创建应用、连接云数据库、导入客户名单并直接发布到公共域名,整个过程可能没有资产登记和安全评估。企业需要明确谁可以使用AI编码平台、哪些平台经过批准、应用部署在哪些云环境、员工离职后应用由谁接管。治理的目的不是阻止业务创新,而是确保每一个公开运行的应用都有明确的负责人和关闭机制。

结语:真正危险的不是AI写代码,而是没人对代码负责

Vibe Coding不会消失。在业务追求"更多、更快、更便宜"的压力下,AI生成代码只会越来越普遍。这项研究也带来了一些相对积极的信号:研究人员原本预计会发现大量SQL注入和跨站脚本问题,实际数量却低于预期,说明近期模型在使用参数化查询、对象关系映射以及处理基础输入安全问题方面已经有所改善。

然而,AI在局部代码模式上的进步,并没有解决全局安全问题。它仍然容易忽略资源限制、秘密管理、复杂授权、运行时状态和长期维护。因此,Vibe Coding带来的真正挑战,不是"AI是否会写出漏洞",而是软件责任发生了怎样的变化。过去,开发人员编写代码,也理解代码;现在,业务人员提出需求,AI生成实现,平台完成部署,安全团队可能最后才知道应用已经存在。当安全事件发生时,却没有人能准确回答:为什么使用这个权限模型,为什么这个接口没有限流,为什么密钥会出现在代码中,谁应该负责修复。

AI可以生成代码,却不能替企业承担责任。Vibe Coding真正成熟的标志,不是任何人都能在三天内做出应用,而是企业能够确保任何一个三天做出的应用,在面对真实攻击时仍然守得住。开发速度可以由AI提升,安全底线仍必须由人来定义、验证和负责。

合作电话：18610811242

合作微信：aqniu001

联系邮箱：bd@aqniu.com