REST API в WordPress часто оставляют открытым «по умолчанию», а потом удивляются лишним запросам, утечке данных о пользователях и шуму в логах. Полностью выключать API обычно не нужно: редактор, блоки, мобильные клиенты и часть плагинов завязаны на него. Но ограничить доступ для неавторизованных запросов — нормальная техническая задача, если понимать, что именно вы хотите закрыть.
Ниже — рабочая схема: сначала диагностика, потом варианты ограничения, затем проверка, чтобы не отрезать себе админку и интеграции.
Что именно обычно хотят закрыть
Под фразой «закрыть REST API» на практике скрываются разные сценарии. Иногда нужно убрать выдачу пользовательских данных для гостей. Иногда — запретить сторонним скриптам дергать публичные маршруты. А иногда — оставить API только для авторизованных запросов и внутренних механизмов WordPress.
Важно разделять:
- публичные маршруты, которые действительно нужны сайту;
- маршруты для авторизованных пользователей;
- маршруты плагинов, которые могут использоваться фронтендом;
- запросы, которые идут из редактора блоков и админки.
Диагностика: что у вас сейчас открыто
Перед изменениями проверьте, какие ответы отдает сайт на базовый REST endpoint и какие данные видны без авторизации. Самый простой тест — открыть /wp-json/ в браузере или выполнить запрос через curl.
curl -i https://example.com/wp-json/Если сайт возвращает JSON со списком маршрутов, это нормально. Вопрос не в самом факте ответа, а в том, какие маршруты доступны и что они отдают гостю. Отдельно проверьте пользовательские данные:
curl -i https://example.com/wp-json/wp/v2/usersНа многих сайтах этот маршрут либо закрыт, либо отдает минимум информации. Если вы видите список пользователей без веской причины, это уже повод ограничить доступ.
Еще одна полезная проверка — посмотреть, не используют ли ваши плагины REST API на фронтенде. Иногда это видно по сетевым запросам в DevTools, иногда — по документации плагина. Если отключить API «в лоб», можно сломать поиск, фильтры, формы или блоки.
Подходы к решению: плагин, код, компромисс
| Способ | Когда подходит | Минус |
|---|---|---|
| Плагин безопасности | Нужно быстро закрыть типовые поверхности без правки темы | Меньше контроля, возможны лишние ограничения |
| Код в mu-plugin | Нужна точечная политика доступа и предсказуемое поведение | Нужно тестировать на каждом обновлении |
| Полное отключение REST API | Редкий случай, когда сайт не использует блоки, интеграции и внешние клиенты | Высокий риск поломки редактора и плагинов |
Для большинства сайтов лучше не «рубить» API целиком, а ограничить только неавторизованные запросы к нужным маршрутам.
Пошаговое решение через код
Самый надежный вариант — добавить небольшой mu-plugin, чтобы правило не зависело от темы. Создайте файл wp-content/mu-plugins/limit-rest-api.php. Если папки mu-plugins нет, создайте ее вручную.
<?php
/**
* Plugin Name: Limit REST API for guests
*/
add_filter( 'rest_authentication_errors', function ( $result ) {
if ( true === $result || is_wp_error( $result ) ) {
return $result;
}
if ( is_user_logged_in() ) {
return $result;
}
$uri = $_SERVER['REQUEST_URI'] ?? '';
// Разрешаем базовый индекс API и нужные публичные маршруты.
$allowed_prefixes = array(
'/wp-json/',
'/wp-json/oembed/1.0/',
);
foreach ( $allowed_prefixes as $prefix ) {
if ( strpos( $uri, $prefix ) !== false ) {
return $result;
}
}
return new WP_Error(
'rest_forbidden',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
} );Этот вариант не идеален для всех сайтов, но он показывает логику: гостям можно оставить только то, что реально нужно. Если у вас есть фронтенд-интеграции, список разрешенных маршрутов придется расширить вручную.
Как не сломать редактор блоков
Редактор Gutenberg и некоторые экраны админки используют REST API для сохранения и загрузки данных. Поэтому не стоит ориентироваться только на is_user_logged_in() и полностью блокировать все запросы без исключений. Если вы работаете в админке, запросы должны проходить.
Если после ограничения перестали сохраняться записи или не подгружаются блоки, значит правило слишком широкое. В таком случае сначала проверьте, не режете ли вы запросы к /wp-json/wp/v2/ для авторизованных пользователей.
Альтернатива через фильтр маршрутов
Если нужно закрыть только конкретные endpoints, удобнее использовать фильтр rest_endpoints. Он позволяет убрать из публичного списка отдельные маршруты, не трогая весь API.
<?php
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( ! is_user_logged_in() ) {
unset( $endpoints['/wp/v2/users'] );
unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
}
return $endpoints;
} );Этот подход полезен, когда вам не нужен маршрут пользователей, но нужны остальные публичные данные, например записи, страницы или таксономии. Минус в том, что список маршрутов нужно поддерживать вручную, если плагины добавляют свои endpoints.
Проверка результата после внедрения
После правки проверьте не только сам ответ API, но и поведение сайта в реальных сценариях.
- Откройте
/wp-json/в режиме инкогнито и убедитесь, что доступ остался только к разрешенным маршрутам. - Проверьте
/wp-json/wp/v2/users— он должен быть закрыт или не содержать лишних данных. - Зайдите в админку и откройте редактор записи: сохранение и загрузка блоков должны работать.
- Если на сайте есть поиск, фильтры или формы, проверьте их отдельно.
- Посмотрите логи браузера на предмет ошибок
401и403в запросах к/wp-json/.
Если у вас есть мониторинг ошибок сервера, полезно отследить всплеск 401 после внедрения. Это покажет, какие внешние клиенты или скрипты еще пытаются ходить в закрытые маршруты.
Частые ошибки и как их исправить
Полностью отключили REST API
Это самая частая ошибка. После нее ломаются блоки, редактор, некоторые формы и интеграции. Исправление простое: не отключайте весь API, а ограничивайте только неавторизованные запросы или отдельные маршруты.
Забыли про фронтенд-скрипты
Некоторые темы и плагины используют REST API для подгрузки контента на сайте. Если у вас перестали работать фильтры или динамические блоки, ищите запросы к /wp-json/ в DevTools и добавляйте исключения.
Проверяете только главную страницу
Ограничение может не затронуть главную, но сломать страницу записи, архив или админку. Тестировать нужно именно те сценарии, где API реально используется.
Ставите правило в тему
Если правило лежит в functions.php, оно исчезнет при смене темы. Для технических ограничений лучше использовать mu-plugin или отдельный мини-плагин.
Безопасность и производительность
Ограничение REST API не делает сайт «защищенным полностью», но уменьшает лишнюю поверхность атаки и шум от автоматических запросов. Это особенно полезно, если у вас много контента, анонимный трафик и нет необходимости отдавать весь набор маршрутов гостям.
При этом не стоит рассчитывать, что одно правило решит все проблемы безопасности. Если есть подозрение на утечку данных, проверьте еще:
- права ролей и пользователей;
- публичность пользовательских архивов;
- настройки индексации служебных страниц;
- наличие лишних REST-маршрутов от старых плагинов.
Если вам нужна более широкая техническая чистка сайта, иногда удобнее делать это через набор точечных настроек в одном инструменте. Например, у Clearfy Pro есть функции для удаления дублей и части служебного мусора, но такие решения все равно нужно проверять на вашем стеке и не включать вслепую: https://wpshop.ru/plugins/clearfy.
Если после внедрения ограничения сайт стал быстрее отвечать на часть запросов — это приятный бонус, но не гарантированный эффект. Основная цель здесь все же контроль доступа, а не ускорение.
Когда лучше не трогать REST API
Если у вас активно используются headless-элементы, мобильное приложение, сложные фильтры, редакторские интеграции или внешние сервисы, сначала составьте список реальных маршрутов. В таких проектах лучше ограничивать не весь API, а конкретные чувствительные endpoints. Иначе вы потратите больше времени на восстановление функциональности, чем на саму настройку.
Практический ориентир простой: если вы не можете быстро назвать, какие маршруты нужны сайту, не начинайте с жесткой блокировки. Сначала снимите карту запросов, потом режьте только лишнее.