持續發生的安全事件：Web 系統所需的「入侵防止」與「損害最小化」

自 2026 年初以來，特別是近幾個月，針對國內企業 Web 系統的非法存取與資訊洩漏報告接連不斷。
10 月 8 日，JPCERT/CC 公開了「針對近期相繼發生的國內組織非法存取的警示」，隔日 9 日，IPA 也呼籲實施基於非法存取所致資訊洩漏的緊急對策。

檢視這類事件時，容易將目光聚焦在舊系統或未更新軟體的問題上。
當然，這些都是巨大風險，但只是簡單地認為系統更新就能確保安全，這種想法並不正確。

我認為重要的是徹底採取措施預防入侵，並且即使在萬一發生安全問題時，也要能透過多層防禦的設計將損害控制在最低限度。

本次我以 Cloudflare、Supabase 以及 2026 年 9 月正式發佈的 EmDash 為例，思考了今後的 Web 安全。

非法存取並非只針對特定企業

JPCERT/CC 在本次警示中提出的不僅是針對已知脆弱性的攻擊，還包括設定檔案和備份檔案的探索、對 API 的非法請求、被竊取 API 金鑰的濫用、利用公開 Web 伺服器作為跳板侵入內部等，攻擊手法多種多樣。

特別令人擔憂的是，除了一般用戶服務外，員工用管理系統和 BI 工具等也成為受害對象。
隨著 AI 的發展，以往「只要不被 Google 索引就沒問題」的概念已經消失，公開在網際網路上的系統可能會立即面臨持續不斷的自動化探索和攻擊。

「像我們這樣的小型系統不會被盯上！」這樣的想法已經行不通了。

使用現代技術就能確保安全嗎？

舊版 PHP 或停止支援的框架、多年未更新的 CMS 當然存在風險。
如果使用 Next.js 或 Astro 建置並利用雲端服務，就安全了嗎？

遺憾的是，不一定是這樣。😭

即便是最新的框架也會發現安全漏洞，若 API 授權處理有缺陷，就可能洩露原本無法存取的資料。
若認證資訊或 API 金鑰管理不當，即使是堅牢的雲端服務也可能造成損害，因此技術新穎與系統安全是兩個不同的問題。

在 Cloudflare 應用程式前端設置防護

Cloudflare 以 CDN 聞名，但在考量網路應用程式安全時也扮演重要角色。
例如，可以透過 WAF（Web Application Firewall）偵測並阻止可疑請求，通過速率限制抑制大量存取，或利用 Cloudflare Access 將社內管理介面的存取限制於認證過的特定使用者。

儘管如此，這遠非完美之策。😭
首先，本不需要公開的管理介面如果任何人都能存取，本身就是風險。

有了 WAF 也無法防禦所有攻擊，格式正常但被濫用的惡意操作及應用程式特有的授權缺陷等需要另行對策。
Cloudflare 是在應用程式前端設置防護機制，不能保證應用程式本身的安全性。

在 Supabase 資料庫層面也進行存取控制

這裡值得思考的是 Supabase 提供的 RLS（Row Level Security）。
RLS 是 PostgreSQL 的功能，可在資料庫行級別控制存取範圍。例如在多個企業使用的業務系統中，可以設定 A 公司使用者只能查看 A 公司資料的規則也在資料庫端設置。
即使應用程式端的授權處理有誤，正確設置的 RLS 也能發揮追加防護的作用。

然而……設置 RLS 也不是萬能的。😭

Supabase 的 secret key 和傳統的 service_role 金鑰根據使用方式可以具有強大的權限，能夠繞過 RLS，所以如果管理不當，RLS 提供的防護就無法發揮作用。
資料表的權限設定和政策測試也是不可或缺的。

重點在於不僅依賴應用程式的授權，還要在資料庫層面實施獨立的控制機制。

EmDash 採用的外掛信任模型

2026年09月28日，由 Cloudflare 支援開發的 CMS「EmDash 1.0」正式發布，官方外掛註冊表也同時公開了！
我們從發布時就開始關注，並且已經用它實現了網站，因此感到非常感動。

用 EmDash 製作多語言部落格的經驗 〜如何在 SSR 下降低翻譯 API 成本〜
從 microCMS 遷移到 EmDash + Cloudflare

EmDash 有趣的地方在於其外掛的安全模型。
傳統型 CMS 中，外掛通常以接近 CMS 核心的權限執行，外掛的漏洞可能會影響整個系統，但 EmDash 官方註冊表中的外掛在沙箱環境內執行。
透過限制外掛可用的功能和資源，並明確說明所需的權限，來縮小影響範圍的設計。

當然，EmDash 也存在不使用沙箱的原生外掛，並非所有外掛都安全；同時 EmDash 本身是一個剛推出不久的 CMS，我們需要持續觀察其未來的運營成效和安全應對。

儘管如此，從設計上就不完全信任外掛的理念，是未來思考 CMS 發展時值得關注的重點。

共同點在於「不信任所有事物」的思維方式

Cloudflare、Supabase 和 EmDash 各自扮演不同的角色，但從安全的角度來看，它們展現出共同的思維方式。

• Cloudflare：在應用程式前端控制可疑的存取
• Supabase：從應用程式端進行的存取也要在資料庫端進行權限控制
• EmDash：分離執行環境，不授予外掛程式超過必要的權限

這些方法都不是將安全性全部寄託在單一機制上，而是限制信任的範圍。這種想法與零信任架構和最小權限原則是相通的，不是嗎？

• 即使認證被突破，也不是所有操作都會被允許。
• 即使 API 有缺陷，也不是所有資料都能被取得。
• 即使外掛程式存在安全漏洞，也無法操作整個系統。

透過設置這些邊界，可以降低單一問題導致整個系統遭到破壞的風險。

總結：防止入侵，萬一發生事故也要將傷害最小化

改用 React 了！改用 Next.js 了！移轉到雲端了！
這些技術更新確實有其意義，但光是更換框架或基礎設施並不足以稱為真正的現代化。我認為重要的是理清認證、授權、API、資料庫、外部服務各自的責任和權限，建立一種單一漏洞不易擴散到其他領域的架構。

安全性對策沒有絕對的保證。
正因為如此，必須層層疊疊地採取預防入侵的措施，即使問題發生，也能設計多層防禦來防止損害擴大。

Cloudflare、Supabase 和 EmDash 都不是萬能的，但這些技術具有只授予必要權限、按職能劃分邊界的機制。

Liberogic 在構築 Web 系統時，不僅僅是採用新技術，更重視這類職責分離和多層防禦。

在安全事件頻繁發生的現在，考慮 Web 系統現代化時，不僅要關注「使用哪些技術」，還要注意「設計中信任邊界在何處」，這一點應該格外重要。