Как отключить открытый REST API в WordPress без плагинов

Автор: Алина Ковалева | Опубликовано: 28.02.2026

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

Что такое REST API в WordPress и почему его иногда нужно отключать

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

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

Отключаем REST API для неавторизованных пользователей с помощью фильтра rest_authentication_errors

Самый простой и эффективный способ – использовать фильтр rest_authentication_errors. Он позволяет перехватывать запросы к REST API и возвращать ошибку аутентификации, если пользователь не авторизован.

Добавьте следующий код в файл functions.php вашей темы или в отдельный плагин:

function wprus_disable_rest_api_for_guests( $access ) {
    if ( ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_cannot_access',
            'Доступ к REST API разрешен только авторизованным пользователям.',
            array( 'status' => 401 )
        );
    }
    return $access;
}
add_filter( 'rest_authentication_errors', 'wprus_disable_rest_api_for_guests' );

Этот код проверяет, авторизован ли пользователь. Если нет – возвращает ошибку с кодом 401 (Unauthorized), блокируя доступ к REST API.

Пояснение работы фильтра

Фильтр rest_authentication_errors вызывается при попытке обработать REST запрос. Если функция возвращает объект WP_Error, доступ блокируется. Если возвращается true, REST API отключается полностью. Если false или null — доступ разрешен.

Полное отключение REST API в WordPress

Если вы хотите полностью отключить REST API, включая все конечные точки (endpoints), используйте такой код:

function wprus_disable_rest_api_completely() {
    add_filter( 'rest_authentication_errors', function() {
        return new WP_Error(
            'rest_disabled',
            'REST API отключен на этом сайте.',
            array( 'status' => 403 )
        );
    });

    // Отключаем ссылку на REST API в заголовках HTTP
    remove_action( 'xmlrpc_rsd_apis', 'rest_output_rsd' );
    remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );
    remove_action( 'template_redirect', 'rest_output_link_header', 11 );
}
add_action( 'init', 'wprus_disable_rest_api_completely' );

Этот код возвращает ошибку 403 Forbidden для всех REST запросов и удаляет ссылки на REST API из заголовков страниц, что предотвращает автоопределение REST API клиентами.

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

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

Исключения: как разрешить доступ к определённым REST маршрутам

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

function wprus_restrict_rest_api_with_exceptions( $access ) {
    if ( is_user_logged_in() ) {
        return $access; // Авторизованные пользователи имеют полный доступ
    }

    $allowed_routes = array(
        '/wp/v2/posts',
        '/wp/v2/categories',
        '/wp/v2/tags',
    );

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

    foreach ( $allowed_routes as $route ) {
        if ( strpos( $request_uri, $route ) !== false ) {
            return $access; // Разрешаем доступ к указанным маршрутам
        }
    }

    return new WP_Error(
        'rest_cannot_access',
        'Доступ к REST API разрешен только авторизованным пользователям.',
        array( 'status' => 401 )
    );
}
add_filter( 'rest_authentication_errors', 'wprus_restrict_rest_api_with_exceptions' );

Таким образом, только указанные публичные маршруты будут доступны гостям, а остальные – закрыты.

Проверка работы и отладка

После внесения изменений важно проверить работу REST API. Для этого можно использовать такие инструменты:

Браузер или curl для отправки запросов к https://ваш-сайт.ru/wp-json/
Плагины для тестирования REST API, например, REST API Console
Логи сервера и консоль браузера для отлова ошибок

Если вы видите ошибку 401 или 403 для REST запросов при попытке получить данные без авторизации, значит ограничение работает корректно.

Альтернативные решения и плагины для управления REST API

Если вы предпочитаете использовать готовые решения, на WPSHOP.RU есть несколько плагинов, которые помогут управлять REST API, например, Clearfy Pro. Он позволяет гибко настраивать отключение REST API и других функций для повышения безопасности сайта без необходимости писать код.

Пример настройки Clearfy Pro для ограничения REST API

После установки и активации плагина Clearfy Pro перейдите в раздел Безопасность и включите опцию «Отключить REST API для неавторизованных пользователей». Это позволит быстро и надежно закрыть REST API, сохранив доступ для администраторов и авторизованных пользователей.

Выводы и рекомендации

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

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