前端的資料，真的保護得了嗎？一個誠實的說明

台灣百岳地圖上的山岳資料，不是放在網站的靜態檔案裡，而是透過一支後端 API 提供。有人問過我：這樣是不是就保護了資料？我的答案是：只保護了一部分，而且要誠實說清楚是哪一部分。

這樣做有什麼效果

如果把資料做成一個靜態檔案，例如 peaks.json，它會有固定的網址。任何人輸入網址就能下載，搜尋引擎也可能把它收錄，爬蟲程式更是隨手就能抓走。

改成透過 API 提供之後：

只要地圖需要顯示這些資料，瀏覽器就一定會收到完整的內容。打開開發者工具的「網路」分頁，看得到 API 回傳的完整 JSON。這是前端網站的物理限制：凡是要顯示給使用者的資料，使用者的瀏覽器就必然拿得到。

所以這個做法提高的是「隨手複製」的門檻，而不是做到「真正無法取得」。我在專案的說明裡也是這麼寫的，沒有把它說成資料保護。

常有人建議：前端把資料加密，需要時再解密。但解密的金鑰也得放在前端，否則瀏覽器無法解密。金鑰一旦在前端，任何人都能取得，加密就只是增加閱讀的麻煩，並不能擋住有心人。

真正能保護資料的做法只有一種：不把它送到瀏覽器。 也就是資料留在伺服器，只回傳使用者「當下被授權看到」的那一小部分，並且在伺服器端做權限判斷。

我把資料分成兩類來處理：

公開資料（例如山岳的名稱、海拔、位置）：這些來自公開來源，本來就不是機密。透過 API 提供只是方便維護，也順便擋掉最輕易的複製，不需要過度防護。

需要保護的資料：例如付費功能的內容、使用者的紀錄。這些一定放在伺服器端，經過登入與權限判斷才回傳，沒有權限就什麼都不給。前端的畫面只決定要不要顯示按鈕，真正的關卡永遠在後端。

API 只要對外開放，就要考慮被濫用的情況。我會限制可以呼叫它的來源網域，並且對請求量做限制，避免有人用程式大量打。這些措施的目的，是避免服務被拖垮，而不是為了鎖住資料。

做產品決策時，先想清楚這份資料屬於哪一類。如果它是機密，就不能依賴前端的任何手段；如果它本來就公開，就不必假裝它受到了保護，也不要為此付出過度的成本。

誠實說明資料保護的真實程度，不只是技術上的正確，也是對使用者的尊重。他們有權知道，哪些東西是真的被保護，哪些只是不那麼容易被拿走。