Cursor用户栽了：100个生产级应用扫描，67%藏高危漏洞

去年有个段子在开发者群里疯传——"Cursor写代码，老板以为我请了10个外包"。现在这笑话不好笑了。有人真去查了100个用Cursor写的生产应用，67%带着关键漏洞上线，平均每个应用埋了3.2颗雷。

这不是实验室数据。扫描对象全是GitHub上的真家伙：SaaS工具、内部仪表盘、电商站点、API后端。作者通过.cursorrules文件和Cursor风格的提交记录筛选，专挑已部署的实战项目。

结果比斯坦福那篇"AI辅助代码45%含漏洞"的论文还难看。差距很好理解：学术界测的是实验环境，这次扫的是用户真金白银跑起来的业务。

43%的应用在裸奔：IDOR漏洞成重灾区

最常见的漏洞蠢到让人发笑——如果它不是真的在生产环境里的话。

Cursor生成API路由时，习惯从URL取ID直接查库返回。不加身份校验，不问"这人有没有权限看这条数据"。改个数字就能读到别人的发票：金额、付款状态、客户姓名，全暴露。

OWASP把它列为漏洞排行榜第一，修复只需一行代码：在查询条件里补上userId校验。Cursor从来不加。它的优化目标是"能跑通"，不是"谁能看"。

43%的应用栽在这个模式上。不是边缘案例，是核心数据接口。

31%把门锁反了：认证中间件的致命!号

更魔幻的是认证逻辑写反的情况。代码长这样：

if (token存在) → 踢去登录页；if (token不存在) → 放行

少了一个感叹号。if(token)变成if(!token)，整个保护机制原地反转。登录用户被赶走，没登录的访客畅通无阻。

这bug的阴险之处在于：开发者自己永远测不出来。你开着session调试，被重定向了可能还以为是缓存问题。攻击者清掉cookie进来，面对的却是完全敞开的系统。

作者说他第一次在生产环境看到这行代码时，盯着屏幕愣了30秒。

28%的SQL注入与密钥裸奔

剩下的问题清单同样刺眼。28%的应用存在SQL注入风险，不是那种需要复杂构造的边角案例，是直接拼接用户输入进查询语句。还有硬编码密钥提交到GitHub的、把数据库密码写进前端配置的、CORS设为*允许任意来源的。

这些都不是Cursor独有的问题。人类开发者同样犯错。区别在于：人类写错一次，下次可能长记性；AI每次"长记性"都需要有人在提示词里反复强调，而大多数人不会。

ShipSafe的扫描报告里有个细节：漏洞密度最高的应用有14处关键问题。作者没透露具体项目，但提到是"一个看起来挺正规的SaaS产品"，有付费用户，有完整文档，有CI/CD流程。

漏洞藏得深吗？不深。OWASP Top 10里的经典款，安全入门课的第一周内容。

Cursor的回应很标准：他们在文档里加了安全提示，建议用户审查AI生成的代码。但"建议"和"默认安全"是两回事。当工具把生成速度做到极致，审查就成了可选步骤——而可选步骤通常被跳过。

一个值得玩味的对比：同一批扫描里，手动代码审查过的Cursor项目，漏洞率降到12%。问题不在AI本身，在"AI生成=可以直接用"的心理捷径。

作者最后放了个数据点：扫描完成后他给其中12个项目的维护者发了私信，3人回复，1人修了漏洞，2人说"谢谢提醒但我们很忙"。

剩下9封邮件，已读未回。