靜態網站想加密碼，用公司統編當通行碼安全嗎？不安全，那是門簾不是鎖

起因：我想給網站的私密區加一道門

我的網站有兩種內容：一種是公開給大家看的，另一種只想給特定的人看。我想替後者加一道權限。我自己先想到一招，還覺得挺聰明的。

我的提問：多一道權限管理，比方說輸入公司統編才能看到，你覺得呢？

我跟 Claude 說：那塊私密內容，能不能讓人「輸入公司統編」才看得到？感覺多一道關卡就安全了。

Claude 的回答：在純靜態網站上，那不是「鎖」，是「門簾」

Claude 沒有附和，反而先講了一個我從沒想過的殘酷事實，而且點出兩個致命問題：

1. 純靜態網站，內容早就下載到瀏覽器了。 用 JavaScript 檢查密碼，等於「先把全部給你、再假裝用一塊布遮住」。按右鍵「檢視原始碼」、或乾脆把 JavaScript 關掉，被遮住的內容原原本本都在。這種鎖，等於沒鎖。
2. 更糟的是，統編就印在那一頁上。 而且公司統編本來就是公開、可被查詢的資訊。拿一個「印在門牌上、誰都查得到的號碼」當鑰匙——等於門牌號碼就是鑰匙，這道門形同為所有人而開。

一句話：客戶端的密碼檢查，保護力是零；而秘密，不能是公開資訊。

我的提問：那要怎麼鎖，才是真的鎖？

既然前端假鎖沒用，我接著問：真正有效的做法長什麼樣？

Claude 的回答：真鎖在伺服器端——沒驗證通過，內容根本不送出去

關鍵差別只有一句：假鎖是「內容先送、再遮」，真鎖是「沒過關，內容連送都不送」。

Claude 用 Cloudflare 的 Functions 當「守門員」：

• 請求一進來，先驗身分（cookie）。沒登入，就只回一個登入頁，連私密內容的影子都拿不到。
• 密碼放在環境變數裡，不寫進程式碼、也不進 git。輸對了，才發一張「簽章過、偽造不來」的通行證（cookie）。
• 而且預設是 fail-closed：萬一哪天忘了設密碼，系統一律「擋住」，而不是不小心「全公開」。出錯時，往安全的那一邊倒。

我這才懂「真鎖 vs 假鎖」的分水嶺，不在於畫面上有沒有密碼框，而在於：該保護的東西，到底有沒有真的離開過伺服器。

我的提問：你是全站上鎖，還是分網址上鎖？

我有點擔心：那我公開給大家看的那塊，會不會也被一起鎖住了？

Claude 的回答：分網址上鎖，公開區完全不受影響

守門員放在哪個資料夾，就只管那個路徑底下的網址。所以公開的那塊照常開放，只有私密區那條路徑要密碼。一個網站、兩種待遇，井水不犯河水。

我學到的

• 純靜態網站的「前端密碼」是假鎖。 內容已經在使用者的電腦裡，藏不住——任何「用 JavaScript 遮一遮」的東西，看原始碼就破功。
• 秘密不能用公開資訊當。 統編、電話、生日、員工編號……這些查得到的東西，都不配當密碼。門牌不能當鑰匙。
• 真正的存取控制必須在伺服器端。 判準很簡單：沒通過驗證，內容是不是「連送都沒送出去」？是，才是真鎖。
• 預設要 fail-closed。 安全機制出錯時，要往「擋住」倒，不是往「打開」倒。「忘了設密碼結果全公開」，是最常見、也最痛的意外。
• 一個 meta 收穫：「看起來安全」和「真的安全」是兩回事，就像那張錯視畫——再逼真的立體感，也只是一層平面的油彩。資安最怕的，就是把門簾當成了鎖。

---

延伸閱讀：這篇和它是同一段實作的一體兩面。一個問「怎麼把私密區鎖起來」，另一個問「怎麼知道資源被用多少」——想知道網站每頁被看幾次，該用 GA4 嗎？