频繁的安全事件：Web 系统所需的"入侵防止"与"损害最小化"

自 2026 年初以来，特别是近几个月，针对国内企业 Web 系统的非法访问和信息泄露报告接连不断。
10 月 8 日，JPCERT / CC 发布了「关于最近国内组织中频繁发生的非法访问的警告」，随后 9 日，IPA 也呼吁根据非法访问引发的信息泄露采取紧急措施。

看到这些事件，人们往往会注意到老旧系统或未更新软件的问题。
当然，这些都是很大的风险，但说系统升新就能确保安全就太过于简单化了。

我认为重要的是要彻底实施防止入侵的措施，而且即使万一发生安全问题，也能够实施多层防御设计来最大限度地减少损害。

这次我以 Cloudflare、Supabase 以及 2026 年 9 月正式发布的 EmDash 为例，思考了未来的 Web 安全问题。

非法访问并不只针对特定企业

JPCERT / CC 在这次警告中涉及的不仅仅是针对已知漏洞的攻击，还包括配置文件和备份文件的探索、对 API 的非法请求、被盗取的 API 密钥的滥用、以公开 Web 服务器为跳板进入内部等多种攻击手段。

特别值得关注的是，除了面向普通用户的服务外，员工管理系统和 BI 工具等也成为了攻击目标。
随着 AI 的发展，曾经「只要不被谷歌索引就没事」的概念已经消失，公开在互联网上的系统面临每天都会遭受自动化探索和攻击的可能性。

「我们这样的小系统不会被盯上！」这种想法已经不再成立。

使用现代技术就能保证安全吗？

旧版 PHP、已停止支持的框架以及多年未更新的 CMS 自然存在风险。
那么用 Next.js 或 Astro 构建、使用云服务就安全了吗？

遗憾的是，并不一定。😭

即使是最新的框架也会发现漏洞，如果 API 的授权处理存在缺陷，可能会导致本不应该访问的数据被获取。
如果管理不好身份验证信息或 API 密钥，即使是可靠的云服务也会造成损失，因此技术新旧与系统安全性是两个不同的问题。

在 Cloudflare 中的应用程序前端设置防御

Cloudflare 作为 CDN 而广为人知，但在考虑 Web 应用程序安全性时也发挥着重要作用。
例如，可以通过 WAF（Web 应用防火墙）检测并阻止可疑请求，通过速率限制抑制大量访问，使用 Cloudflare Access 还可以将内部管理界面等的访问限制于经过身份验证的特定用户。

话虽如此，这远非完美。😭
首先，不必公开的管理界面处于任何人都可以访问的状态本身就构成了风险。

WAF 并不能防御所有攻击，正常格式请求的滥用、应用程序特有的授权缺陷等需要采取其他措施。
Cloudflare 是在应用程序前端设置防御的机制，不能保证应用程序本身的安全性。

在 Supabase 中也可以在数据库侧控制访问

这里值得考虑的是 Supabase 提供的 RLS（行级安全）。
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 系统现代化时，不仅要关注「使用什么技术」，还需要考量「设计中信任边界的划定」。