REST API в WordPress часто нужен для редактора, мобильных приложений, блоков, внешних интеграций и некоторых плагинов. Проблема начинается, когда его пытаются «выключить целиком» ради безопасности: в итоге ломаются запросы в админке, автосохранение, блоки Gutenberg или сторонние сервисы. Гораздо практичнее ограничить доступ только для неавторизованных пользователей и оставить рабочие сценарии для бэкенда.
Ниже — рабочая схема: сначала быстро диагностируем, кто и зачем обращается к API, потом закрываем публичные маршруты, а затем проверяем, что редактор и админка продолжают работать.
Когда REST API действительно стоит ограничить
Не каждый сайт нуждается в полном публичном доступе к REST API. Если у вас обычный корпоративный сайт, блог или контентный проект без внешнего фронтенда, то открытые эндпоинты часто не дают пользы, но создают лишний шум в логах и расширяют поверхность атаки. При этом полностью отключать API «на глаз» нельзя: WordPress и плагины используют его внутри админки.
Типичные симптомы лишнего публичного доступа
Проверять стоит не только безопасность, но и нагрузку. На практике проблему выдают такие признаки:
- в логах много запросов к
/wp-json/от ботов; - внешние сервисы дергают публичные маршруты без авторизации;
- плагин безопасности показывает открытые пользовательские данные через REST;
- после установки «жесткого» сниппета перестают работать блоки, автосохранение или редактор записей.
Диагностика: что именно открыто
Сначала посмотрите, как отвечает сайт на базовые запросы REST API. Это не замена полноценному аудиту, но позволяет понять, есть ли публичная экспозиция и не мешает ли текущая конфигурация работе админки.
curl -I https://example.com/wp-json/Если сервер отвечает 200, это нормально для стандартного WordPress. Важнее понять, какие маршруты доступны без авторизации. Для этого можно открыть в браузере:
https://example.com/wp-json/wp/v2/postsЕсли в ответе видны записи, заголовки, рубрики или другие данные, которые вы не хотите отдавать гостям, значит нужно ограничение на уровне логики, а не «рубить всё подряд».
Пошаговое решение: закрываем REST API для гостей
Самый предсказуемый вариант — запретить доступ к REST API для неавторизованных пользователей, но оставить его для входа в админку и внутренних запросов WordPress. Делать это лучше через rest_authentication_errors: это штатный фильтр, который отрабатывает до выполнения маршрута.
Вариант через код в теме или mu-plugin
Если у вас есть доступ к коду, добавьте сниппет в functions.php дочерней темы или, что лучше, в отдельный mu-plugin. Так изменения не потеряются при обновлении темы.
add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
if ( is_user_logged_in() ) {
return $result;
}
// Разрешаем служебные запросы WordPress, если они идут из админки.
if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
return new WP_Error(
'rest_forbidden',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
}
return $result;
} );Этот вариант жесткий: он запрещает публичный доступ к REST API. Для многих сайтов этого достаточно, но перед включением обязательно проверьте, не используют ли API фронтенд-скрипты, формы, поиск или сторонние интеграции.
Более мягкий вариант: закрыть только пользовательские данные
Если вам нужно оставить часть публичных маршрутов, а закрыть только чувствительные данные, лучше ограничивать конкретные эндпоинты через register_rest_route() или фильтровать ответы на уровне плагина. Полное глобальное отключение в таком случае будет слишком грубым.
| Подход | Что делает | Риск |
|---|---|---|
| Плагин безопасности | Быстро закрывает доступ без кода | Может конфликтовать с редактором или интеграциями |
Код через rest_authentication_errors | Точный контроль над доступом | Нужна проверка зависимостей |
| Полное отключение REST API | Скрывает API целиком | Часто ломает админку и блоки |
Как не сломать админку и Gutenberg
Самая частая ошибка — добавлять фильтр, который режет вообще все REST-запросы, включая те, что нужны редактору. WordPress в админке активно использует API для сохранения контента, загрузки данных и работы блоков. Поэтому после внедрения нужно проверить не только главную страницу, но и редактор записей.
Что проверить сразу после изменения
- открывается ли
/wp-admin/post-new.php; - создаются ли и сохраняются ли записи в блоковом редакторе;
- работает ли автосохранение;
- не появляются ли ошибки в консоли браузера;
- не ломаются ли плагины, которые подгружают данные через REST.
Если редактор начал выдавать ошибки, значит ограничение слишком широкое. В таком случае не пытайтесь «лечить» это исключениями наугад — сначала найдите конкретный маршрут, который нужен плагину или ядру.
Проверка результата после внедрения
После установки ограничения проверьте сайт с двух сторон: снаружи и из авторизованной сессии. Это самый надежный способ понять, что вы закрыли именно публичный доступ, а не сломали рабочие сценарии.
Проверка снаружи
Откройте в браузере или через curl публичный маршрут REST API. Для гостя должен быть отказ в доступе или пустой ответ, в зависимости от выбранной логики.
curl -i https://example.com/wp-json/wp/v2/usersЕсли вы видите список пользователей без авторизации, это уже повод пересмотреть настройку: такой ответ обычно не нужен на обычном сайте.
Проверка из админки
Зайдите в панель, откройте редактор записи, создайте черновик и сохраните его. Если всё работает, значит ограничение не задело внутренние запросы. Дополнительно откройте консоль браузера: там не должно быть повторяющихся ошибок вида 401 или rest_cookie_invalid_nonce.
Частые ошибки и как их исправить
На этой задаче чаще всего ломаются не сами ограничения, а их реализация. Ниже — типовые промахи, которые я вижу в проектах.
- Отключают REST API через
remove_action( 'rest_api_init', ... ). Это грубо и непредсказуемо: можно задеть маршруты плагинов и ядра. - Ставят фильтр в активную тему. После смены темы защита исчезает. Для системных ограничений лучше использовать mu-plugin.
- Не проверяют фронтенд-интеграции. Некоторые формы, фильтры и виджеты могут получать данные через REST.
- Сразу блокируют всё для всех. Авторизованные пользователи тоже могут потерять доступ к нужным маршрутам, если логика написана слишком жестко.
- Путают REST API и XML-RPC. Это разные механизмы. Если вы уже закрыли XML-RPC, REST API всё равно может оставаться открытым.
Практические советы по безопасности и производительности
Если цель — не только безопасность, но и снижение лишней нагрузки, не ограничивайтесь одним фильтром. Посмотрите, какие маршруты реально используются на сайте, и уберите только то, что не нужно. Для небольших проектов полезно дополнительно логировать обращения к REST API на уровне сервера или WAF, чтобы увидеть ботов и подозрительные шаблоны запросов.
Если вы не хотите писать код вручную, можно использовать плагин, который умеет точечно чистить WordPress от лишнего и закрывать часть технических поверхностей. Например, Clearfy Pro подходит как базовый инструмент для технической гигиены сайта, но даже в этом случае логику доступа лучше перепроверять на живом проекте.
Когда лучше не закрывать REST API полностью
Если у вас headless-фронтенд, мобильное приложение, публичный каталог данных или интеграция с внешним сервисом, полный запрет REST API почти наверняка создаст больше проблем, чем пользы. В таких сценариях нужно не отключение, а нормальная схема авторизации, ограничение конкретных маршрутов и контроль прав доступа по ролям.
Для обычного сайта без внешних потребителей API рабочая стратегия проще: закрыть гостевой доступ, оставить админские сценарии, проверить редактор и зафиксировать изменение в конфигурации, чтобы оно не потерялось после обновления темы.