我经营一个WordPress代理商。Seahawk Media已交付超过12,000个WordPress网站，目前在护理计划中维护数千个。所以当我说用Next.js、Astro或Nuxt构建的无头网站在物质上比即使是运维良好的WordPress网站更安全时，这不是从便宜的座位写出来的观点。这是一个在WordPress安全模型内工作了12年、现在每周都同时交付两种架构的人的实战观察。
这篇文章的诚实框架：WordPress安全是可管理的。配合托管主机、前面的Cloudflare、每个登录都有双因素认证、严格的插件管理和有人实际关注，WordPress就没问题。这个平台本身并不不安全。它只是需要主动管理才能保持安全。无头网站不需要这种管理。攻击面在结构上是不同的，而这种结构差异就是整个论点。
WordPress攻击面实际上是什么样的？
一个标准WordPress网站在请求时运行PHP进程、连接到MySQL数据库、执行插件代码、执行主题代码、暴露/wp-admin、暴露/wp-login.php、在/wp-json暴露REST API、在/xmlrpc.php暴露XML-RPC（在许多安装中仍然是默认开启的）、接受通过媒体处理器的文件上传，以及将用户输入存储在数据库中。这些面的每一个在过去五年内都曾是一个重大CVE的来源。
我们在Seahawk应对的最昂贵的WordPress事件可以追溯到四个根本原因之一：一个没有及时修补的已知插件漏洞、对/wp-login.php的暴力攻击成功对付了一个弱管理员密码、一个包含任意文件上传漏洞的过时主题，或一个热门插件的受损供应链，其中维护者账户本身被劫持。这些都不是理论。Yuzo Related Posts XSS、File Manager RCE、Elementor Pro权限提升，以及热门表单生成器插件中的反复漏洞都是过去几年影响数百万网站的具体例子。
你可以防御其中的每一种攻击。我们每天都在这样做。但你必须主动防御。WordPress 安装永远没有一个安全的节点，除非持续进行操作维护，否则无法保持安全。
无头架构的攻击面实际上是什么样的？
在请求时渲染的静态 Next.js 或 Astro 站点从 CDN 提供预构建的 HTML、CSS 和 JavaScript 文件。没有 PHP 进程。没有数据库连接。没有管理面板。没有插件目录。公开站点上没有文件上传端点。没有 /wp-login.php 可以被暴力破解。没有 XML-RPC。没有评论表单在每次页面加载时将用户输入写入数据库。
内容编辑所在的 CMS，无论是 Sanity、Contentful、Supabase、Strapi 还是无头 WordPress 安装，都位于经过身份验证的 API 访问后面的单独源上。即使攻击者完全破坏了你的 CDN 提供的静态站点，他们也无法获得数据库。数据层需要的 API 凭证不会存储在公开站点的任何地方。
当内容团队发布新内容时，构建管道从 CMS 提取数据、构建新的静态文件，并将其部署到 CDN。构建在隔离的环境中运行，而不是在你的实时服务器上。输出是一组全新的静态文件。没有持久的运行时可以被破坏。
两种架构之间的视觉差异大致如下：
在右侧，该堆栈的每一层都是请求时漏洞可能落地的地方。在左侧，请求时的路径是对预渲染文件的单一边缘缓存命中。这个结构上的差异就是整个文章的核心。
无头模型在结构上排除了哪些攻击？
请求时的 SQL 注入消失了。访问者加载页面时没有数据库查询发生。数据已经在构建时获取并呈现为 HTML。
请求时的插件和主题远程代码执行消失了。公开站点上没有 PHP 执行面可被利用。构建时依赖是一个单独的问题，我将在下面讨论。
公开网站上的暴力破解凭证攻击已经消除。没有在公共URL上暴露的管理面板。CMS身份验证端点位于单独的源上，通常使用OAuth或魔法链接认证，而不是在典型WordPress安装上每天被暴力破解三万次的用户名和密码表单。
文件上传漏洞已经消除。公开网站没有上传端点。媒体通过CMS UI上传到CMS存储层，该存储层在资产到达CDN之前，在沙箱管道中验证和处理资产。
通过用户提交的内容进行的跨站脚本攻击大幅减少。没有评论表单、联系表单或用户提交的内容写入到运行时数据库，供访问者在下次页面加载时查看。无头网站上的表单发送到单独的API（Netlify函数、Supabase边缘函数或Formspree等第三方服务），该API拥有自己的身份验证和验证层。
服务器端请求伪造、本地文件包含以及大多数依赖于服务器端运行时的OWASP Top 10条目对于静态渲染网站根本不适用。攻击模式需要一个根据用户输入执行代码的服务器。不存在这样的服务器。
那npm包的供应链攻击呢？
这是坦诚的反方论点，值得真正重视。Next.js或Astro项目随附数百个npm依赖项。如果一个流行的包被破坏（2018年的event-stream事件、2021年的ua-parser-js破坏、2024年的Polyfill.io供应链攻击），恶意代码可能会进入你的构建输出并提供给访问者。
三件事使这在实践中的风险明显小于WordPress的等价风险。首先，恶意代码仅在你下次构建和部署时运行。WordPress插件的破坏可以在插件自动更新后的几分钟内向实时访问者传播恶意行为。其次，npm包破坏倾向于在数小时内被自动扫描仪、dependabot和安全研究社区检测到，因为许多生产工具依赖于相同的包。第三，安全意识强的无头设置会固定依赖版本并使用lockfiles，所以你不会在明确选择更新之前获取恶意版本。
我仍然会对无头推荐：固定依赖、在每次构建时运行npm audit、订阅GitHub安全公告以获取你的主要包、并将任何计划外的部署视为安全审查触发器。
典型的WordPress黑客攻击实际上是如何发生的？
根据我们在Seahawk过去二十四个月内应对的事件，这是大致的分布情况。大约四十个百分比追溯到已知的、已修补的CVE的过时插件。大约二十五个百分比追溯到被破坏的管理员账户，几乎总是弱密码且没有双因素认证。大约十五个百分比追溯到过时的WordPress核心或PHP版本。大约十个百分比追溯到自定义主题中的漏洞。剩余的十个百分比是所有其他情况：托管账户破坏、DNS劫持、恶意开发者访问、插件维护者的供应链。
注意这些根本原因中有多少在无头网站上根本不存在。没有插件需要补丁。公开网站上没有管理员账户。PHP 版本无关紧要，因为没有 PHP。自定义主题在构建管道中运行，而不是在实时服务器上运行。
这是否意味着无头网站无法被破解？
不是。剩余的攻击向量是真实的，值得指出。对内容编辑的 CMS 凭证进行网络钓鱼仍然有效。CMS 本身可能存在漏洞（Sanity、Contentful、Strapi 和 Payload 都曾有过 CVE）。Vercel 或 Netlify 上的托管账户泄露会让攻击者获得密钥。DNS 劫持会重定向流量，无论网站如何构建。对你的 git 仓库的恶意提交将重新构建和部署攻击者想要的任何东西。
改变的是攻击成本曲线。那些每天扫描互联网、针对每个 WordPress 安装的机会性自动化攻击根本不针对无头网站，因为没有可扫描的指纹，也没有适用的攻击手册。成功攻击无头网站的攻击是有针对性的、有计划的，需要凭证盗取或供应链访问。这些是真实的威胁。它们也是运行良好的 WordPress 安装所面临的威胁，除此之外还有机会性攻击，而不是代替这些威胁。
WordPress 为什么对大多数企业仍然足够安全？
因为保持其安全所需的运营纪律是公认的，也被广泛践行。使用处理核心更新、服务器强化和数据库隔离的托管主机。在源站前放置 Cloudflare 或类似的 WAF。为每个管理员登录启用双因素认证。将管理员账户限制在尽可能少的人数，并每季度审计一次。坚持严格的插件饮食，来自知名作者的十个或更少的维护良好的插件。每周更新所有内容。每天进行备份，至少每季度测试一次恢复。使用每天运行的恶意软件扫描器。
如果一致地应用这个方案，WordPress 对普通业务来说和普通无头网站一样安全。问题在于一致性。被黑的 WordPress 网站不是采用这个方案的网站。它们是那些机构在两年前就脱离的网站，插件更新停止了，管理员账户密码是在 2019 年设置的，没有人在好几个月里登录过主机控制面板。无头网站对这种忽视是宽容的。WordPress 网站则不然。
安全差异对 2026 年的机构客户意味着什么？
我在与客户交流时的工作框架是：当内容速度、插件生态系统优势或非技术编辑体验是主要需求，且客户愿意资助持续的安全维护时，WordPress 是正确的答案。当客户想要一种无需维护的安全姿态、团队具有技术成熟度来运行构建管道，且内容模型定义得足够清晰以至于结构化 CMS 有意义时，无头是正确的答案。
实际上这意味着：营销网站、宣传册网站、文档网站以及停机成本高昂的高价值属性页面作为无头网站往往表现更好。具有重型插件生态系统依赖的网站（会员制、具有利基地区税务要求的电子商务、复杂的 LMS、BuddyPress 风格的社区）往往作为 WordPress 表现更好，因为插件优势超过了安全开销。
这个决定很少是关于哪种架构在绝对意义上更安全。而是关于哪种架构与客户现实能够承担的安全维护相匹配。
如果安全是唯一标准，我会构建什么？
一个静态渲染的 Astro 或 Next.js 网站，在每次内容变更时在 CI 中构建，部署到 Vercel 或 Netlify（仅使用部署令牌），内容来自 Supabase 或 Sanity（启用 RLS 或文档级权限），表单提交到单独的边缘函数（配置速率限制），所有密钥存储在主机提供商的环境变量中（永远不提交），域名 DNS 在 Cloudflare（启用 DNSSEC），整个链路中的每个账户都启用双因素认证（CMS、主机、DNS、git、包注册表），以及配置好的 dependabot 来标记每一个依赖变更。这个设置确实接近无法被破解，除非遭遇有针对性的国家级别操作，而这不是普通营销网站的威胁模型。
总结
WordPress 是可管理的。Headless 是可接受的。老实的区别在于，你可以半年不管一个 headless 网站，回来时它仍然安全。WordPress 就做不到。对于在 2026 年选择架构的业务来说，安全论证不是"哪个更安全"，而是"哪个安全态势与我的实际运维纪律相匹配"。如果答案是"我们不会密切关注这个网站"，那么 headless 以实际幅度更安全。
我们仍然交付比其他任何东西都多的 WordPress，因为大多数客户仍然需要 WordPress 独有的功能。但对于任何对话以"我们只想让它保持运行而不用费心去想它"开始的客户，我越来越多地首先推荐 headless 并解释原因。
相关阅读
2026 年的 Headless WordPress：完整实战指南
2026 年的 WordPress vs Next.js：我的诚实对比
WordPress 维护主要是关于用心