REST API в WordPress нужен не только для внешних интеграций. Его активно использует сам редактор блоков, часть плагинов, мобильные приложения и некоторые темы. Поэтому грубое отключение через фильтры «на весь сайт» часто заканчивается странными ошибками в админке, неработающим автосохранением или поломанными виджетами на фронтенде.
Если задача не в том, чтобы «вырубить всё», а в том, чтобы убрать лишнюю поверхность атаки и закрыть публичные запросы для гостей, подход должен быть точечным: ограничить доступ к REST API для неавторизованных пользователей, но оставить его для админки и нужных внутренних сценариев.
Когда REST API мешает и что именно нужно ограничивать
Типичный запрос выглядит так: в логах много обращений к /wp-json/, сканеры показывают открытые маршруты, а владелец сайта хочет снизить шум и убрать лишнюю публичную информацию. Это нормальная задача, но важно понимать границу. Полное отключение REST API почти всегда избыточно. В большинстве случаев достаточно запретить доступ гостям к стандартным маршрутам и оставить авторизованные запросы.
Что ломается при слишком жёстком отключении
Если просто вернуть ошибку на все REST-запросы, можно задеть:
- редактор блоков Gutenberg;
- автосохранение записей;
- AJAX-логики некоторых плагинов, которые ходят в REST;
- внешние интеграции, если они работают от имени авторизованного пользователя.
Поэтому сначала стоит проверить, кто именно делает запросы и какие маршруты реально используются.
Диагностика: какие запросы к REST API идут на сайте
Перед изменениями посмотрите, есть ли у сайта реальные потребители REST API. Самый простой способ — открыть консоль браузера в админке и проверить запросы при редактировании записи. Если при сохранении или загрузке блока появляются ошибки rest_cookie_invalid_nonce или 401, значит, где-то уже есть проблема с авторизацией или конфликтом плагинов.
На сервере полезно посмотреть логи веб-сервера или WAF. Если много обращений к /wp-json/wp/v2/posts, /wp-json/wp/v2/pages и похожим маршрутам от гостей, это уже хороший повод ограничить доступ.
Ещё один практический тест — открыть в браузере адрес /wp-json/ в режиме инкогнито. Если API отдаёт подробный список маршрутов без ограничений, это не всегда уязвимость, но это лишняя информация, которую можно сократить.
Как ограничить REST API для гостей без поломки админки
Самый безопасный вариант — не отключать API полностью, а блокировать его только для неавторизованных пользователей. Для этого можно использовать фильтр rest_authentication_errors. Он срабатывает рано и позволяет вернуть ошибку до выполнения маршрута.
<?php
add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
if ( is_user_logged_in() ) {
return $result;
}
// Разрешаем только системные запросы, если они нужны вашему сайту.
$allowed_routes = array(
'/wp/v2/types',
'/wp/v2/taxonomies',
);
$request_uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';
foreach ( $allowed_routes as $route ) {
if ( false !== strpos( $request_uri, $route ) ) {
return $result;
}
}
return new WP_Error(
'rest_forbidden',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
} );Этот вариант лучше, чем отключение через rest_enabled или агрессивные плагины, потому что он не ломает весь стек сразу. Но у него есть нюанс: если у вас есть фронтенд-компоненты, которые завязаны на публичные REST-запросы, их нужно отдельно проверить.
Если нужен более мягкий режим
Иногда достаточно не закрывать API целиком, а скрыть только часть маршрутов. Например, можно запретить доступ к пользовательским данным и оставить публичные типы записей. Тогда логика будет строиться не на полном запрете, а на проверке маршрута.
<?php
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( is_user_logged_in() ) {
return $endpoints;
}
unset( $endpoints['/wp/v2/users'] );
unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
return $endpoints;
} );Такой подход полезен, если цель — убрать перечисление пользователей и часть служебных данных, но не мешать редактору и публичным запросам.
Сравнение подходов: плагин, код, серверный уровень
| Подход | Что даёт | Компромисс |
|---|---|---|
| Плагин | Быстрое включение/выключение без правки кода | Может закрыть лишнее и сломать редактор или интеграции |
| Код через фильтры | Точный контроль над доступом | Нужно тестировать маршруты и авторизацию |
| Серверный запрет | Снижает нагрузку и шум в логах | Легко задеть нужные запросы, если правила слишком общие |
Если нужен именно технический контроль, код обычно надёжнее. Плагин уместен, когда на сайте нет сложных интеграций и нужен быстрый результат без разработки.
Пошаговое решение: безопасный сценарий внедрения
- Сделайте резервную копию файлов и базы.
- Проверьте, использует ли сайт Gutenberg, формы, фронтенд-виджеты или внешние сервисы, которые ходят в REST API.
- Добавьте ограничение только для гостей, а не глобальное отключение.
- Откройте админку, создайте/обновите запись и проверьте автосохранение.
- Проверьте
/wp-json/в инкогнито и убедитесь, что лишние маршруты недоступны. - Посмотрите логи на предмет новых ошибок
401и403.
Как проверить, что решение сработало
Проверка должна быть не формальной, а прикладной. Откройте сайт в инкогнито и попробуйте обратиться к /wp-json/wp/v2/posts. Если вы ограничивали доступ для гостей, запрос должен вернуть ошибку авторизации или пустой ответ в зависимости от вашей реализации.
Затем зайдите в админку под обычной учётной записью редактора или администратора и проверьте:
- открытие редактора записей;
- автосохранение;
- публикацию и обновление записи;
- работу блоков, которые подгружают данные через REST API.
Если после изменения кода редактор начал выдавать ошибку сохранения, значит, вы слишком широко перекрыли маршруты или сломали nonce-проверку. В таком случае сначала откатите правку и сузьте список ограничений.
Частые ошибки и как их исправить
Отключают REST API через общий запрет на /wp-json/
Это самая частая ошибка. Снаружи кажется, что всё просто: запретили URL — и проблема решена. На практике это часто ломает редактор и плагины. Исправление одно: ограничивать доступ через WordPress-фильтры, а не грубым блоком всего пути.
Не проверяют фронтенд-скрипты
Некоторые темы и плагины используют REST API для подгрузки контента, фильтров, поиска или счётчиков. После ограничения доступа такие элементы могут перестать работать без видимой ошибки. Перед внедрением проверьте, есть ли на сайте динамические блоки.
Оставляют открытыми пользовательские маршруты
Даже если вы закрыли стандартные маршруты, пользовательские endpoints от плагинов могут остаться доступными. Если цель — уменьшить поверхность атаки, нужно отдельно проверить, что регистрируют установленные плагины.
Путают безопасность и индексацию
REST API — это не только SEO-вопрос. Закрытие маршрутов не заменяет настройку robots.txt, noindex или защиту админки. Если цель — убрать дубли и мусор из индекса, нужны отдельные решения. Если цель — снизить риск и шум, тогда REST API можно ограничивать, но аккуратно.
Практические советы по безопасности и производительности
Если на сайте много ботов и лишних обращений к REST API, ограничение для гостей может немного снизить шум в логах и сократить количество бесполезных запросов. Но не стоит ждать от этого чудес по скорости. Это скорее точечная мера безопасности и гигиены, чем полноценная оптимизация производительности.
Для сайтов с большим количеством контента и технических настроек полезно держать под рукой инструменты, которые помогают чистить лишние сущности и управлять техническими параметрами без ручной правки каждого файла. Например, в Clearfy Pro есть набор настроек для технической чистки WordPress, но даже с такими инструментами логику доступа к REST API лучше проверять отдельно на вашем сайте.
Если вы вносите код в functions.php, не забывайте, что обновление темы может его затереть. Для таких правок безопаснее использовать дочернюю тему или небольшой mu-plugin.
Когда REST API лучше не трогать
Если сайт активно использует блоковый редактор, headless-часть, внешние приложения или сложные интеграции, полное ограничение REST API для гостей может принести больше проблем, чем пользы. В таких проектах разумнее закрывать только конкретные маршруты, а не весь механизм целиком.
Практический ориентир простой: если вы не можете быстро перечислить, какие запросы идут в REST API и кто их делает, не начинайте с полного отключения. Сначала соберите картину, потом режьте только лишнее.