REST API часто отключают «на всякий случай», а потом ловят поломку редактора блоков, автосохранения, поиска по сайту или фронтенд-виджетов, которые ходят в /wp-json/. Правильная задача здесь не в полном отключении API, а в ограничении доступа для гостей там, где он действительно не нужен.
Если сайт не использует публичные REST-эндпоинты, можно закрыть их для неавторизованных пользователей и оставить доступ для админки, редактора и внутренних запросов. Ниже — рабочая схема с диагностикой, кодом и проверкой результата.
Когда REST API лучше ограничить, а когда не трогать
REST API нужен не только для внешних интеграций. Его используют Gutenberg, некоторые формы, фильтры, темы с AJAX-подгрузкой, плагины поиска и даже отдельные блоки в админке. Поэтому перед изменениями важно понять, что именно обращается к API.
Типичные признаки, что API используется на сайте
- в консоли браузера есть запросы к
/wp-json/; - в редакторе блоков не работают автосохранение или загрузка метаданных;
- на фронтенде перестают работать фильтры, поиск, подгрузка постов;
- в логах появляются ошибки 401/403 на REST-запросах.
Диагностика: что именно ломается
Сначала проверьте, есть ли реальные обращения к REST API. Откройте страницу сайта, затем DevTools → Network и отфильтруйте запросы по wp-json. Если запросы идут только из админки, ограничение для гостей обычно безопасно. Если же фронтенд активно использует API, нужен более точечный подход.
Ещё один быстрый тест — открыть публичный адрес /wp-json/ в браузере. Если сайт отдаёт структуру маршрутов, это нормально. Сам по себе ответ не означает проблему. Важен вопрос: кто и зачем этим пользуется.
Пошаговое решение: закрыть REST API для неавторизованных
Самый предсказуемый вариант — добавить фильтр rest_authentication_errors. Он позволяет заблокировать REST-запросы для гостей и не мешать авторизованным пользователям.
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 )
);
} );Такой код лучше размещать в дочерней теме или в небольшом mu-plugin, а не в основной теме. Тогда ограничение не исчезнет после обновления шаблона.
Если нужно оставить часть эндпоинтов открытыми
Иногда полностью закрывать API нельзя: например, если публичный фронтенд-плагин использует конкретный маршрут. В этом случае можно разрешить только нужные пути, а остальные блокировать.
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'] ) : '';
if ( strpos( $request_uri, '/wp-json/myplugin/v1/public-data' ) !== false ) {
return $result;
}
return new WP_Error(
'rest_forbidden',
__( 'REST API закрыт для гостей.', 'textdomain' ),
array( 'status' => 401 )
);
} );Это не идеальный универсальный шаблон, но для точечной задачи он работает. Если у вас несколько публичных маршрутов, список лучше вынести в массив и проверять по нему.
Сравнение подходов: плагин, код, частичное ограничение
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
| Плагин для безопасности | Ограничивает REST вместе с другими функциями | Быстро включить, меньше ручного кода | Может затронуть лишнее, сложнее понять причину блокировки |
Код через rest_authentication_errors | Блокирует REST для гостей | Контроль на уровне логики, легко откатить | Нужно аккуратно проверить зависимости |
| Частичное разрешение маршрутов | Оставляет только нужные эндпоинты | Минимум побочных эффектов | Требует списка используемых маршрутов |
Как проверить, что ограничение сработало
После внедрения откройте публичный адрес /wp-json/ в режиме инкогнито. Для гостя должен возвращаться ответ с ошибкой 401 или 403, в зависимости от выбранной логики. Затем проверьте вход в админку и редактор записей: они должны работать как раньше.
Дальше обязательно пройдитесь по фронтенду:
- откройте главную страницу и несколько внутренних;
- проверьте формы, поиск, фильтры и AJAX-подгрузку;
- создайте или отредактируйте запись в Gutenberg;
- посмотрите консоль браузера на наличие ошибок REST.
Если сайт использует кэш, очистите его после изменений. Иначе можно увидеть старое поведение и сделать ложный вывод, что код не работает.
Частые ошибки и как их исправить
Полностью отключили REST API через жёсткий редирект
Иногда пытаются блокировать /wp-json/ на уровне .htaccess или nginx без разбора. Это опасно: редактор блоков, некоторые плагины и внутренние запросы могут перестать работать. Если нужна защита, используйте фильтр WordPress, а не грубую блокировку URL.
Сломали фронтенд-плагины, которые читают данные через API
Если после ограничения перестали работать фильтры каталога, лента записей или поиск, значит, один из плагинов использует публичный маршрут. Найдите запрос в Network и добавьте исключение только для него, а не возвращайте открытый API целиком.
Проверяли только в админке
Админка может работать нормально, а гости уже получают 401 на нужных страницах. Проверять нужно именно в режиме неавторизованного пользователя и на реальных страницах сайта.
Вставили код в тему и забыли про обновления
После смены темы ограничение исчезнет. Для технических правил безопасности лучше использовать mu-plugin или отдельный мини-плагин. Так правило живёт независимо от дизайна.
Практические советы по безопасности и производительности
Ограничение REST API не заменяет нормальную защиту сайта. Если цель — уменьшить поверхность атаки, проверьте ещё и права пользователей, актуальность плагинов, наличие двухфакторной аутентификации и логи авторизации. А если задача — ускорить сайт, не ждите от этого шага чудес: REST API сам по себе редко является главным тормозом.
Если вы чистите сайт от лишних технических поверхностей, полезно смотреть на проблему шире: дубли, ненужные эндпоинты, лишние публичные маршруты и тяжёлые плагины часто дают больший эффект, чем точечная блокировка одного URL. Для комплексной технической чистки иногда удобнее использовать инструменты вроде Clearfy Pro, но только там, где реально нужен набор связанных настроек, а не один отдельный фикс.
Короткий чек-лист перед публикацией изменения
- Проверить, использует ли сайт публичные REST-запросы.
- Добавить ограничение через
rest_authentication_errors, а не через грубую блокировку URL. - Проверить фронтенд в инкогнито.
- Проверить редактор блоков и автосохранение.
- Очистить кэш после внедрения.
- Сохранить код вне основной темы, если правило должно жить долго.
Если после ограничения всё работает, значит, вы закрыли REST API для гостей без лишних побочных эффектов. Если что-то сломалось, почти всегда проблема не в самом фильтре, а в том, что сайт уже зависел от публичного маршрута, о котором забыли на этапе диагностики.