Как отключить REST API в WordPress без поломки редактора и внешних интеграций

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

Если задача именно в сокращении поверхности атаки или в закрытии лишних публичных эндпоинтов, лучше не рубить REST API целиком, а сначала понять, кто его вызывает. В большинстве случаев достаточно ограничить доступ к неавторизованным запросам и оставить рабочие сценарии для админки и доверенных интеграций.

Когда REST API действительно мешает

Типичный сценарий — сайт не использует headless-архитектуру, внешние приложения и публичные JSON-эндпоинты не нужны, а в логах видно много запросов к /wp-json/. Иногда это просто сканеры. Иногда — плагины, которые получают данные через REST, и вот здесь отключение «в лоб» ломает функциональность.

Перед изменениями проверьте, что именно использует API:

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

Диагностика: что ломается первым

Если REST API закрыть полностью, чаще всего страдают не «какие-то абстрактные функции», а вполне конкретные вещи:

• блок-редактор Gutenberg может начать выдавать ошибки при загрузке данных;
• плагины форм и виджетов перестают подтягивать конфигурацию или отправлять данные;
• мобильные приложения и внешние сервисы теряют доступ к контенту;
• часть тем и конструкторов получает ошибки при AJAX/REST-запросах.

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

Рабочие варианты: что выбрать

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

Пошаговое решение: закрыть REST API для гостей

Ниже вариант, который не ломает авторизованных пользователей в админке, но режет доступ к REST для неавторизованных посетителей. Это не универсальная панацея, но для обычного сайта часто достаточно.

<?php
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }

    if ( is_user_logged_in() ) {
        return $result;
    }

    return new WP_Error(
        'rest_forbidden',
        __( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
        array( 'status' => 401 )
    );
} );

Куда вставлять: в functions.php дочерней темы или, лучше, в отдельный mu-plugin. Для production-сайта mu-plugin удобнее: код не потеряется при смене темы.

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

<?php
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }

    $request_uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';

    if ( false !== strpos( $request_uri, '/wp-json/myplugin/v1/webhook' ) ) {
        return $result;
    }

    if ( is_user_logged_in() ) {
        return $result;
    }

    return new WP_Error( 'rest_forbidden', 'REST API закрыт для гостей.', array( 'status' => 401 ) );
} );

Если нужен более мягкий вариант

Иногда достаточно не блокировать API целиком, а скрыть только лишние маршруты или ограничить доступ к отдельным типам данных. Это уже зависит от конкретного плагина или темы. В таком случае лучше искать фильтры самого плагина, а не пытаться решить всё одним глобальным хуком.

Проверка результата после внедрения

После правки важно проверить не только главную страницу, но и сценарии, которые обычно всплывают позже.

• Откройте /wp-json/ в браузере без авторизации: должен быть отказ или ограниченный ответ, если вы так настроили.
• Проверьте вход в админку и открытие редактора записей.
• Создайте/отредактируйте запись в Gutenberg и убедитесь, что блоки загружаются без ошибок.
• Проверьте формы, поиск, комментарии и интеграции, которые были подключены к сайту.
• Посмотрите консоль браузера: нет ли ошибок 401/403 на нужных запросах.

Если что-то сломалось, не ищите проблему сразу в теме. Чаще всего конфликтует конкретный плагин, который ожидал публичный REST-запрос.

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

Полностью отключили REST API и потеряли редактор

Это самая частая ошибка. Блок-редактор и часть админских сценариев используют REST. Решение — не отключать всё целиком, а ограничить доступ для гостей или настроить исключения.

Сломали интеграцию формы или вебхук

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

Проверяли только главную страницу

Это плохая проверка. Ошибки часто видны только в редакторе, на странице с формой или в личном кабинете. Тестируйте именно те шаблоны и сценарии, которые используются на сайте.

Вставили код в активную тему

После обновления темы правка исчезнет. Для постоянной защиты лучше использовать mu-plugin или отдельный мини-плагин.

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

Если цель — не «спрятать WordPress», а уменьшить лишний шум, полезнее сочетать несколько мер:

• закрыть REST API для гостей, если он не нужен публично;
• не отключать то, что использует админка и редактор;
• проверить, не отдают ли плагины лишние данные в публичных маршрутах;
• смотреть логи и убирать неиспользуемые интеграции.

Если вы уже используете инструменты для технической чистки сайта, например Clearfy Pro, проверьте, нет ли там готовых настроек по REST API и смежным оптимизациям. Но даже в этом случае полезно понимать, какой именно сценарий вы закрываете и что останется доступным.

Главная идея простая: REST API не нужно отключать «по привычке». Его стоит ограничивать только после проверки зависимостей. Тогда вы получите меньше лишних запросов и не сломаете то, что реально используется на сайте.