Если вам нужно уменьшить публичную поверхность сайта, ограничение REST API для неавторизованных пользователей — один из рабочих вариантов. Но отключать его «в лоб» нельзя: многие темы, блоки редактора, формы, поисковые интерфейсы и плагины используют REST API для обычной работы. Поэтому правильная задача звучит не как «убрать REST API совсем», а как «закрыть доступ к нему для гостей, не сломав сайт».
Ниже разберём, когда такое ограничение действительно оправдано, какой способ безопаснее, и как проверить, что после изменения ничего не отвалилось.
Когда ограничение REST API оправдано
REST API в WordPress нужен не только для внешних интеграций. Его используют сам WordPress, редактор блоков, некоторые темы, AJAX-логика плагинов, мобильные приложения и сервисы, которые получают данные с сайта. Поэтому полное отключение — это не универсальная мера безопасности, а точечное решение для конкретного сценария.
Ограничивать доступ имеет смысл, если:
- сайт не использует внешние приложения и публичные интеграции через REST API;
- вам нужно уменьшить количество открытых точек доступа для гостей;
- вы видите нежелательные запросы к эндпоинтам API в логах или мониторинге;
- сайт работает как обычный корпоративный или контентный проект без публичного API.
Если же у вас фронтенд на React/Vue, headless-схема, мобильное приложение, кастомный поиск, фильтры или плагин, который явно обращается к REST API, закрывать его для всех гостей нельзя. В таком случае лучше ограничивать только отдельные маршруты или оставить API доступным.
Какой способ безопаснее
Для большинства сайтов самый аккуратный вариант — не отключать REST API полностью, а запретить доступ к нему только неавторизованным пользователям. Авторизованные администраторы, редакторы и другие вошедшие пользователи при этом продолжают работать с редактором и админкой как обычно.
Есть два практических подхода:
| Способ | Что делает | Когда подходит |
|---|---|---|
| Код в теме или мини-плагине | Возвращает 401/403 для гостей при запросах к REST API | Если нужен контроль без установки лишних плагинов |
| Плагин для ограничения REST API | Даёт готовую настройку без правки кода | Если не хочется трогать functions.php |
Для точечной и предсказуемой настройки я обычно рекомендую код в отдельном мини-плагине. Так решение не пропадёт после смены темы и не смешается с её логикой. Правка functions.php тоже работает, но это менее удобно для поддержки.
Ограничение REST API для гостей через код
Перед изменениями сделайте резервную копию сайта или хотя бы файла, куда будете вносить код. Если на сайте уже есть плагины, которые используют REST API на публичной части, после ограничения они могут перестать работать. Это не ошибка кода, а ожидаемое следствие политики доступа.
Ниже пример, который блокирует REST API для неавторизованных пользователей, но оставляет доступ тем, кто вошёл в админку. Код можно добавить в functions.php дочерней темы или, что лучше, в небольшой собственный плагин.
add_filter( 'rest_authentication_errors', function ( $result ) {
if ( true === $result || is_wp_error( $result ) ) {
return $result;
}
if ( is_user_logged_in() ) {
return $result;
}
return new WP_Error(
'rest_forbidden',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
} );Что здесь происходит: фильтр rest_authentication_errors вызывается до обработки запроса REST API. Если пользователь не вошёл в систему, код возвращает ошибку 401 Unauthorized. Для авторизованных пользователей запрос проходит дальше.
Если вам нужен более жёсткий вариант, можно вернуть 403 вместо 401. На практике разница небольшая: 401 означает «нужна авторизация», 403 — «доступ запрещён». Для большинства сайтов 401 понятнее и логичнее.
Как сделать это в виде мини-плагина
Если не хотите зависеть от темы, создайте отдельный файл плагина, например wp-content/plugins/restrict-rest-api/restrict-rest-api.php, и вставьте туда такой код:
<?php
/*
Plugin Name: Restrict 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;
}
return new WP_Error(
'rest_forbidden',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
} );После этого активируйте плагин в админке WordPress. Такой способ удобнее, если вы управляете несколькими сайтами или не хотите править тему при каждом обновлении.
Что может сломаться после ограничения
Самая частая ошибка — включить блокировку и сразу получить жалобы от редакторов или увидеть, что на сайте перестали работать отдельные элементы интерфейса. Обычно проблема не в самом REST API, а в том, что какой-то компонент сайта использовал его как обычный канал обмена данными.
Проверьте особенно внимательно:
- редактор блоков в админке;
- поиск и фильтры на фронтенде, если они построены на AJAX;
- формы, которые отправляют данные через REST API;
- виджеты и блоки, которые подгружают контент динамически;
- кастомные решения темы, особенно если она современная и активно использует JavaScript.
Если что-то перестало работать, не спешите полностью откатывать изменение. Сначала выясните, какой именно скрипт или плагин делает запросы к REST API. Иногда достаточно оставить доступ только для части маршрутов, а не для всего API целиком.
Как проверить, что ограничение работает
Проверка простая и не требует специальных инструментов. Откройте сайт в режиме гостя, то есть в приватном окне браузера, и перейдите по адресу вида /wp-json/. Если ограничение включено, вы должны увидеть ошибку доступа, а не список маршрутов API.
Затем войдите в админку под обычной учётной записью и снова откройте /wp-json/. Для авторизованного пользователя REST API должен открываться, если вы использовали именно вариант с ограничением для гостей.
Дополнительно проверьте:
- главную страницу и внутренние страницы сайта;
- редактирование записей и страниц в админке;
- формы, поиск, фильтры и другие интерактивные элементы;
- консоль браузера на предмет ошибок JavaScript.
Если на фронтенде появились ошибки, значит, какой-то компонент ожидал доступ к REST API. В этом случае лучше не держать блокировку «как есть», а найти конкретный запрос и понять, можно ли ограничить только его.
Когда лучше не отключать REST API полностью
Есть ситуации, в которых ограничение для гостей создаст больше проблем, чем пользы. Например, если сайт активно использует блоки Gutenberg на фронтенде, работает с внешними сервисами, имеет сложную тему с динамическими компонентами или зависит от плагинов, которые получают данные через REST API без авторизации.
В таких случаях разумнее:
- оставить REST API открытым;
- ограничить отдельные маршруты на уровне плагина или сервера;
- убрать только те публичные endpoints, которые действительно не нужны;
- проверить журналы запросов и понять, кто именно обращается к API.
Если цель — именно снизить лишнюю публичную поверхность, а не сломать рабочие сценарии, лучше идти от диагностики. Сначала посмотрите, что использует REST API на вашем сайте, и только потом включайте ограничение для гостей.
На практике это самый надёжный подход: вы не отключаете полезный механизм целиком, а закрываете его там, где он действительно не нужен. Для обычного сайта на WordPress этого обычно достаточно, чтобы уменьшить лишний публичный доступ без побочных эффектов.