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

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

Нормальная задача здесь не в том, чтобы «выключить всё», а в том, чтобы ограничить доступ для гостей и оставить рабочими авторизованные сценарии. Ниже — рабочая схема, как это сделать, как проверить результат и где обычно ломают сайт.

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

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

При этом есть типичные случаи, когда закрывать API нужно аккуратно:

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

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

Перед изменениями полезно понять, кто и зачем обращается к /wp-json/. Самая частая ошибка — отключить доступ для всех неавторизованных запросов, а потом искать, почему в редакторе не подгружаются данные или перестали работать формы.

Проверка в браузере и логах

Откройте сайт и посмотрите запросы в DevTools во вкладке Network. Если видите обращения к /wp-json/ на фронтенде, это уже сигнал: какой-то плагин или тема использует REST для подгрузки данных.

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

Что проверить до внедрения

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

Как закрыть REST API только для гостей

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

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

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

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

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

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

Как оставить рабочими отдельные маршруты

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

<?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_prefixes = array(
        '/wp-json/wp/v2/',
        '/wp-json/oembed/1.0/',
    );

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

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

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

Сравнение подходов: плагин, код, сервер

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

Пошаговое внедрение без сюрпризов

1. Сделайте резервную копию файлов и базы.
2. Проверьте, какие страницы и плагины используют /wp-json/.
3. Добавьте ограничение сначала на staging-копии сайта.
4. Откройте редактор записей и сохраните тестовую запись.
5. Проверьте фронтенд: формы, поиск, фильтры, подгрузку контента.
6. Посмотрите ответы 401 или 403 в Network и убедитесь, что блокируются только лишние запросы.
7. Перенесите изменение на продакшен и снова проверьте логи.

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

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

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

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

Полностью отключили REST API и сломали Gutenberg

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

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

Сделали исключения слишком широкими

Когда в whitelist попадает слишком много маршрутов, защита становится формальной. Например, разрешить все запросы к /wp-json/wp/v2/ — это уже почти публичный API для контента. Для некоторых сайтов это нормально, но решение должно быть осознанным.

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

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

Не учли кэш и CDN

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

Безопасность и производительность: что реально дает ограничение

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

С точки зрения производительности эффект зависит от того, сколько запросов действительно уходило в REST. Если API почти не использовался, разница будет минимальной. Если же у вас были тяжелые публичные endpoint'ы, ограничение может заметно разгрузить PHP и базу.

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

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