Как отключить REST API для гостей в WordPress без поломки админки и плагинов

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

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

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

Полное отключение REST API редко бывает хорошей идеей. На практике его ограничивают в трёх сценариях:

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

Если у вас работает редактор блоков, формы с AJAX, поиск по сайту через REST или интеграция с внешним сервисом, сначала нужно понять, кто и что вызывает. Иначе вы получите «защиту», после которой редактор начнёт сыпать ошибками в консоли.

Диагностика: что именно использует REST API

Начните с проверки в браузере и в логах. Откройте главную страницу и админку, затем посмотрите запросы в DevTools → Network. Ищите обращения к /wp-json/, admin-ajax.php и запросы, которые возвращают JSON.

Если есть доступ к серверным логам, полезно посмотреть, кто чаще всего стучится в REST. Это поможет отличить нормальную активность от мусорного трафика.

# Пример для Apache/Nginx access log: ищем обращения к REST API
grep '/wp-json/' access.log | tail -n 50

Для проверки на стороне WordPress можно временно включить логирование в wp-config.php, если оно у вас ещё не включено:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

После этого откройте проблемные страницы и посмотрите wp-content/debug.log. Если какой-то плагин или тема делает REST-запросы с ошибками, это обычно видно сразу.

Как отключить REST API только для гостей

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

Вариант через код в mu-plugin или functions.php

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

<?php
/**
 * Plugin Name: Restrict REST API for guests
 */

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) ) {
        return $result;
    }

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

    // Разрешаем только служебные маршруты, если они нужны.
    $uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';

    if ( strpos( $uri, '/wp-json/wp/v2/types' ) !== false ) {
        return $result;
    }

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

Этот пример намеренно простой. В реальном проекте лучше не ориентироваться только на REQUEST_URI, а разрешать конкретные маршруты через список. Так проще контролировать, что именно остаётся открытым.

Более аккуратный вариант с белым списком маршрутов

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

<?php
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) || is_user_logged_in() ) {
        return $result;
    }

    $request_uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';
    $allowed = array(
        '/wp-json/wp/v2/posts',
        '/wp-json/wp/v2/pages',
        '/wp-json/my-plugin/v1/public-data',
    );

    foreach ( $allowed as $path ) {
        if ( strpos( $request_uri, $path ) !== false ) {
            return $result;
        }
    }

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

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

Сравнение подходов: плагин, код или серверный фильтр

Если задача техническая, выбор обычно сводится к трём вариантам. У каждого есть компромисс.

Для большинства сайтов WordPress достаточно кодового ограничения на уровне rest_authentication_errors. Серверный запрет имеет смысл только если вы уверены, что публичные REST-маршруты не используются вообще.

Если нужен запрет на уровне Nginx

Этот вариант стоит применять осторожно. Он не знает ничего о логике WordPress и просто режет запросы по пути. Если вы ошибётесь с условием, можно случайно заблокировать полезные маршруты.

location ~* ^/wp-json/ {
    if ($request_uri !~* "^/wp-json/wp/v2/posts|^/wp-json/wp/v2/pages") {
        return 403;
    }
}

На практике лучше не усложнять конфиг сервера, если нет жёсткой необходимости. Гораздо проще и безопаснее управлять доступом в WordPress-коде, где можно учитывать авторизацию и конкретные маршруты.

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

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

• откройте фронтенд в режиме инкогнито и убедитесь, что публичные страницы грузятся без ошибок;
• зайдите в админку и откройте редактор блоков;
• проверьте консоль браузера на ошибки запросов к /wp-json/;
• если есть формы, поиск или фильтры, протестируйте их отдельно;
• посмотрите wp-content/debug.log и серверные логи на новые 401/403.

Хороший признак — в браузере для гостя REST-запросы получают 401 или 403 там, где это ожидается, а в админке и у авторизованных пользователей всё работает как раньше.

Что проверить в редакторе и в плагинах

Особое внимание уделите Gutenberg и плагинам, которые подгружают данные через REST. Если после ограничения редактор не сохраняет записи, не подгружаются шаблоны или ломается предпросмотр, значит, вы закрыли слишком много.

В таком случае не откатывайте всё целиком. Сначала расширьте белый список маршрутов и проверьте снова. Обычно проблема решается точечным разрешением нужного эндпоинта.

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

Ошибка: отключили REST API через общий security-плагин

Некоторые плагины безопасности предлагают «полностью отключить REST API». Это удобно на бумаге, но на практике часто ломает админку или интеграции. Если после включения такой опции редактор начал выдавать ошибки, отключите глобальный запрет и перейдите на точечное ограничение для гостей.

Ошибка: проверяют только главную страницу

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

Ошибка: режут запросы по слишком общему условию

Если в Nginx или в коде блокировать всё, что содержит /wp-json/, можно случайно закрыть нужные маршруты. Всегда начинайте с белого списка, а не с тотального запрета.

Ошибка: вносят код в тему

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

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

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

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

Если вы параллельно чистите сайт от технического мусора, полезно смотреть на проблему шире: иногда проще убрать лишний функционал, чем бесконечно защищать его фильтрами. В таких задачах иногда помогает Clearfy Pro, если нужен набор точечных настроек для SEO и технической чистки сайта, но сам принцип остаётся тем же: сначала диагностика, потом точечное ограничение, затем проверка.

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