事故摘要

Cloudflare 在 2019-07-02 發布新的 WAF Managed Rule 後，規則中的 regex 觸發 catastrophic backtracking，導致 edge CPU 快速打滿。事故影響約 27 分鐘，症狀是大量 502/503 與延遲激增。

這起事件屬於典型「控制面配置推送 → data plane 全網受影響」模式。錯誤並非單點節點故障，而是由一致推送機制把同一錯誤同步擴散到整個 edge 網路。

判讀訊號

事故路徑

1. 控制面推送新 WAF 規則到全球 edge。
2. 規則 regex 在特定輸入下產生高計算成本。
3. edge CPU 被規則執行成本吃滿，請求處理能力下降。
4. 5xx 與延遲擴散成全球可見症狀。
5. 回滾規則後，CPU 與可用性逐步恢復。

這條路徑顯示：事故擴散速度主要由「推送覆蓋範圍」決定，而不是由「單機故障率」決定。

可回寫控制面

下一步路由

• 回寫訊號治理： 4.17 Telemetry Data Quality
• 回寫規則成本訊號： 4.21 Rule-level CPU Signal Governance
• 回寫規則推送閘門： 6.24 Rule Rollout Safety Gate
• 回寫驗證與安全邊界： 6.20 Experiment Safety Boundary
• 回寫事中決策與證據： 8.19 Incident Decision Log
• 回寫跨模組閉環： 8.22 Incident Evidence Write-back

引用源

• Details of the Cloudflare outage on July 2, 2019

事故摘要

Cloudflare 在 2023-01-24 經歷 service token 相關變更問題，造成內外部控制面能力受影響，連帶影響多個產品面向。事件本質是控制面身份機制失效，並透過共用依賴擴散。

這類事故的危險在於症狀看起來像多個服務同時不穩，但根因其實是同一個共享身份控制點。若沒有先識別 shared dependency，排障會被切成很多局部問題，恢復速度會顯著下降。

判讀訊號

事故路徑

1. 控制面 token/身份相關變更進入生產環境。
2. 共享身份依賴開始出現授權或驗證失效。
3. 多個產品面的控制操作受阻，形成連鎖症狀。
4. 團隊透過回退與修正策略逐步收斂。
5. 事件後需回寫身份變更治理與事故交接流程。

這條路徑顯示：擴散關鍵在 shared identity dependency，不在單一產品流量高低。

可回寫控制面

下一步路由

• 身分邊界與權限治理： 7.2 Identity Access Boundary
• 規則推送安全閘門： 6.24 Rule Rollout Safety Gate
• 事故決策紀錄： 8.19 Incident Decision Log
• 證據回寫流程： 8.22 Incident Evidence Write-back
• 控制面訊號治理： 4.18 Observability Operating Model

引用源

• Cloudflare incident on January 24, 2023

規劃重點

• 全球 configuration push 的 blast radius：為何 60 秒內可癱瘓全球流量
• Regex CPU 耗盡：catastrophic backtracking 如何繞過所有 timeout
• BGP 風險：路由洩漏如何把流量吸入錯誤 ASN
• Recovery 設計：為何 configuration rollback 需要 dataplane 層協作

預計收錄事故

案例清單

• 2019 Regex CPU Outage
• 2023 Control Plane Token Incident
• 2023 Workers KV Deployment Tool Misconfiguration
• 2026 BYOIP BGP Withdrawal

建議閱讀順序

1. 2019 Regex CPU Outage
2. 2023 Control Plane Token Incident
3. 2023 Workers KV Deployment Tool Misconfiguration
4. 2026 BYOIP BGP Withdrawal

案例定位

Cloudflare 這個案例在講的是 edge 平台如何把一個小錯誤快速放大到全球。讀者先看懂配置推送、runtime 驗證與路由撤銷各自的責任，再把 anycast 與 control plane 當成事故擴散的核心路徑。

判讀重點

當 regex、workers 設定或 deployment tool 出現問題時，真正危險的是錯誤被快速推到全網，單一節點故障反而容易收斂。當 BGP 或 BYOIP 參數變動時，回滾與驗證就必須先於擴散，否則影響會直接表現在全球流量上。

可操作判準

• 能否在全網推送前做足夠的配置驗證
• 能否把 blast radius 限制在局部 edge 群組
• 能否在 CPU 熱點或路由撤銷前先看見異常
• 能否把 rollback 動作設計成快速且可驗證

與其他案例的關係

Cloudflare 和 Fastly 都在講 edge 平台的快速擴散，但 Cloudflare 更常暴露控制面與部署工具的問題。它和 AWS S3、GCP 放在一起看，可以更清楚看到全球網路事故是配置與路由鏈條的連鎖反應，單一節點失效很少是起因。

代表樣本

• 2019 年 regex CPU outage 是 catastrophic backtracking 直接拖垮 edge runtime 的經典樣本。
• 2023 年控制面事故與 2026 年 BYOIP / BGP 事故則顯示配置與路由都能成為全球擴散點。
• 這組樣本也能對照配置推送與回滾速度對 blast radius 的影響。
• Cloudflare 的事故史很適合拿來和 Fastly 比較 edge 平台差異。
• workers / deployment tool misconfiguration 讓控制面本身成為風險。
• anycast edge 讓路由錯誤能在全球尺度迅速顯現。
• global propagation 讓回滾時間直接影響用戶體感。
• control plane bug 常常比 data plane bug 更難局部化。

引用源

• Details of the Cloudflare outage on July 2, 2019：regex CPU / catastrophic backtracking 事故的官方回顧。
• Cloudflare incident on January 24, 2023：service token / control plane 變更導致的多產品連鎖影響。
• Cloudflare incident on October 30, 2023：Workers KV / deployment tool misconfiguration 的控制面事故。
• Cloudflare outage on February 20, 2026：BYOIP / BGP 變更造成的路由撤銷事故。

事故摘要

Cloudflare 在 2026-02-20 17:48 UTC 發生 BYOIP 相關 outage。部分使用 Bring Your Own IP（BYOIP）的客戶，其 IP prefixes 被 Cloudflare 經由 BGP 非預期撤告，導致相關服務從 Internet 無法到達。官方回顧指出，事故總時長為 6 小時 7 分鐘；在 4,306 個 BYOIP prefixes 中，約 1,100 個 prefixes 曾被撤告，約佔 BYOIP prefixes 的 25%。

事故起因是 Cloudflare 在 Addressing API / BYOIP pipeline 中引入的自動化清理流程，與外部攻擊無關。該流程原本要移除 pending deletion 的 prefixes，但 API query 的 pending_delete 參數沒有值，server 端將它解讀成一般查詢，回傳所有 BYOIP prefixes。下游流程接著把回傳結果當成待刪除集合，開始撤告 prefixes 與移除相關 service bindings。

判讀訊號

事故路徑

1. Addressing API 相關程式碼在 2026-02-05 合併，並於 2026-02-20 部署。
2. cleanup sub-task 查詢 /v1/prefixes?pending_delete，但 pending_delete 沒有值。
3. API server 沒有進入 pending deletion 分支，而是回傳所有 BYOIP prefixes。
4. cleanup sub-task 將回傳的 prefixes 解讀成待移除集合，開始撤告 prefixes 與刪除 dependent objects。
5. Cloudflare 在觀察到 1.1.1.1 相關失敗後回退變更並終止 broken sub-process。
6. 多數 prefixes 透過 re-advertise 或 restore 流程恢復，剩餘約 300 個 prefixes 需要工程師手動恢復 service bindings 與 edge 設定。

這條路徑顯示：BGP withdrawal 是結果，真正的事故起點是控制面資料查詢語意不明確，以及 operational workflow 對查詢結果缺少大範圍變更 circuit breaker。

可回寫控制面

下一步路由

• 控制面資料品質： 4.17 Telemetry Data Quality
• 規則推送安全閘門： 6.24 Rule Rollout Safety Gate
• 變更安全邊界： 6.20 Experiment Safety Boundary
• 驗證證據交接： 6.23 Verification Evidence Handoff
• 事故決策紀錄： 8.19 Incident Decision Log
• 證據回寫流程： 8.22 Incident Evidence Write-back

引用源

• Cloudflare outage on February 20, 2026

事故摘要

Cloudflare 在 2023-10-30 發生控制面相關事故，根因涉及 deployment tool 的設定錯誤，影響 Workers KV 與相關服務操作路徑。表面症狀可出現在多個產品面向，但本質是共享控制面變更帶來的連鎖失效。

這類事故和單點 runtime bug 不同。關鍵不是「哪個服務先報錯」，而是「哪個共用控制點先失真」。

判讀訊號

事故路徑

1. 控制面 deployment tool 變更進入生產。
2. 設定錯誤導致共享控制路徑失真。
3. Workers KV 與關聯產品出現控制操作異常。
4. 團隊透過回退與修正逐步收斂錯誤。
5. 事故後回寫 deployment guardrail、decision log 與 evidence 管線。

可回寫控制面

下一步路由

• 事故決策紀錄： 8.19 Incident Decision Log
• 事故證據回寫： 8.22 Incident Evidence Write-back
• 規則推送安全閘門： 6.24 Rule Rollout Safety Gate
• 觀測治理模型： 4.18 Observability Operating Model

引用源

• Cloudflare incident on October 30, 2023

本文是 Cloudflare WAF overview 的 implementation-layer deep article。Overview 已說明 Cloudflare WAF 在入口治理譜系的定位、本文聚焦 Page Shield 這個 client-side（browser）supply chain attack 防禦工具 — 跟 WAF 攔 server-side request 是不同層。

Attack pattern × Defense mechanism 對照

Client-side supply chain attack 不會被 WAF 看到 — 攻擊發生在 browser 渲染 page 時、不在 origin server 跟 client 之間的網路層。Page Shield 是 browser-side script execution 的監測 + 防禦層、跟 WAF 處理 server-side request inspection 互補不重疊。

三層防禦對應不同 attack 階段：

1. CSP（Content Security Policy）：browser-enforced policy、preventive、阻止違反 policy 的 script load / network request
2. SRI（Subresource Integrity）：load 階段 hash 驗證、detective + preventive、廠商 CDN 上 script 被改就 browser 拒載
3. Script monitoring：runtime 觀測、detective only、記錄頁面 load 哪些 third-party script、變動時 alert

三層各有 ceiling — CSP 擋 inline / unauthorized source 但擋不到 allowed source 被 compromise；SRI 擋已知 vendor 改 hash 但擋不到動態 loader；monitoring 看得到但攔不到。Production 三層疊用、不要單一 layer。

CSP 配置 step-by-step

從 Cloudflare dashboard 啟用 + 寫 policy

 1# Dashboard: Security → Page Shield → CSP
 2# 模式: Report-only（第一週）→ Enforced（驗證後）
 3
 4# 範例 policy
 5default-src 'self';
 6script-src 'self' 'nonce-{NONCE}' https://cdn.trusted.com https://www.googletagmanager.com;
 7style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
 8img-src 'self' data: https:;
 9connect-src 'self' https://api.myapp.com https://*.sentry.io;
10form-action 'self';
11frame-ancestors 'none';
12report-uri https://csp-report.cloudflare.com/cdn-cgi/script_monitor/report;
13report-to default;

關鍵直覺：

• 'nonce-{NONCE}'：origin server 每 request 生成 random nonce、注入 <script nonce="..."> 跟 CSP header；script tag 沒對應 nonce 就被 browser 拒跑、擋 XSS
• connect-src 精準寫：第三方 API endpoint 全列出；不寫 * 或 https: 是擋 exfiltration 的關鍵（Magecart 把信用卡送外部 endpoint 就是用 connect-src 攔）
• form-action：擋 form 被改 action attribute 送外部、formjacking 第一道防線
• report-uri + report-to：违反 policy 的 event 送 Cloudflare、Page Shield dashboard 看 violation report

Report-only mode 第一週

1Content-Security-Policy-Report-Only: <policy>
2Content-Security-Policy:             default-src 'self';   # 鬆 policy 仍 enforce

Report-only 期間 browser report 違反但不擋、production traffic 不受影響；SOC 看 report 找：

• 漏列的 legitimate third-party（marketing / analytics SDK 沒寫進 policy）
• 意外 inline script（dev 留下的 debug snippet）
• 跨 domain 的合法 connect（CRM / chat widget）

第一週後 dashboard 看 violation 數量趨穩 + 主要違規都已 whitelist、切 Enforced。

Enforced mode 切換 + canary

不要直接全站 enforced — 用 Cloudflare Page Rule 對 10% traffic enforced、90% report-only：

1URL pattern: example.com/*
2Page Rule: Add CSP header (enforced)
3Bypass: 90% by Cookie / IP hash

10% traffic 跑 24-48h、確認 zero legitimate violation、再擴大到 50% → 100%。canary 期間 monitor error-rate metric、不只是 violation report。

SRI 配置

Subresource Integrity 用 hash 驗證 CDN-hosted script 沒被改：

1<script src="https://cdn.example.com/widget.v1.2.3.js"
2        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
3        crossorigin="anonymous"></script>

Browser load 時算 hash、跟 integrity 不符就拒跑。關鍵：

• Hash 一定要 version-pinned：用 widget.v1.2.3.js、不能用 widget.latest.js；廠商更新 latest 時 hash 變 → SRI 拒載 → 服務中斷
• 多 hash：寫 integrity="sha384-... sha512-..." 至少一個 match 就過、可在 vendor rotate hash 時平滑遷移
• crossorigin="anonymous" 必加：跨 origin script 預設 browser 不暴露 hash 失敗細節、anonymous 才允許 CORS-based hash check

Page Shield 自動產 SRI 提示

Dashboard → Page Shield → Scripts 列出所有偵測到的 script、含 建議 SRI hash；可以 export 整合進 build pipeline、自動把所有 vendor script 加 SRI。

故障演練

Case 1：CSP report flood，SOC noise

徵兆：切 Enforced 後、CSP violation report 從每天 ~500 漲到每分鐘 ~50K、Page Shield dashboard 變紅、SOC 收 alert 收到 silent。

根因：browser extension（廣告攔截 / spell checker / password manager）注入 inline script 跟 connect、被 CSP block 同時觸發 report；不是真實 attack、是 user 端 extension 行為。

修法：

1. CSP report-sample directive 限 sampling（只 report 10%）— spec 部分支援、不是所有 browser 都認
2. Page Shield 規則：filter out extension protocol（chrome-extension://、moz-extension://、safari-extension://）後再 alert
3. Report endpoint 自管 + aggregation：不直接接 SIEM、先 batch + dedupe、再送 SIEM
4. 接受 report flood 是 normal、focus 監測 unique violation pattern 不是 total volume

Case 2：Inline script 漏，舊頁面突然壞

徵兆：切 Enforced 後 X 個舊頁面壞、user feedback 提交 form 失敗、debugger 看到 console Refused to execute inline script because it violates...。

根因：legacy page 有 inline <script> 沒 nonce、CSP enforced 後 browser 拒跑；報表/管理後台/舊 admin page 常見。

修法：

1. Audit 所有 inline <script>、加 nonce attribute（server-side render 時注入）
2. 短期：對舊頁面用 unsafe-inline 寫進 CSP（接受降級）、page-specific CSP override
3. 長期：legacy page 改 build-time bundle、消除 inline script

Case 3：Dynamic script loader 繞過 SRI

徵兆：vendor script load 成功、但 Page Shield monitoring 看到該 vendor script load 後又動態 load 多個額外 script；額外 script 沒 SRI 保護、廠商側 compromise 直接過。

根因：第三方 SDK 用 document.createElement('script') + script.src = '...' runtime 動態 load；CSP script-src 可能允許這個來源、但 SRI 沒法在 runtime 注入。

修法：

1. CSP script-src 精準到 只允許特定 path、不是整個 domain（例：https://cdn.vendor.com/sdk/v3/ 而不是 https://cdn.vendor.com）
2. 評估 vendor 是否有 static-only 替代（多數 marketing / analytics SDK 不需要 dynamic loader、是 legacy 設計）
3. 不能消除 dynamic loader 時、Page Shield monitoring 設 new script alert、廠商加 sub-script 即刻通知

Case 4：SRI hash mismatch，vendor 偷偷更新

徵兆：第三方 widget 突然不顯示、Page Shield 顯示 SRI mismatch、廠商 status page 沒事故公告。

根因：廠商在 same URL（不是 versioned）下偷偷 push minor patch、hash 變了 → SRI 拒載；不是 attack、是 vendor 不遵守 immutable URL 慣例。

修法：

1. 強制要求廠商提供 versioned URL（widget.v1.2.3.js）、不收 widget.latest.js
2. 廠商不配合時、build pipeline 加 daily hash check、廠商偷改 SRI hash 自動更新 + Slack alert
3. 評估換 vendor — 不遵守 immutable URL 的廠商 supply chain integrity 信用低

容量 + cost

Page Shield 是 Enterprise plan + Page Shield add-on、cost 維度：

Page load 影響：

• CSP header ~1-2KB（policy 寫越精準越長、不是越短越好）
• SRI 比對 ~5-10ms / script、現代 browser cache decoded hash、不重複算
• Script monitoring beacon ~100 byte / script load、async 不阻塞 page render

實務 default：

• Critical e-commerce / fintech：CSP enforced + SRI 全 vendor + monitoring all、SOC review weekly
• 一般 SaaS：CSP report-only ongoing + SRI critical vendor only + monitoring 主域
• Marketing / blog：CSP default-src 'self' minimum + monitoring only

整合 / 下一步

跟 dev workflow 整合

CSP 寫進 deploy pipeline、不是 dashboard 手動配：

1. Repo 內 csp-policy.yml、跟 code 同 lifecycle
2. CI 跑 CSP linter（如 csp-evaluator）、檢查 policy 弱點
3. Deploy 時 push 到 Cloudflare API、自動 versioning + rollback

跟 WAF 互補

Page Shield 跟 Cloudflare WAF 不重疊但互補：

• WAF 攔 server-side request injection（SQL / command / path traversal）
• Page Shield 攔 client-side script execution（XSS / supply chain）
• 共同 dashboard + alert routing、不要分開 SOC team 看

跟 supply chain SBOM

Page Shield 偵測的 client-side dependency 可進 SBOM、跟 Snyk / Dependabot 的 server-side SBOM 合併、得到完整 dependency graph。

下一步議題

• Trusted Types：browser-side template injection 的下一代防禦、Chrome 已支援、Firefox / Safari 進度不一
• CSP Level 3 + strict-dynamic：減少 maintenance burden、用 nonce 動態信任 nested script
• Reporting API v1：standard report endpoint + Reporting-Endpoints header 取代 report-uri

相關連結

• 上游 vendor 頁：Cloudflare WAF
• 上游 chapter：7.3 入口治理與伺服器防護、7.12 供應鏈完整性
• 對照案例：British Airways 2018 Magecart / Macy’s 2019 skimmer（公開 supply chain 案例）
• 平行 vendor：AWS WAF / Fastly Next-Gen WAF
• 平行 deep article：Vault Dynamic Credential / Splunk RBA
• Methodology：Vendor 深度技術文章的寫作方法論

選型情境是單人自用遠端 shell 存取：人在外、手機操作家中或辦公室本機的真實終端機（zsh）。兩個候選方案代表兩種根本不同的安全模型——「公開端點 + 多層防護」vs「私有網路 + 端點不存在」。

情境約束

• 單人自用（owner = 開發 = 維運 = 唯一用戶）
• 失敗代價高：整台機器的 shell 外洩
• 手機端需自建 Flutter 終端機 UI（兩方案皆需）
• 預算趨近零（免費方案）

兩方案架構對比

方案 A：Cloudflare Tunnel + Cloudflare Access

 1Flutter app（Face ID）
 2   │  WSS，帶三組憑證
 3   ▼
 4Cloudflare Tunnel（named，固定網域）
 5   ▼
 6Cloudflare Access（邊緣：驗 Service Token）── 未授權流量在此被擋
 7   ▼
 8Go proxy（本機：驗 X-App-Tunnel-Token）── 第二道
 9   ▼
10ttyd（本機：basic auth）── 第三道
11   ▼
12zsh

方案 B：Tailscale mesh VPN

 1Flutter app（Face ID）
 2   │  WS，帶 ttyd basic auth
 3   ▼
 4Tailscale mesh VPN（WireGuard 加密隧道，裝置級認證）
 5   ▼
 6Go proxy（本機：稽核 log + 透明轉發，不做認證）
 7   ▼
 8ttyd（本機：basic auth）── 應用層最後防線
 9   ▼
10zsh

核心選型維度

選型判讀

Tailscale 勝出的場景（本情境適用）

• 攻擊面最小化是首要目標：shell 閘道的失敗代價極高，「端點不存在」比「保護公開端點」本質上更安全
• 單人自用：不需要 CF Access 的多人 policy / IdP 整合 / Device Posture 等企業功能
• 架構簡單性：從 5 元件 3 層認證縮為 3 元件 2 層認證，Go proxy 職責大幅簡化（砍認證閘道，只留 log + 轉發）
• 密鑰管理簡化：不再需要為 proxy token 建可插拔多後端（keychain/file/env），只管 ttyd 帳密
• 不需要自有網域：Tailscale MagicDNS 或直接用 Tailscale IP

Cloudflare Tunnel 勝出的場景（本情境不適用，但值得記錄）

• 需要對外提供服務（非自用）：CF 的 WAF / CDN / rate limit / bot protection 生態豐富
• 需要 HTTP 層細粒度存取控制：CF Access 的 Application + Policy 模型適合管多個 internal web app
• 需要 Device Posture 檢查：CF 整合 CrowdStrike / SentinelOne 等 EDR 做裝置健康判斷（Device Posture：在授權前先檢查裝置的安全狀態 — 作業系統版本、磁碟加密、防毒軟體是否啟用）
• 已在用 Cloudflare 生態：共用控制面的管理紅利（同一 Logpush / API token / Audit Log）
• 多人 / 多團隊 / 合規場景：CF Access 的 IdP 整合 + Service Auth + Audit Log 比 Tailscale 個人方案完整

邊界情境

• 多人但仍小規模（2-5 人）：Tailscale ACL（存取控制清單，定義哪些裝置可存取哪些服務）足以控制；超過此規模再評估 CF Access 或 Teleport
• 需要 session recording：兩者都沒有一流方案——Tailscale 需 Enterprise tier，CF Access 只記 metadata 不錄 keystroke。重 audit 走 Teleport
• 需要從固定 IP 出網：Tailscale Exit Node 可做但不是設計核心；CF 有更成熟的方案

Tailscale 採用後的安全底線

即使 Tailscale 攻擊面更小，仍需維持以下底線：

此選型的 tripwire

從本情境到 vendor 詳頁

• Tailscale 完整 vendor 判讀 → Tailscale SSH
• Cloudflare Access 完整 vendor 判讀 → Cloudflare Access
• Infrastructure access + 合規場景 → Teleport
• 本選型的章節歸屬 → 7.3 入口治理與伺服器防護