AIDive開場:先對準自己
在別人把你的 App 拆開之前,先自己拿 REA 對準它。我們從一個一次性的雲端沙盒出發,把 REA 對準我們自己的線上網站,修掉它找到的問題,最後送出 pull request。
REA 是一個逆向工程 skill,一大波影片都把它對準別人的軟體。在我們的網站上,它花不到十三分鐘,而且一個寫入請求都沒送,就證明了任何網站都能填滿我們的電子報名單。它還發現我們留言機器人的每日上限,就躺在你從我們網站下載的 JavaScript 裡。修好之後,以前能溜過去的那個請求會被拒絕。
成果是六條規則,讓你用同樣的方式審查自己的 App:一次性沙盒、確切的目標、替發現分類、bundle 裡的設定、端點的煞車,以及證明修復有效。
REA 是什麼,以及如何安裝
REA 是 Reverse Engineer Anything 的縮寫,是一組讓 Claude Code 拆解你所發布 App 的工具。逆向工程是指從成品推斷出它是怎麼做的,就像技師在沒有原廠圖面的情況下讀懂一輛車。
它不讀你的原始碼,而是讀 bundle,也就是你的網站實際送給每位訪客的 JavaScript。它會從 bundle 裡列出路由、你的頁面呼叫的端點,以及你不小心留在裡面的東西。它無法把原始碼還給你,你拿到的只有證據,而且它自己的文件也說它不是沙盒。
安裝方式如下:
- 從官方套件安裝 REA 並固定版本,因為它一週內發了六個版本。
- 執行它為 Claude Code 準備的 setup。
- 開啟精簡 profile,因為它會把一百多個工具載入你的 session。
- 只從官方 repo 安裝,因為夾帶惡意程式的假冒副本已經流傳過。
我們在沙盒裡執行安裝時,agent 動手之前先確認套件指向的是官方 repo。接著 setup 只安裝了 skill,沒有安裝工具伺服器,所以 Claude Code 直接改用 REA 同樣工具的命令列版本。如果 setup 之後看不到工具,你不需要重新啟動任何東西:直接在終端機呼叫同樣的步驟就好。
規則 1:在傷不到你的地方執行
第一條規則談的是在哪裡執行。你即將讓一個 agent 操控瀏覽器,並對你的正式環境 App 執行下載來的工具。在你的筆電上,那個 agent 就坐在你的金鑰、其他專案和所有已登入帳號旁邊。REA 自己的安全說明講得很直接:這不是沙盒。
沙盒是一台用完即丟的機器,出了任何狀況都留在裡面,你把它刪掉就好。在你的 repo 上開一個一次性沙盒,整個審查都在那裡跑,絕不要在你自己的機器上。
我們用的是 Kosuke,它在一台用完即丟的雲端機器裡,以你自己的訂閱執行 Claude Code。你選好 repo,告訴部署 agent 你的 App 怎麼啟動,它就給你一個預覽,也就是你執行中的 App 出現的連結。每個對話還會有自己的分支,也就是程式碼的專屬副本,並以 pull request 收尾。我們匯入網站時,agent 自己安裝了套件管理器和無頭瀏覽器,量了記憶體,並挑好機器規格。幾分鐘後,我們的真實網站就在對話旁邊跑了起來,跑在一條沒人會碰的分支上。
先前測試時有一個陷阱:新的 Next.js App 出現在預覽裡,但頁面上什麼都沒有反應。解法是在你的 Next 設定裡加一行,允許預覽的網址,頁面就活了。
限制是,這仍是同一個 Claude Code,只是外面加了一個箱子,所以本機虛擬機或容器也能做同樣的事。重要的是箱子,不是品牌。
揭露:Kosuke 讓我們免費使用其最高階方案。註冊後立刻在「Promo code」欄位輸入優惠碼 AIDIVE2026,就能拿到 30 美元的額度,而不是平常的 10 美元。
規則 2:只給一個確切網址,封鎖所有寫入
第二條規則是你實際對 REA 說什麼。如果你只說「幫我審查我的 App」,REA 的 skill 會停下來問你是哪個 App。
REA 也從不自己開瀏覽器,所以你要自己啟動一個帶除錯埠的瀏覽器。除錯埠是一扇門,讓工具能看到頁面做的每一件事。請依這個順序設定:
- 讓除錯埠只綁在 loopback,也就是只有你自己的機器連得到的位址,並給瀏覽器一個全新的 profile。
- 在任何頁面載入之前,先封鎖所有寫入請求,這樣審查可以讀你的網站,卻不能送出表單或改動任何東西。
- 然後才把你要它讀的確切頁面交給 REA。
在我們的 prompt 裡,我們點名了免費社群的兩個頁面,並用白話寫下一條規則:絕不對線上網站送出寫入。這很重要,因為那些頁面上的表單連著一份真實的電子報名單,名單上都是真人。agent 把這條規則當真,自己寫了一個小守衛:放行讀取,擋下其他一切。審查期間,這個守衛擋下了分析腳本的六次嘗試,而且沒有任何一個請求送到我們的訂閱表單。
接著 REA 做了它該做的事:檢查每個頁面、讀取每個 bundle、截圖,並把腳本匯出到 repo 之外。
限制是,REA 只看得到它連上期間載入的東西,所以在那之前發生的事,在報告裡仍是未知。即便如此,你現在手上有一份關於你線上 App 的報告,而且完全沒有碰到它的任何資料。
規則 3:先分類每項發現,再修
第三條規則是先分類再修。這樣的報告裡滿是嚇人的條目,你會想一次全修掉。
REA 自己的 skill 要求每個結論都標成觀察、推論或未知,並附上證據 ID。也就是它看到什麼、猜了什麼、看不到什麼,而證據 ID 是你可以查驗的收據。先只用外部人的視角把每項發現這樣分類,並在打開任何一個原始碼檔案之前就 commit 那個版本。然後再讀你的原始碼,把每一行標成真正的洩漏、刻意的設計,或誤報。
我們的報告有十五項發現:
| 發現 | REA 看到什麼 | 我們的判定 |
|---|---|---|
| 訂閱端點 | 沒有限制,也沒有檢查是哪個網站在呼叫,所以任何網站都能讓訪客的瀏覽器把任意信箱訂閱到我們的名單 | 真正的洩漏,最嚴重 |
| 免費資源包的 email 門檻 | 整個資源包早已在你載入的頁面裡;在瀏覽器主控台打一行就能移除門檻,或用閱讀模式就能看到文字 | 刻意的設計 |
| Source map、金鑰、cookie | bundle 裡都沒有,到處都沒有 cookie | 好消息 |
門檻是刻意的設計,因為資源包本來就是故意免費的,而且我們自己的程式碼就寫明,壞掉的表單絕不能把免費頁面藏起來。
限制在於未知那一欄。REA 看不到你的伺服器做了什麼,所以這些行要靠讀你的伺服器程式碼來定案。
規則 4:你的 bundle 會帶著你的設定
第四條規則談的是你的 bundle 帶了什麼,因為一個共用的設定檔可能在你沒注意時就送給每位訪客。
過程是這樣的:你在一個 helper 裡匯入設定,兩個小型互動元件用了這個 helper。bundler 是把你的程式碼打包成瀏覽器下載檔案的工具,它分不出這兩個元件需要哪些 key,於是全部送出。
這正是 REA 在我們的 JavaScript 裡找到的。我們整份網站設定躺在一個檔案裡,包括電子報名單 ID、建置資料夾,以及回覆我們影片留言的機器人的限制。裡面甚至寫了這個機器人一天發多少則回覆,一百則,還有出幾次錯會觸發它的安全開關。而拉進這份設定的那兩個元件,其實只讀網站名稱和語言清單。
規則是:在你送出的 JavaScript 裡搜尋你自己的設定 key,並且只給用戶端元件它們實際會讀的欄位。在我們的沙盒裡,agent 把設定拆成一個只含那些欄位的微型瀏覽器版本,其餘留在伺服器。它還加了一個建置步驟,只要伺服器端的 key 再度出現在任何送出的檔案裡,建置就會失敗,讓你不會倒退。
這些都不是密碼,但那個檔案裡的任何東西都是公開的,所以你的機密只該放在伺服器變數裡。
規則 5:每個開放端點都要有煞車
第五條規則修掉了我們真正的洩漏,而且只要你有呼叫付費服務的公開表單就適用:你的電子報名單、你的 AI 模型,或是簡訊閘道。你透過一個花一個下午寫成的小型伺服器函式去呼叫它。我們的函式接收一個 email,直接轉給電子報服務,而任何其他網站都能讓訪客的瀏覽器對它送出請求。
資安界自己的清單講得很直接:你的存取控制只有在攻擊者改不了的程式碼裡才有效,也就是你的伺服器。所以每個這樣的端點都要加上煞車:
- Origin 檢查。 Origin 標頭是瀏覽器蓋在請求上的印章,標明是哪個網站送來的,所以來自其他網站的表單會被拒絕。
- 速率限制。 限制單一訪客在短時間內能送出多少請求。
- 在伺服器檢查同意。 你勾選的那個框,確實隨著請求一起送來。
在我們的沙盒裡,agent 把這三項都寫進了我們的 Worker,也就是訪客造訪時在你的頁面前面執行的小函式。然後它拿假的電子報服務去測試,從沒碰過真的,結果每個請求都在該被拒絕的地方被拒絕。從錯的網站送出,被拒絕。一分鐘內的第六個請求,也被拒絕。沒有同意,則被駁回。
限制是,腳本可以偽造 Origin 印章,而速率限制是依地點計算,所以真正的解法是 email 雙重確認。
規則 6:重跑、手動檢查、送出 PR
第六條也是最後一條規則,是證明修復有效,因為整排綠色勾勾正是你停止細看的時候。一位在桌面 App 上測試 REA 的開發者在 HackerNoon 上寫道,它漏掉了該 App 確實有的進入點。
所以用同樣的 REA 步驟對修好的版本再跑一次,從終端機親手檢查每一項修復,然後才開 pull request。
在修好的版本上,以前能溜過我們訂閱表單的那個請求會被拒絕。伺服器的 key 從每個送出的檔案裡消失了,安全標頭也到位了,Worker 的測試從失敗變成通過。免費資源包的門檻仍然開著,那是我們決定的,而報告在每一行旁邊都這樣寫明。
接著 agent 開了 pull request。報告會在裡面,只是因為我們在 prompt 裡要求。Kosuke 產生的測試清單留在 session 內,pull request 本身沒有貼出任何東西。如果你的審查者只看 GitHub,請自己把修復前後的報告放進 pull request。
之後我們把同一份變更帶進自己的程式碼,它會隨下一次網站部署上線。
結論:何時該把 REA 對準自己
整個過程是:從一個一次性沙盒把 REA 對準我們自己的線上網站,每項發現都分類、真正的洩漏都修好、再審查一次,最後以 pull request 送出。讓這一切值得的,是第一個發現:任何網站都能用任何人的信箱填滿我們的訂閱表單。
在你發布任何帶有公開表單或付費服務的東西之前,先跑這個審查,之後每次改動送出內容時再跑一次。不要對你不擁有的軟體跑,因為 REA 自己的免責聲明把它限定在你擁有或獲授權檢查的軟體。它也絕不能取代閱讀你的伺服器程式碼,因為未知恰恰就在那裡。
如果你只記住一條規則,就記這條:對自己跑,在箱子裡跑,只修你分類過的。
確切的 prompt、分類表,以及我們送出的 Worker 修復,都在這支影片的免費資源包裡。
