文章总结： 作者分享因过度依赖AI生成代码导致数据库泄露的经历，揭示AI代码普遍存在SQL注入、IDOR、硬编码密钥等安全隐患，并提出人工审计、安全扫描、密钥分离等可操作建议，强调开发者需对AI生成代码的安全负责。 综合评分： 85 文章分类： 安全意识,安全开发,web安全,应用安全,实战经验

我用AI写了3年代码，直到公司数据库被脱库

原创

我有个朋友 我有个朋友

AI员工上线

2026年4月14日 19:54 广东

在小说阅读器读本章

去阅读

一、我开始用AI写代码，是因为真的太爽了

说实话，我第一次用Cursor的时候，那种震撼感我到现在还记得。

那是2022年底，我接了个小项目，要做一个用户管理系统。搁以前，这种活儿我得折腾两三天。但那天晚上，我就对着Cursor说了一句话：

“帮我写一个带登录注册的用户系统，用Node.js，MongoDB存数据。”

你猜怎么着？

10分钟，完整的代码出来了。接口、模型、路由，甚至连JWT鉴权都给我配好了。

我当时的感觉就是：卧槽，这玩意儿要改变世界。

从那以后，我的开发习惯彻底变了。不是我想偷懒，是真的太香了。写CRUD？AI来。写单元测试？AI来。连文档都能让AI生成个初稿。

我算过一笔账：以前一个功能我要写4小时，现在1小时搞定。效率提升300%，这不是开玩笑的。

而且不只我一个。

Y Combinator 2025年冬季批次里，有25%的创业公司，他们95%的代码都是AI生成的。整个圈子都在聊一个词：Vibe Coding。

啥意思？就是你不用懂底层，用自然语言描述你要什么，AI帮你搞定一切。你只要”vibe”对就行了。

听起来很美好对吧？

我也是这么想的，直到去年年底。

二、那个凌晨3点的电话

去年11月，我帮一个客户做了一个内部管理系统。就是很常见的那种：员工管理、项目追踪、数据报表。

用Cursor写的，前后端一共花了不到一周。客户很满意，上线也很顺利。

然后12月的一个凌晨，我被电话吵醒。

“出事了，数据库被拖了。”

我一下子清醒了。登录服务器一看，用户表全被导走了。邮箱、手机号、加密后的密码，还有一堆业务数据。

事后复盘的时候，我发现问题出在一个很蠢的地方。

AI给我生成的查询代码里，直接把用户输入拼进了SQL语句。没有参数化，没有预处理，赤裸裸的字符串拼接。

我后来去翻Cursor生成的其他代码，发现了更多问题：

• 有的API接口没有鉴权检查
• 有的密钥硬编码在代码里
• 有的文件上传没有类型验证

这些代码都能跑，功能都正常。但安全？基本裸奔。

我当时真的懵了。我用AI写了3年代码，从来没想过这个问题。

功能能跑，和安全能跑，是两码事。

三、这不是我一个人的遭遇

我以为是我不够仔细。后来去查资料，发现这事儿比我想象的严重得多。

2025年初，一个叫Lovable的平台出了个大新闻。

这是个很火的AI应用生成平台，口号是”用自然语言生成完整应用”。用户只需要描述需求，AI就能生成前后端代码，还能一键部署。

听起来很美好对吧？

结果CVE-2025-48757爆出来：170个应用的数据库完全暴露，用户数据任人下载。

原因是什么？

AI生成的Supabase配置，没有开启RLS（Row Level Security）。

简单说，就是 anybody 都能访问 anybody 的数据。你只要知道表名，就能把整个数据库拖走。

还有更离谱的。

Tea，一个约会应用，用AI生成了整个系统。结果呢？72,000张用户照片泄露，包括很多人的身份证自拍。

为啥？Firebase存储桶的配置是公开的，AI没给加访问控制。

还有一个叫EnrichLead的公司，纯用Cursor构建的产品。上线2天，API密钥暴露在前端代码里，被人直接薅羊毛，业务停摆。

我开始意识到，这不是偶然。

这是一个系统性的问题。

四、为什么AI代码容易有安全问题？

我后来研究了一下，发现AI生成代码的安全问题，有几个固定的模式。

我后来研究了一下，发现AI生成代码的安全问题，有几个固定的模式。

1. SQL注入回来了

你可能觉得，SQL注入这是20年前的漏洞了，现在谁还会犯？

但AI会。

因为AI是从训练数据里学代码的。训练数据里有大量历史代码，包括那些写得不好的。AI不会分辨哪些是最佳实践，它只是”生成看起来像代码的东西”。

结果就是，字符串拼接SQL这种 antique 写法，被AI原封不动地复活了。

2. IDOR漏洞遍地都是

IDOR，就是不安全的直接对象引用。简单说，就是你改个ID参数，就能访问别人的数据。

AI生成代码的时候，只管”拿到数据”，不管”谁有资格拿”。

比如一个获取用户信息的接口：

app.get('/api/user/:id', async (req, res) => {
  const user = await db.getUser(req.params.id);
  res.json(user);
});

这段代码能跑，功能也正常。但你把id从123改成124，就能看到别人的信息了。

AI不会帮你加权限检查，它默认”你要这个功能，我给你这个功能”。安全？那不是功能需求。

3. 硬编码密钥

这是最无语的。

AI生成的示例代码里，经常直接写死API密钥、数据库密码。因为它要给你一个”能直接跑”的例子，所以把配置都写死了。

你要是忘了改，直接提交到GitHub，那就是公开处刑。

Veracode去年出了一份报告：45%的AI生成代码引入了安全漏洞。CodeRabbit的数据更吓人：AI代码的安全问题比人写的多2.74倍。

这个数字背后，是无数我这样的开发者，在不知情的情况下埋下的雷。

五、那还能用AI写代码吗？

说实话，这个问题我纠结了很久。

你不用AI，效率拼不过别人。你用AI，安全风险又这么大。

后来我悟了：问题不是用不用AI，而是怎么用。

AI是个加速器，但它不是替代品。它加速的不只是你的产出，还有你的错误。

如果你不懂安全，AI会帮你生成”看起来对但实则危险”的代码，而且生成得特别快。

所以我现在有几个硬性规定：

第一，AI生成的代码，必须人工审计安全。

特别是涉及用户输入、数据库操作、文件上传的地方。每个接口都要问自己：这里有没有鉴权？参数有没有校验？会不会有注入？

第二，敏感操作必须用工具检查。

我现在每提交一次代码，都会跑一遍安全扫描。GitHub的Dependabot、Snyk、CodeQL，能上的都上。自动化的东西，不要省。

第三，密钥和配置必须分离。

AI给的示例代码，有硬编码的，一律要改成环境变量。这是基本的安全意识，但AI不会提醒你。

第四，权限检查要显式写。

不要假设”这个接口只有登录用户能访问”。AI生成的路由，很多是没有权限中间件的。你必须显式地加：auth.require(), rbac.check()。

说白了，AI帮你写代码，但安全责任还是你的。

六、写在最后

我现在还在用Cursor、Copilot这些工具。说实话，确实离不开。

但我不再盲目信任了。

AI给我的代码，我会多看一遍。特别是那些”看起来太完美”的地方，往往就是坑所在。

上周我和一个做安全的朋友聊天，他说了一句话我觉得挺对的：

“Vibe Coding的本质，是让你用未来的时间换现在的效率。你现在省下的每一分钟，可能都是将来救火时要还的。”

我不知道这是不是绝对正确。但至少，我现在写代码的时候会多想想：这段代码，3年后的自己看到会怎么想？

如果答案是会骂娘，那我现在就重写。

就这样吧。你们用AI写代码的时候，有没有踩过类似的坑？评论区聊聊。

PS：文章中提到的CVE-2025-48757等案例，均来自公开安全报告。如果你正在用AI写代码，建议去查一下OWASP Top 10，至少把基础的安全意识补上。安全这东西，不出事的时候觉得没必要，出事的时候后悔来不及。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AI员工上线 我有个朋友 我有个朋友《我用AI写了3年代码，直到公司数据库被脱库》