Как найти и отключить лишние REST endpoint’ы в WordPress без поломки сайта

REST API в WordPress часто включён не только для редактора и штатных сценариев, но и для плагинов, темы и внешних интеграций. Проблема обычно не в самом API, а в лишних endpoint’ах: они увеличивают поверхность атаки, засоряют карту доступных маршрутов и иногда светят лишние данные. Если задача не «выключить всё», а убрать только ненужное, нужен точечный подход.

Когда это действительно проблема

Сначала стоит понять, что именно вас беспокоит. Если сайт работает на Gutenberg, использует мобильное приложение WordPress, headless-фронтенд или интеграции с CRM, полностью закрывать REST API нельзя. Но можно убрать отдельные маршруты, которые не нужны в вашей конфигурации: например, публичные endpoint’ы плагинов, служебные маршруты темы или старые интеграции, которые больше не используются.

Типичные признаки:

• в /wp-json/ видны маршруты плагинов, которые вы давно отключили логически, но они всё ещё регистрируются;
• в ответах REST API есть данные, которые не должны быть доступны гостям;
• сканеры безопасности показывают лишние публичные endpoint’ы;
• после установки плагина количество маршрутов резко выросло, а вы не понимаете, что из этого реально нужно.

Диагностика: какие endpoint’ы вообще зарегистрированы

Самый надёжный способ — посмотреть список маршрутов через сам WordPress. Для этого удобно временно вывести результат rest_get_server()->get_routes() в админке или в лог. Ниже пример, который показывает все маршруты только пользователю с правом manage_options.

add_action('admin_notices', function () {
    if (!current_user_can('manage_options')) {
        return;
    }

    if (!isset($_GET['show_rest_routes'])) {
        return;
    }

    $server = rest_get_server();
    if (!$server) {
        echo '<div class="notice notice-error"><p>REST server недоступен.</p></div>';
        return;
    }

    $routes = array_keys($server->get_routes());
    echo '<div class="notice notice-info" style="max-height:300px;overflow:auto"><pre>' . esc_html(implode("\n", $routes)) . '</pre></div>';
});

После этого откройте /wp-admin/?show_rest_routes=1 и посмотрите список. Ищите маршруты, которые явно относятся к неиспользуемым плагинам, старым интеграциям или служебным функциям темы. Если маршрут нужен редактору, формам, поиску или синхронизации данных, его лучше не трогать.

Как отключить конкретный REST endpoint

Для точечного удаления маршрута используется фильтр rest_endpoints. Это штатный механизм WordPress: он позволяет убрать один или несколько маршрутов из списка до того, как они станут доступны извне. Важно не удалять всё подряд, а работать с конкретными ключами массива.

Пример: допустим, вам не нужен публичный маршрут /wp-json/wp/v2/users, который часто используют для перечисления пользователей. Его можно убрать для гостей, оставив админские сценарии нетронутыми.

add_filter('rest_endpoints', function ($endpoints) {
    if (!is_array($endpoints)) {
        return $endpoints;
    }

    if (!is_user_logged_in()) {
        unset($endpoints['/wp/v2/users']);
        unset($endpoints['/wp/v2/users/(?P<id>[\\d]+)']);
    }

    return $endpoints;
});

Если нужно убрать endpoint плагина, сначала найдите точный ключ маршрута в списке, а потом удаляйте только его. Не используйте размытые проверки по подстроке без необходимости: так легко снести соседние маршруты и получить неочевидную поломку.

Отключение маршрутов по namespace

Иногда удобнее убрать целый namespace, если вы точно знаете, что он не нужен. Но это уже более грубый инструмент. Например, если плагин регистрирует собственный набор маршрутов в /my-plugin/v1, можно удалить все ключи, начинающиеся с этого префикса.

add_filter('rest_endpoints', function ($endpoints) {
    foreach (array_keys($endpoints) as $route) {
        if (strpos($route, '/my-plugin/v1') === 0) {
            unset($endpoints[$route]);
        }
    }

    return $endpoints;
});

Такой подход полезен, когда плагин больше не используется, но его код всё ещё загружается из-за зависимостей темы или автозагрузки. Если же плагин нужен частично, лучше удалять только конкретные маршруты, а не весь namespace.

Сравнение подходов

Если endpoint нужен, но не для гостей

Иногда маршрут нельзя удалять, потому что он используется внутри сайта, но для внешних запросов он должен быть закрыт. В этом случае лучше не трогать регистрацию маршрута, а ограничить доступ через permission_callback или проверку прав внутри callback’а. Это правильнее, чем удалять endpoint и потом пытаться «обойти» его с фронтенда.

Пример собственного REST endpoint, доступного только редакторам и выше:

add_action('rest_api_init', function () {
    register_rest_route('site/v1', '/stats', [
        'methods'  => 'GET',
        'callback' => function () {
            return rest_ensure_response([
                'posts' => wp_count_posts('post')->publish,
            ]);
        },
        'permission_callback' => function () {
            return current_user_can('edit_others_posts');
        },
    ]);
});

Если вы правите код плагина, не забывайте, что обновление может перезаписать изменения. Для собственного сайта безопаснее вынести логику в mu-plugin или в дочернюю тему, если это действительно связано с темой.

Пошаговое решение без лишнего риска

1. Соберите список маршрутов через rest_get_server()->get_routes().
2. Отметьте только те endpoint’ы, которые не используются редактором, формами, интеграциями и фронтендом.
3. Сначала протестируйте отключение на staging-копии.
4. Добавьте фильтр rest_endpoints и удалите один маршрут за раз.
5. Проверьте, что админка, редактор и внешние интеграции продолжают работать.
6. Зафиксируйте изменения в коде, а не в настройках плагина, если нужен предсказуемый результат.

Как проверить, что решение сработало

Проверка должна быть не только визуальной. Откройте URL маршрута напрямую и посмотрите код ответа. Если endpoint удалён корректно, WordPress вернёт rest_no_route или 404 для этого маршрута. При этом другие маршруты должны продолжать отвечать нормально.

Что проверить вручную:

• /wp-json/ больше не показывает удалённый маршрут;
• прямой запрос к endpoint возвращает ошибку маршрута, а не данные;
• редактор записей открывается без ошибок;
• формы, поиск, комментарии и интеграции не потеряли связь с REST API;
• в логах нет новых PHP warnings после правки.

Если у вас есть доступ к командной строке, можно быстро проверить ответ так:

curl -I https://example.com/wp-json/wp/v2/users

Для удалённого endpoint ожидаем не успешный ответ с данными, а ошибку маршрута или запрет доступа — в зависимости от того, как именно вы его ограничили.

Частые ошибки и как их исправить

Удаляют не тот маршрут

Проблема почти всегда в том, что ключ маршрута в rest_endpoints не совпадает с тем, что виден в браузере. В массиве используется именно внутренний путь, а не красивый URL из адресной строки. Сначала смотрите список через get_routes(), потом вносите правку.

Ломают редактор Gutenberg

Редактор активно использует REST API. Если удалить слишком много маршрутов или закрыть доступ без проверки, редактор перестанет загружать данные. В таком случае откатите изменения и оставьте только те endpoint’ы, которые точно не участвуют в работе админки.

Пытаются отключить REST API через robots.txt

Это не работает. robots.txt не закрывает доступ к endpoint’ам, он только даёт указания поисковым роботам. Для безопасности нужен код, который реально убирает маршрут или ограничивает доступ на уровне WordPress.

Правят плагин напрямую

После обновления изменения исчезнут. Если маршрут нужно отключить надолго, делайте это в своём коде: в mu-plugin, в дочерней теме или в небольшом кастомном плагине.

Практические советы по безопасности и производительности

Не стоит превращать отключение endpoint’ов в «генеральную уборку» без учёта зависимостей. Сначала проверьте, кто именно регистрирует маршрут, и нужен ли он для фронтенда, редактора или интеграций. Если маршрут не используется, его удаление может немного сократить поверхность атаки и уменьшить шум в ответах API, но не стоит ожидать чудес по скорости сайта.

Если на сайте много плагинов, полезно периодически пересматривать список REST-маршрутов после обновлений. Новый плагин может добавить несколько endpoint’ов, и часть из них будет лишней для вашей задачи. В таких случаях проще поддерживать короткий whitelist нужных маршрутов, чем потом искать источник лишних данных по всему сайту.

Для сайтов, где важна чистка технического мусора и контроль индексации, иногда удобнее сочетать ручную правку с инструментами вроде Clearfy Pro, но только если вы понимаете, что именно отключаете и зачем. Автоматические настройки не должны заменять проверку конкретных маршрутов.

Если нужен быстрый рабочий процесс, держите под рукой такой чек-лист:

• сначала список маршрутов, потом отключение;
• не трогать маршруты редактора и авторизации без проверки;
• изменения вносить в свой код, а не в чужой плагин;
• после правки проверять /wp-json/ и прямой запрос к endpoint;
• тестировать на staging перед выкладкой на боевой сайт.

Такой подход даёт предсказуемый результат: вы убираете только лишнее, не ломая то, что WordPress и плагины используют каждый день.