这是一个非常糟糕的安全漏洞，你将不得不面对这些问题：

您的端点将always 工作，即使您的插件被停用，或者您切换主题，您的端点也将在多站点安装的所有站点上处于活动状态，而不仅仅是您打算安装它的站点，这可能会导致端点在不打算使用的地方使用，文件将很脆弱，移动您的插件文件夹，或者将插件放入mu-plugins 将导致端点出现500个致命错误，您需要自己实现所有身份验证和验证，缓存插件将无法与端点交互，从而减慢常见请求的速度anything 它可能会回来anything如果说主题和插件中的独立端点存在安全风险，那就太轻描淡写了，无论是AJAX处理程序还是表单处理程序，甚至是图像的独立文件（timthumb做到了这一点，甚至原始开发人员也因为其安全声誉而否认了这一点）

您可以使用更好的WP-AJAX-API，但需要您自己实现任何身份验证或清理检查，并且有一些怪癖。它也不提供结构，因为对于标准端点，它可以接收任何内容并返回任何内容（如果返回的话）。

相反，请将REST API用于register_rest_route, 它更易于使用，有更少的怪癖，并为您处理身份验证。它还为您提供了更友好的URL和命名空间，例如：

function tomjn_rest_test() {
        return "moomins";
}
add_action( \'rest_api_init\', function () {
        register_rest_route( \'tomjn/v1\', \'/test/\', array(
                \'methods\' => \'GET\',
                \'callback\' => \'tomjn_rest_test\'
        ) );
} );

您可以在以下位置看到：

https://tomjn.com/wp-json/tomjn/v1/test

有了这个，我可以做很多事情：

指定用户必须登录，并确切说明他们需要什么才能做到这一点指定参数分别指定每个参数的类型和消毒剂指定是否需要它们指定端点是用于读写还是两者都由为core编写的代码处理。当然，您可以在每个WP AJAX处理程序中手动实现所有这些，但这要简洁得多，经过测试（WP社区中很少有人有足够的经验来正确实现这一点），例如，让我的上述端点仅对管理员可用：

register_rest_route( \'tomjn/v1\', \'/test/\', array(
    \'methods\' => \'GET\',
    \'callback\' => \'tomjn_rest_test\',
    \'permission_callback\' => function( $req ) {
        return current_user_can(\'manage_options\');
    }
) );

作为奖励，它使某些最佳实践更易于使用，例如返回数据而不是HTML，使用标准HTTP GET PUT POST等，并返回可以验证的JSON响应

端点始终处于活动状态有什么不好

前面我提到，本机端点处于活动状态，即使其内部的插件被禁用。关闭它的唯一方法是通过内部检查或删除文件。为什么这么糟糕？

问题的关键是，在一种情况下可能合适的，在另一种情况下可能不合适。

例如，场景1：

管理员安装一个插件，允许用户在前端登录和注册，而无需刷新页面。为此，插件有一个端点来创建用户。然而，管理员意识到注册并不是他们想要的，只是登录，并停用插件。但是，文件仍然存在，用户仍然可以加载端点以创建新用户。

场景2：

多站点安装中使用了一个插件，通过联系人表单向博客管理员发送电子邮件。这一切都如期进行，但网站上还有其他博客对这一功能不感兴趣。通过更改博客所使用的域，攻击者可以向这些其他博客的管理员发送电子邮件，方法是在网络上其他博客的上下文中加载联系人表单使用的端点，向在多站点安装中任何位置具有管理员角色的任何人发送电子邮件

场景3：

插件有一个有用的调试功能，允许用户更改他们的电子邮件，但出于安全原因，您已关闭此功能。但是，处理电子邮件更改表单的端点是一个独立的文件，任何知道表单如何构建的人都可以更改其电子邮件