我的网站被黑了：一天灌入 227 万条垃圾数据，AI 写的代码差点让我社死

大家好，我是孟健。

上周六下午，我收到一封邮件。

标题很直白："你的东西泄露了，兄弟"。

邮件里附了一个暗网论坛链接，声称我的网站 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 写代码时踩过安全的坑吗？评论区聊聊，我来回。