自建圖床看起來只是「把圖片放上去、產生一條連結」，實際上卻同時碰到檔案上傳、遠端抓取、管理員登入、API 權限與個資外洩等問題。即使系統已加入限流、SSRF 防護和路徑隔離，也不能因此認為它是絕對安全；安全性往往取決於伺服器設定、更新習慣，以及管理者有沒有真正落實權限控管。
檔案上傳不只是容量問題
拖曳上傳、Ctrl+V、URL 拉圖和 ZIP 批量解壓都很方便，但每多一種入口，就多一條可能被利用的攻擊路徑。若只檢查副檔名，攻擊者可能上傳偽裝成 JPG 的 PHP、SVG 或含有惡意腳本的檔案。特別是 ZIP 解壓功能，除了檔案數量限制，也要防範 Zip Slip，避免壓縮檔內的 ../ 路徑覆蓋網站程式或設定檔。
圖片處理同樣不能掉以輕心。WebP、JPEG 轉換通常依賴 ImageMagick、GD 或其他函式庫，過往曾出現圖片解析漏洞。建議限制檔案大小與像素總量，重新編碼後再儲存，並讓上傳目錄完全不能執行腳本。
URL 上傳與遠端儲存的風險
系統雖然禁止內網位址和跳轉，仍應持續檢查 DNS 解析結果，因為攻擊者可能利用 DNS rebinding 或特殊 IPv6 表示法繞過 SSRF 規則。若遠端 API 使用固定金鑰，金鑰一旦出現在錯誤訊息、日誌或備份檔中，攻擊者就可能直接刪除或大量寫入遠端儲存。
Cloudflare R2、Telegram 等第三方服務也不是天然安全。公開桶設定錯誤、權杖權限過大，甚至 CDN 快取了原本應受保護的圖片，都可能造成資料外洩。加密圖片最好採用限時簽名網址，而不是只依賴前端輸入密碼。
管理後台與 API 是高價值目標
/admin/ 和 /api/v1.php 若暴露在網際網路上，會持續遭遇密碼嘗試、ID 枚舉和自動化濫用。每五分鐘限制八次登入是基本防線，還應啟用多因素驗證、記錄異常 IP，並避免 API 只靠檔名或連續 ID 查詢資料。管理員密碼也不應沿用預設值；一旦後台被登入，刪除圖片、竄改公告，甚至替換頁腳 HTML，後果往往比單純圖片外洩更嚴重。
真正容易被忽略的細節
SHA-256 去重可能暴露「某張圖片是否已存在」的資訊，公開發現頁和圖片搜尋也可能讓圖片 ID、檔名逐步被枚舉。另一方面，SQLite、錯誤日誌、備份檔與遠端 API 設定若未排除在 Web 根目錄之外，防住 storage/ 仍然不夠。
自建圖床不是不能用，而是要把它當成一個小型檔案服務來維護：定期更新依賴、檢查備份權限、監控流量與儲存異常，並對公開、私密和管理資料分開設計。便利功能可以慢慢加，安全底線卻不適合事後補。
評論（4）
以前只想到空間夠不夠，沒想過上傳路徑會有這麼多漏洞
Zip Slip 這個點真的很容易被忽略，得趕快檢查一下設定
想問如果用 Cloudflare R2 搭配簽名網址，安全性會提升很多嗎？
果然便利跟安全很難兼顧，還是得定期更新依賴才行