禁用wordpress的rest api可通过在functions.php或自定义插件中添加代码实现，推荐使用选择性限制策略，即允许管理员和已登录用户访问，阻止未登录用户访问，同时移除api发现链接以降低攻击面；这样做既能提升安全性，防止用户枚举等数据泄露风险，又可避免彻底禁用导致gutenberg编辑器、页面构建器、表单插件、woocommerce扩展或第三方集成失效等问题，确保网站功能正常使用，是一种在安全与可用性之间取得平衡的有效做法。
禁用WordPress的REST API，通常可以通过在主题的
functions.php文件或自定义插件中添加代码来实现，这能有效阻止外部或未授权的请求访问你的网站数据接口。这样做的好处是多方面的，主要涉及安全和性能，尤其对于那些不需要REST API功能（比如非无头模式网站）的站点来说，这是一种直接且有效的加固手段。
解决方案
要禁用WordPress的REST API，最常见且直接的方法是利用WordPress提供的过滤器（filters）。以下是一个我个人倾向使用的代码片段，它可以阻止所有未登录用户的REST API访问，同时保留管理员和已登录用户的访问权限，以确保Gutenberg编辑器等依赖REST API的功能正常运行。
将以下代码添加到你主题的
functions.php文件，或者一个你自定义的插件中：
add_filter( 'rest_authentication_errors', function( $result ) {
// 如果已经有错误，直接返回
if ( ! empty( $result ) ) {
return $result;
}
// 如果是管理员或已登录用户，允许访问
if ( current_user_can( 'manage_options' ) || is_user_logged_in() ) {
return $result;
}
// 对于未登录用户，阻止访问并返回错误
return new WP_Error( 'rest_forbidden', __( '你没有访问此REST API的权限。', 'your-text-domain' ), array( 'status' => rest_authorization_required_code() ) );
});
// 彻底禁用REST API接口的发现功能，防止通过/wp-json/访问
remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );
remove_action( 'template_redirect', 'rest_output_link_header', 11 );这段代码的作用是，当有REST API请求进来时，它会检查用户是否已登录或者是否为管理员。如果不是，就会返回一个“权限不足”的错误。同时，它移除了HTML头部和HTTP响应头中关于REST API的链接，让外部更难发现你的API接口。
当然，如果你需要更彻底地禁用，甚至包括登录用户的访问，可以将
if ( current_user_can( 'manage_options' ) || is_user_logged_in() )这行去掉，或者修改为更严格的条件。但我个人不建议完全禁用，因为这可能会影响到一些核心功能。
禁用WordPress REST API对网站安全有什么影响？
谈到禁用REST API对网站安全的影响，这其实是一个挺有意思的话题。在我看来，这主要是一种“降低攻击面”的策略。WordPress的REST API确实提供了一个强大的接口，让外部应用可以与你的网站进行数据交互，比如获取文章列表、用户数据等等。但这种强大也带来了潜在的风险。
最直接的风险就是数据泄露，尤其是用户枚举。默认情况下，REST API的
/wp/v2/users端点可能会暴露你网站上所有用户的ID和用户名，这对于潜在的攻击者来说，无疑是收集信息、进行暴力破解攻击的“宝藏”。虽然WordPress后来对此做了一些限制，但风险依然存在。
另外，如果你的网站不需要与外部应用进行复杂的数据交互，那么开放REST API就相当于多开了一扇门。每一扇多开的门，理论上都可能成为被攻击的入口。禁用或限制它，就像是把这扇不必要的门关上，或者至少只给需要的人留个小缝。这并不是说REST API本身不安全，而是说，如果你用不上它，那么它的存在就增加了额外的管理和监控负担。
所以，从我的经验来看，对于那些内容固定、不作为API后端、不依赖Gutenberg以外的REST API功能的网站（比如简单的企业官网、个人博客），禁用或限制REST API，确实能有效减少被探测和攻击的机会，让你的网站变得更“安静”一些。
彻底关闭与选择性限制REST API，哪种方式更适合你？
这是一个关于“权衡”的问题，我个人倾向于“选择性限制”，而不是“彻底关闭”。就像我前面给出的代码，它允许已登录用户（特别是管理员）继续使用REST API，这对于WordPress的日常管理和内容创作至关重要。
彻底关闭意味着你的网站将完全切断与所有REST API相关的交互。这听起来很安全，但实际上，它可能会导致Gutenberg编辑器无法正常工作（因为Gutenberg大量依赖REST API来加载和保存内容）、一些插件（比如某些表单插件、页面构建器、缓存插件的高级功能）可能会罢工，甚至一些主题的动态功能也会失效。这就像为了防止小偷，干脆把家里的所有门窗都焊死，结果自己也进不去了。对于一个现代的WordPress网站来说，这几乎是不可行的。
而选择性限制则更为灵活和实用。你可以根据自己的需求来定制：
- 只允许已登录用户访问： 这是最常见的做法，也是我推荐的。它保证了网站的后端管理不受影响，同时阻止了匿名用户对API的探测。
-
禁用特定的API端点： 比如，你可能只想禁用用户枚举端点（
/wp/v2/users
），而保留其他端点。这可以通过更精细的过滤器实现。 - 基于IP地址限制： 结合服务器配置（如Nginx或Apache），你可以只允许特定IP地址访问REST API，这对于内部应用或特定合作伙伴非常有用。
在我看来，选择性限制是一种更成熟、更可持续的策略。它在安全性和可用性之间找到了一个平衡点，既能提升安全性，又不至于让网站变得难以管理或功能缺失。毕竟，网站是用来用的，不是用来供起来的。
禁用REST API可能带来哪些问题？
我必须承认，禁用WordPress的REST API并非没有代价，尤其是在不了解其依赖关系的情况下盲目操作。这就像你拆掉一个你觉得不用的零件，结果发现整个机器都停摆了。
最直接且普遍的问题，就是Gutenberg编辑器（块编辑器）的故障。Gutenberg深度依赖REST API进行内容的加载、保存、块的预览、媒体库的访问等等。如果你彻底禁用了REST API，你会发现编辑器根本无法加载，或者保存文章时出现错误。这对于日常的内容创作来说，简直是灾难性的。
其次，许多现代的WordPress插件和主题会受到影响。现在很多插件不再是简单的PHP脚本，它们会利用REST API进行数据交互，比如：
- 表单插件： 某些高级表单插件可能会通过REST API提交数据。
- 页面构建器： Elementor、Beaver Builder等页面构建器在编辑模式下，也可能利用REST API加载模板、保存布局。
- 电子商务插件： 像WooCommerce这样的插件，虽然核心功能不完全依赖REST API，但其某些扩展或外部集成可能会用到。
- 缓存插件： 某些缓存插件在清理缓存或预加载内容时，也可能通过REST API与WordPress核心交互。
还有，如果你有移动应用程序或者第三方服务（比如Zapier、IFTTT）与你的WordPress网站集成，并且它们是通过REST API进行数据同步的，那么禁用API将直接导致这些集成失效。你的网站将变成一个“孤岛”，无法与外部世界进行数据交换。
所以，在决定禁用REST API之前，我通常会先问自己几个问题：我的网站是否使用了Gutenberg？我有没有安装依赖REST API的插件或主题？我是否需要与外部应用进行数据交互？如果答案是肯定的，那么我就会倾向于采用前面提到的“选择性限制”策略，而不是一刀切地全部禁用。这能避免很多不必要的麻烦，也能让网站的功能保持完整。
