Cloudflare Access JWT 安全性與 iframe 同源政策解析

前言

在替部落格實作私密文章功能時，我選擇了 Cloudflare Access 作為保護層。設定完成後，自然會想到一個問題：這個保護機制真的安全嗎？ 於是開始深入研究 JWT 的安全性、cookie 被竊取的風險，以及一直以來對 iframe 的安全疑慮。

這篇文章記錄了這些探索的過程和結論。

Cloudflare Access 的 JWT 機制

Cloudflare Access 驗證通過後，會在瀏覽器設定一個名為 CF_Authorization 的 cookie，裡面存放的是一個 JWT（JSON Web Token）。

JWT 裡存了什麼

欄位	說明
sub	你的 email（驗證身份）
aud	Application ID（對應哪個 Access Application）
iat	簽發時間
exp	過期時間
iss	簽發者（Cloudflare Access）
nonce	防重放攻擊的隨機值

每次請求 /private/* 路徑時，Cloudflare 邊緣節點會檢查這個 cookie 裡的 JWT 是否有效且未過期，通過才放行。

JWT 能被變造嗎

幾乎不可能。 原因：

JWT 使用 RS256（RSA 非對稱加密） 簽名，私鑰只存在 Cloudflare 伺服器端
攻擊者即使拿到 cookie 內容，沒有私鑰就無法偽造有效簽名
Cloudflare 會在邊緣節點用公鑰驗簽，任何篡改都會被拒絕

簡單說：你可以「看到」JWT 的內容，但無法「改動」它。就像你可以看到一張支票的金額，但沒有銀行的印章就無法偽造。

真正的風險在哪裡

JWT 本身的加密機制足夠安全，但實際的攻擊面在其他地方：

如果攻擊者能在你的網頁中注入惡意 JavaScript，就能讀取 CF_Authorization cookie 並在過期前冒充你。

但對純靜態站來說，這個風險極低。 靜態站沒有使用者輸入、沒有動態內容渲染，根本沒有注入惡意 JS 的入口。

2. Email 帳號被入侵

攻擊者如果控制了你的 email，就能直接通過 OTP 驗證。這是最大的風險，但已經超出網站安全的範疇，屬於個人帳號安全的問題。

靜態站的 XSS 風險分析

XSS（跨站腳本攻擊）是指攻擊者在網頁中注入惡意 JavaScript。常見的攻擊場景是留言板沒有過濾輸入，有人貼了一段 <script> 偷取 cookie。

靜態站天然免疫大部分 XSS 攻擊，因為：

所有 HTML 在建置時就已經產生，不會根據使用者輸入動態渲染
沒有伺服器端接收使用者輸入並嵌入頁面的流程
頁面內容固定，攻擊者無法透過 URL 參數注入腳本

iframe 安全性迷思

「iframe 不安全」是一個常見的誤解，但真相更加細緻。

iframe 真正的風險

風險一：你的網站被別人用 iframe 嵌入（Clickjacking）

攻擊者在自己的網站用 iframe 嵌入你的頁面，上面疊一層透明按鈕，誘騙使用者點擊。防禦方式是設定 X-Frame-Options 或 Content-Security-Policy header 禁止被嵌入。

風險二：你嵌入了不可信的 iframe

如果嵌入的是惡意網站，使用者可能在 iframe 裡被釣魚。但即使如此，iframe 內的 JS 無法存取你主頁面的 cookie、DOM、localStorage。

為什麼 Giscus 留言系統是安全的

部落格使用 Giscus 作為留言系統，它透過 iframe 嵌入。這是安全的，因為：

iframe 隔離：Giscus 運行在 GitHub 的 iframe 裡，不是直接在你的頁面 DOM 中
同源政策保護：瀏覽器的 Same-Origin Policy 阻止 iframe 內的 JS 存取主頁面的任何東西
可信任來源：Giscus 來自 GitHub，留言內容由 GitHub 負責過濾和渲染
Cookie 隔離：CF_Authorization cookie 設定在你的網域上，GitHub iframe 完全看不到

iframe 的風險是「被別人嵌入」和「嵌入不可信來源」，不是「嵌入可信來源」。

結論

對個人部落格的私密文章來說，Cloudflare Access 提供的安全層級非常足夠：

攻擊向量	風險等級	說明
JWT 變造	極低	RS256 非對稱加密，無私鑰無法偽造
XSS 竊取 Cookie	極低	純靜態站無 JS 注入入口
iframe 跨域存取	無	同源政策完全隔離
Email 帳號入侵	低	唯一實際風險，但屬於帳號安全範疇

安全不是追求零風險，而是讓攻擊成本遠高於攻擊收益。一個個人部落格的私密文章，用 Cloudflare Access 的 JWT + Email OTP 保護，已經是非常合理的選擇。

前言