大家好，我是孟健。
上周六下午，我收到一封邮件。
标题很直白："你的东西泄露了，兄弟"。
邮件里附了一个暗网论坛链接，声称我的网站 kirkify.net 的数据库已经被公开下载。
▲ 就是这封邮件。发件人 punker，链接指向暗网论坛的数据库下载帖
我打开后台一看------
case_studies 表：227 万条记录。
而前一天，这张表只有 259 条。
从下午 3 点 25 分开始，持续了整整 6 个半小时 ，有人往我的数据库里灌了 227 万条垃圾数据。
数据分布极其均匀：763K approved、763K pending、764K rejected。攻击者用 FloodUser_XXXXX 的命名模式批量写入，每条 caption 填充 1KB 的 base64 随机数据------这不是随机攻击，是有计划的数据库膨胀攻击。
▲ 我的 AI Agent 墨码发现数据异常后的应急分析，第一时间定位到了漏洞
漏洞在哪？一个没有门锁的 API
▲ kirkify.net------我用 AI 编程工具做的出海小产品，用 Cursor + Claude 几天搭好就上线了
问题出在一个叫 submitCaseStudy 的 Next.js Server Action 上。
这段代码有 五个致命问题叠在一起：
① Server Action 暴露为 HTTP POST 端点
Next.js 的 Server Action 虽然在服务端执行，但本质上就是一个 HTTP POST 接口。任何人都可以直接构造请求调用，完全不需要前端页面。
② 无认证（No Authentication）
函数体内没有任何 session / auth 验证。谁都能调，无门槛。
③ 无 Rate Limit
没有任何频率限制。攻击者写个循环脚本，每秒能提交几百条。
④ 自动审核通过（Auto-Approve）
代码里 status: 'approved' 硬编码，提交即上线。垃圾内容直接出现在 Gallery 页面，不需要任何审核。
⑤ 用 Service Role Key 绕过数据库安全
代码用 Supabase 的 service_role key 操作数据库，完全绕过了行级安全策略（RLS）。虽然数据库开了 RLS，但 service_role 拥有 God Mode 权限，安全策略形同虚设。
五个漏洞叠加的效果：你家大门敞开，没有保安，没有门禁，来者自动发 VIP 卡。
而这段代码，恰恰是 AI 帮我写的。
当初我对 Cursor 说："帮我写一个提交案例的功能"。AI 很快给出了代码------功能完整、类型正确、能跑。但完全没有考虑安全性。
而我看到代码能跑，就直接部署了。
这不是个例
▲ Veracode 2025 报告：测试 100+ 个 AI 模型，45% 的代码引入了安全漏洞
数据印证了这一点：
- Veracode 报告 ：分析 100+ 个 LLM 生成的代码样本，45% 存在安全漏洞，引入了 OWASP Top 10 安全问题
- Apiiro 研究 ：截至 2025 年 6 月，AI 生成代码每月引入 超过 10,000 个新安全问题，六个月增长 10 倍
- 常见漏洞类型：缺乏认证、硬编码密钥、SQL 注入、缺少输入校验、未配置 Rate Limit
AI 很擅长写"能跑的代码"，但它默认不会帮你加认证、加限速、配安全策略。
除非你明确要求它这么做。
修复过程：一天迁移整个数据库
发现问题后，我和 AI Agent 墨码立刻开始修复。
第一步：堵住入口
- 关闭
submitCaseStudy的公开访问 - 给所有写入 API 加上 JWT 认证 + Rate Limit
第二步：全面安全审计
- 审查所有 Server Action 的认证状态
- 检查 Supabase RLS 配置------发现 case_studies 表虽然开了 RLS，但只有一条 SELECT 策略，没有 INSERT 策略。而代码用 service_role key 绕过了全部 RLS
- 检查 billing_customers、credit_balances 等敏感表------确认未被攻击者访问，攻击者只能通过 Server Action 写入 case_studies 表
第三步：数据库迁移（关键决策）
- 没有选择在原数据库上修补，而是直接把整个数据库从 Supabase 迁移到 Cloudflare D1
- 迁移 12 张表，只导入 261 条干净数据（260 条 approved + 1 条 pending），227 万条垃圾数据直接抛弃
- D1 版本完全重写了数据访问层，用 JWT 认证，不再有裸露的 Server Action
- 同步完成 CF Workers 部署，DNS 切换上线
第四步：服务器加固
- fail2ban 收紧（3 次失败封 24 小时）
- VNC 绑定内网 IP
- 环境变量文件权限改为 600
- 泄露的 API Key 全部轮换
从发现到完成数据库迁移和上线切换，总共花了约一天。
给用 AI 编程的你：写完代码多问一句
这次教训让我养成了一个习惯：
每次 AI 帮我写完一个功能，我都会追加一句：
"这段代码有什么安全隐患？帮我加上认证、Rate Limit 和输入校验。"
就这一句话，能避免 80% 的安全问题。
再具体一点，每次上线前检查这 5 件事：
1. API 端点有没有裸奔？ 不需要认证就能访问的写入 API = 等着被刷。特别注意 Next.js Server Action------它本质是 HTTP POST，不是"服务端函数"。
2. API Key 有没有硬编码在代码里？ 检查 .env 文件权限，确保 Key 不在 Git 仓库里，更不要出现在聊天记录里。
3. 数据库有没有正确配置权限？ 用 Supabase 就开 RLS + 写好策略。用 service_role key 要极其谨慎------它能绕过一切安全策略。
4. 有没有 Rate Limit？ 没有限速的 API，就是一个等着被刷的 API。
5. 有没有监控异常？ 数据量突增、请求量突增------这些信号需要有人盯着。
用 OpenClaw 的朋友，多留个心眼
最近 OpenClaw 火了（GitHub 21 万星），越来越多人在自己的服务器上跑 AI Agent。
OpenClaw 本身的安全性很好------沙箱隔离、权限分级、Token 加密存储，这些基础设施层面做得扎实。但你用 OpenClaw 搭建的应用和服务，安全性取决于你自己。
这次被攻击之后，我把自己服务器上的安全配置全过了一遍，总结了几条实用建议：
1. .env 文件权限改 600
你的 OpenClaw 配置文件和环境变量里存着所有 API Key。运行 chmod 600 ~/.openclaw/*.json 和 chmod 600 .env，只允许当前用户读写。
2. 不要在聊天里发明文 Key
我这次就踩了这个坑------在 Telegram 里给 Agent 发了 Replicate API Key，结果被记录到了几十个文件里。正确做法是直接写进 .env 或用 openclaw config 设置。
3. 远程访问绑内网
如果你在服务器上跑 VNC、远程桌面或调试端口，一定绑到内网 IP 或 Tailscale 网络，不要暴露在公网。我之前 VNC 绑了 0.0.0.0，相当于全世界都能连。
4. 开 fail2ban
SSH 暴力破解是最常见的攻击手段。apt install fail2ban 一行命令，建议配置 3 次失败封 24 小时。
5. Agent 不要用 root 跑
给 OpenClaw 创建专用用户，限制文件系统访问范围。万一 Agent 被诱导执行恶意命令，损害范围可控。
6. 定期检查开放端口
运行 ss -tlnp 看看你的服务器对外暴露了哪些端口。数据库端口（5432、3306）、调试端口（9229、18800）绝对不应该对公网开放。
OpenClaw 给了你 10 倍的生产力，也意味着 10 倍的攻击面。Agent 能帮你写代码、调接口、操作数据库------如果权限没控好，攻击者也能通过 Agent 做这些事。
AI 编程让我们 10 倍速出活，但也让安全债务 10 倍速累积。
代码能跑，不代表代码安全。
希望你不用像我一样，等到收到黑客邮件那天才明白这个道理。
你用 AI 写代码时踩过安全的坑吗？评论区聊聊，我来回。