REST API в WordPress часто оставляют открытым по умолчанию, а потом удивляются лишним запросам, светящимся эндпоинтам в сканерах и нежелательной выдаче служебных данных. Полностью рубить API на живом сайте нельзя: Gutenberg, часть плагинов и интеграций завязаны на него напрямую. Поэтому задача обычно не в том, чтобы «выключить всё», а в том, чтобы закрыть REST API для гостей и оставить его рабочим для авторизованных пользователей и нужных сценариев.
Ниже — рабочая схема: сначала быстро диагностируем, действительно ли REST API вам мешает, затем ограничиваем доступ аккуратно, проверяем, что редактор и интеграции не сломались, и разбираем типичные ошибки.
Когда REST API лучше ограничить
Не каждый сайт нуждается в полном публичном доступе к REST API. На практике ограничение имеет смысл, если вы видите хотя бы один из этих сценариев:
- в логах много запросов к
/wp-json/от ботов и сканеров; - служебные данные о записях, таксономиях или пользователях доступны без авторизации и вам это не нужно;
- сайт работает как обычный контентный проект без внешнего приложения, которое читает данные через API;
- нужно снизить поверхность атаки без установки тяжёлого security-плагина.
Если у вас редакторы работают в блоковом редакторе, подключён мобильный клиент, headless-фронтенд или внешний сервис синхронизации, сначала проверьте, какие именно эндпоинты используются. Иначе можно получить не «усиление безопасности», а сломанный интерфейс публикации.
Диагностика: что именно открыто и кто этим пользуется
Перед изменениями полезно понять, как сайт ведёт себя сейчас. Самый простой тест — открыть публичный REST-эндпоинт в браузере или через curl.
curl -I https://example.com/wp-json/Если сервер отвечает 200 OK, API доступен. Это нормально само по себе, но дальше важно проверить, не отдаёт ли он лишнее гостям и не ломает ли это ваш стек.
Ещё один практичный тест — открыть страницу редактирования записи в админке и посмотреть консоль браузера. Если после ограничений там появляются ошибки загрузки данных или запросы к /wp-json/ получают 401 или 403 там, где должны быть доступны, значит правило слишком жёсткое.
Что проверить до внедрения
- работает ли Gutenberg;
- есть ли интеграции, которые читают данные через REST API;
- использует ли тема AJAX-запросы к
wp-json; - есть ли мобильное приложение WordPress или внешняя CMS-связка;
- не завязаны ли формы, поиск или фильтры на REST-эндпоинты.
Как ограничить REST API для гостей
Самый безопасный подход — не отключать REST API целиком, а запретить доступ неавторизованным пользователям. Для этого удобно использовать фильтр rest_authentication_errors. Он срабатывает до выполнения самого запроса и позволяет вернуть ошибку для гостей.
<?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 )
);
} );Этот вариант жёсткий: он закрывает API для всех гостей. Подходит для внутренних сайтов, корпоративных порталов и проектов, где 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'] ) : '';
if ( strpos( $request_uri, '/wp-json/wp/v2/users' ) !== false ) {
return new WP_Error(
'rest_forbidden_users',
__( 'Доступ к данным пользователей запрещён.', 'textdomain' ),
array( 'status' => 401 )
);
}
return $result;
} );Такой вариант менее универсален, потому что опирается на URI, а не на объект запроса. Но для точечной защиты конкретных маршрутов он работает предсказуемо и не требует сторонних плагинов.
Сравнение подходов: плагин, код или серверная блокировка
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
Код через rest_authentication_errors | Контроль на уровне WordPress, гибкая логика | Нужно аккуратно тестировать | Если хотите закрыть API без лишних плагинов |
| Security-плагин | Быстро включить, часто есть готовые пресеты | Может конфликтовать с другими настройками | Если нужен широкий набор защитных мер |
| Блокировка на сервере | Снимает нагрузку раньше WordPress | Легко сломать нужные запросы | Если у вас понятная инфраструктура и есть доступ к nginx/apache |
Если нужен не только REST, но и чистка сайта от лишних технических сущностей, иногда проще взять комплексный инструмент вроде Clearfy Pro, но использовать его стоит только после проверки, какие именно функции вам нужны. Ссылка на продукт: https://wpshop.ru/plugins/clearfy.
Проверка результата после внедрения
После включения ограничения проверьте не только сам ответ API, но и реальные сценарии сайта.
Минимальный чек-лист
- открыть
/wp-json/в приватном окне и убедиться, что гостю приходит401или403; - зайти в админку и проверить, что редактор записей открывается без ошибок;
- создать или отредактировать запись и посмотреть консоль браузера на наличие ошибок REST-запросов;
- проверить формы, поиск, фильтры и другие AJAX-элементы;
- если есть внешние интеграции, прогнать тестовый запрос от них.
Для быстрой проверки можно снова использовать curl:
curl -I https://example.com/wp-json/wp/v2/postsЕсли вы закрывали API для гостей, ответ должен быть не 200. Но если вы вошли в админку и проверяете из авторизованной сессии, поведение может отличаться — это нормально. Важно смотреть на тот сценарий, который вы реально ограничивали.
Частые ошибки и как их исправить
Сломали Gutenberg
Причина обычно в слишком жёстком запрете всего REST API для всех запросов. Блоковый редактор использует API для загрузки данных, автосохранения и некоторых операций с контентом. Исправление простое: не блокируйте API для авторизованных пользователей или ограничьте только отдельные маршруты.
Отключили API через remove_action и получили побочные эффекты
Иногда пытаются убрать REST API через отключение связанных функций ядра. Это грубый метод: он может задеть не только публичные запросы, но и внутренние механизмы WordPress. Надёжнее работать через фильтр доступа, а не вырезать функциональность ядра.
Проверяли только главную страницу
REST-проблемы часто проявляются не на фронтенде, а в админке. После внедрения обязательно проверьте редактор, медиа-библиотеку и страницы с динамическими блоками. Если что-то перестало подгружаться, ищите конкретный маршрут, а не откатывайте всё целиком.
Забыли про внешние интеграции
Если сайт синхронизируется с CRM, мобильным приложением или сторонним сервисом, у него может быть свой способ авторизации в REST API. Перед блокировкой убедитесь, что эти запросы не идут как гостевые. Иначе интеграция начнёт падать без очевидной ошибки на стороне WordPress.
Практические советы по безопасности и производительности
Ограничение REST API — не универсальная панацея. Оно уменьшает лишнюю экспозицию, но не заменяет нормальную гигиену сайта. Если цель именно безопасность, проверьте ещё несколько вещей:
- обновления ядра, тем и плагинов;
- отключение XML-RPC, если он не нужен;
- ограничение доступа к
/wp-admin/и/wp-login.phpпри необходимости; - контроль пользователей с правами администратора;
- логирование ошибок после изменений.
С точки зрения производительности закрытие лишних публичных маршрутов иногда снижает шум от ботов, но не стоит ждать от этого чудес. Если сайт реально тормозит, сначала смотрите кэш, запросы к базе и тяжёлые плагины, а уже потом режьте API.
Если нужен более мягкий путь, можно не блокировать REST API полностью, а закрыть только чувствительные маршруты и оставить публичные записи, категории или страницы. Это обычно лучший компромисс между безопасностью и совместимостью.