昨天，我的自研 GTD 系統後台突然多了 5000 多個新增賬號，actions 也陡增了 3000 多條。

第一反應當然是：難道產品突然爆火了？ 幾分鐘之後我冷靜下來：這更像是一場「惡意註冊 / 接口攻擊」，而不是增長奇蹟。

這篇文章想簡單記錄一下：

• 這次攻擊是怎麼暴露出來的
• 我是怎麼用 Claude Code 快速排查問題的
• 我對「小產品的安全邊界」的幾個反思

希望能給同樣在做小產品 / side project 的同學一點參考：就算你現在只有幾十個真用户，也值得認真對待安全和風控。

一、事情是怎麼被發現的？

先簡單説一下背景。 我用 Claude Code 搭了一套自己的 GTD 系統，名字叫 GTD Pro，靈感來自 OmniFocus，目前主要是我自己和少量真實用户在用，線上版本在這裏： https://gtd.nebulame.com/

按照正常節奏，這個系統一天新增用户只有幾個人，有時候甚至是 0。結果昨天我在後台看統計時，發現：

• 賬號總數在很短時間裏突然多了 5000+ 個
• actions 表裏多了 3000+ 條明顯無效的數據

問題在於：

• 我並沒有做任何大規模推廣
• 真實的活躍用户，其實只有幾十個

所以這波「暴漲」明顯不正常。

我簡單做了幾件事：

1. 按時間排序，發現這些賬號幾乎集中在一個很短的時間窗口內創建
2. 看標識/行為，很多請求模式非常機械、重複
3. 對比真實用户的使用行為，路徑和頻率完全不一樣

基本可以確認：這是一次針對後端 API 的「惡意註冊 + 寫入」攻擊，而不是自然增長。

二、這次攻擊到底發生了什麼？（攻擊情況一覽）

從日誌裏覆盤了一下，大概情況是這樣的：

• 攻擊開始時間：2025-12-30 00:28 左右
• 持續時間：從 00:28 一直持續到 05:07 左右

• 攻擊方式：不停地往兩個接口打請求：

  • POST /api/auth/register 註冊接口被高頻調用
  • POST /api/inbox Inbox 創建接口被高頻調用

幾小時之內，數據變成了這樣：

• 用户數：從 38 個漲到 5512 個（+5474 個惡意賬號）
• Actions：從 119 條漲到 3209 條（+3090 條無效記錄）
• 數據庫大小：從大約 400KB 漲到 12MB 左右（體積直接放大了 30 倍）

從時間分佈和請求模式看，很明顯這不是正常用户增長，而是腳本在持續轟炸註冊接口和 Inbox 接口。這裏可以放上 Claude Code 幫我整理出來的攻擊摘要和時間線截圖，我也是在它的提示下，開始給系統補上第一輪安全防護。

三、我和 Claude Code 做了一次「線上演習」

這次排查其實花的不是很多精力，更多是靠 Claude Code 幫我把問題結構化了一遍。

大概流程是這樣：

1. 我把相關的日誌片段、數據特徵、接口設計，整理成一個簡化版描述

2. 丟給 Claude Code，讓它幫我：

   • 分析可能的攻擊路徑
   • 提出優先級最高的幾條防護建議
   • Review 一下現有的註冊 / 寫入接口設計

Claude 給出的幾個方向非常實用：

• 後端 API 暴露在公網，沒有最基本的 rate limit
• 註冊和寫入接口缺少「人類門檻」，腳本可以無限請求
• 沒有給「可疑賬號」打標 / 隔離，只是直接進入正式業務表

我對照這些建議，很快做了第一輪處置：

• 給這批可疑賬號和對應 actions 打上標記，而不是直接物理刪除
• 在業務邏輯上先軟刪除：統計、報表、產品邏輯裏一律不算它們
• 開始在代碼裏補上 rate limit 和簡單風控策略

這次體驗對我來説有點意思：

• 不是「AI 幫我寫了一大堆代碼」，而是
• 「AI 幫我快速梳理威脅模型 + 設計第一版防護方案」，我自己做關鍵決策和實現細節

對一個只有幾十個真實用户的小產品來説，這種「AI + 人」的協作方式剛好合適。

四、我給 GTD 系統加了三道基礎安全鎖

這次事件之後，我給 GTD Pro 加了三道「基礎安全鎖」，也推薦給還在早期的獨立開發者：

1）給註冊和寫入接口上閘門

• 對註冊接口加簡單節流：同 IP / 同 UA / 同郵箱域名在單位時間的上限
• 對寫 actions 的接口也加上 rate limit，避免有人用單一賬號或腳本刷爆寫入

2）引入一個「人類門檻」

• 可以是郵箱驗證 / 一次性驗證碼 / 極簡驗證碼
• 不一定要很重，但要讓大規模腳本攻擊的成本變高

3）業務上把「可疑流量」和「真實用户」徹底分開

• 給這 5000 多個賬號統一打上 is_suspicious = true
• 統計和報表默認只看「未標記為可疑」的賬號
• 以後如果還有類似事件，可以快速對比行為模式、複用處理流程

這次攻擊也間接幫我確立了一個心態：

• 只要你的產品暴露在公網，就默認會被掃、被撞、被試探
• 安全不是「有大公司再做」，而是「你第一次被攻擊的那天，就該開始認真設計」

五、小產品也要有安全邊界

這次惡意註冊事件，對我最大的提醒是：

• 就算你現在只有幾十個真實用户，也應該早點想好：

  • 註冊/登錄的邊界
  • 寫入數據的節流
  • 垃圾數據的隔離策略

• AI 不只是用來給用户做「炫酷功能」，也可以拿來幫你做基礎設施：

  • 設計威脅模型
  • 幫你 review 代碼
  • 幫你想「最小代價的安全升級」

嚴格來説，這次並不能算一場「大規模攻擊」，更像是給我提了個醒：

• 我的 GTD 不再只是本地小玩具
• 它開始作為一個真正對外的在線服務存在

六、如果你也想試試這套 GTD / 看看代碼

最後，留兩個入口：

• 線上版本（我自己每天在用的那套）：https://gtd.nebulame.com/
• 開源版本代碼倉庫（功能少於線上版，主要用來參考架構和實現）：https://github.com/femto/gtd

如果你也在做自己的小工具、小產品，建議不要等到「出事了」再補安全。哪怕只是在註冊接口前面多加幾行簡單的 rate limit 邏輯，都是一個好的開始。

也歡迎你來試試 GTD Pro，或者在 issue 裏告訴我你遇到的安全/風控問題，我們可以一起繼續把這套系統打磨得更像一個真正可依賴的「第二大腦」。

如果你對我在做的通用 Agent 框架也感興趣，可以看看：

• minion-agent（實戰框架，支持瀏覽器、MCP、deep research 等）：https://github.com/femto/minion-agent
• Minion（Agent 大腦 / 推理內核）：https://github.com/femto/minion

GTD Pro 目前主要跑在 Claude Code 上，後面也會逐步和這套 Agent 基礎設施打通。