Lazy PageSpeed 開發筆記

你會因為每天都看到一堆 AI 相關的工具或資訊而感到焦慮嗎? 害怕錯過了其中一種就落後別人，其實那些大部份都是雜訊沒看到反而更好，越是強調自動化的東西就越是局限，大大限制了能發揮的更大潛能，比如說你要買一組設計好的樂高還是要買散裝的? 如果你沒想法就買設計好的，但當你完成了之後，那然後呢? 再接著換下一組，一直重複一樣的流程? 還是就不再玩樂高了?

在快要完成 Lazy PageSpeed 專案之前，用 Claude 的 Sub Agent 做了資安審計時發現了一個嚴重的問題，那是當初我把構想給 AI 產生的功能，但在審查時才發現原來問題的嚴重性，然後 AI 針對建議的措施怎麼問都是那幾種通用的方式，雖然我不會寫程式，但還是讓我覺得這傢伙根本在胡說，為了解決問題，我不得不自己在腦中不停的演練原本的流程到底是什麼問題，要怎麼更改架構才能完全斷絕問題。

以下就是過程還原:

原本的架構(基本模式)：

1. 前端 → CF Workers /api/analyze → CF Workers 呼叫 Google API → 回傳報告給前端
2. 前端壓縮報告 → 上傳到 CF Workers /api/upload-report → CF Workers 存到 CF R2

資安審計發現的問題：

- 前端僅透過 new URL() 驗證格式，未限制協議(javascript:、data: 等仍可通過)，也沒有私有 IP 或保留區段檢查，容易成為 XSS 和 SSRF 入口
- Cloudflare Workers 在 validateShareRequest 完全未檢查 URL 格式與協議；分享功能模組只在提取 hostname 時使用 new URL()，無效網址會被靜默跳過，不會阻擋惡意輸入
- 分享流程最終會依據這些值讀寫 CF KV 和 CF R2，若被植入惡意協議或內網位址，會造成資料污染甚至被濫用當代理
- /api/upload-report 端點無存取控制，任何人可直接呼叫上傳偽造的報告

Claude 的建議：

1. 在 CF Workers 的 Validators 實作嚴格的 validateUrl：僅允許 http/https，並阻擋私有 IP、localhost、0.0.0.0、127.0.0.0/8 等
2. validateShareRequest 逐一檢查 body.urls，若不合法直接回傳 400
3. 前端 isValidURL 同步比照限制，維持使用者體驗
4. 分享功能模組對非法網址應直接拒絕請求，而不是靜默跳過

但以上建議只能解決 SSRF 攻擊，問了好幾次都無法解決偽造問題，所以我決定只能透過重構整個儲存架構來根本解決。

重構後的架構：

1. 前端 → CF Workers /api/analyze → CF Workers 呼叫 Google API → CF Workers 壓縮報告 → CF Workers 存到 CF R2 → 回傳 reportId
2. 移除 /api/upload-report 端點

關鍵改變：

- CF Workers 呼叫 API 後不再交給前端處理，而是自己完成壓縮和儲存
- 前端完全無法介入報告內容和上傳流程

經驗與反思：專注於理解原理和基礎能力，而非追逐每個新工具
AI 能夠快速針對現況問題給予通用的建議 (加驗證、加限制、加防護)，但卻沒辦法用全局觀的方式來思考整個架構的缺失。Claude 看到的是 URL 沒驗證，但他沒辦法延伸思考是上傳流程本身就有問題。所以目前儘管有 AI 協助，但最終還是需要自己的判斷，才能看清問題的本質，重構上傳的功能約花了一天時間處理，也是這個專案卡關最久的部份。

—

Lazy PageSpeed 相關連結:
網址：[前往]
使用文件: [前往]
GitHub：[前往]
Claude 對分析報告的整理總結範例: [前往]
使用上有問題的話，歡迎到社團交流： [前往]