Если вам нужно сократить лишние внешние запросы и уменьшить поверхность атаки, не ломая при этом админку и редактор, полностью отключать REST API в WordPress обычно не стоит. Практичнее ограничить доступ только для незалогиненных пользователей: тогда публичные запросы к /wp-json/ будут закрыты, а авторизованные пользователи продолжат работать с блоковым редактором, админкой и внутренними запросами WordPress.
Это решение подходит, когда сайт не использует публичный REST API для фронтенда, мобильного приложения или внешних сервисов. Если такие интеграции есть, сначала проверьте, какие именно маршруты им нужны, иначе можно сломать часть функциональности.
Что именно отключаем и чего не трогаем
REST API в WordPress — это не одна кнопка, а набор маршрутов, доступных через /wp-json/. Полное отключение API часто приводит к побочным эффектам: перестают работать блоки в редакторе, некоторые функции админки, плагины и темы, которые запрашивают данные через REST.
Когда речь идёт об ограничении для незалогиненных пользователей, задача другая: закрыть публичный доступ к API для гостей, но оставить доступ для авторизованных пользователей. На практике это означает, что запросы без входа в систему будут получать отказ, а пользователь с активной сессией сможет работать как раньше.
Такой подход обычно безопаснее, чем попытка «вырубить всё». Он меньше ломает сайт и лучше соответствует реальной задаче — убрать лишний публичный доступ, а не отключить сам механизм WordPress.
Самый надёжный способ: ограничить REST API через код
Если у вас есть доступ к теме, дочерней теме или небольшому mu-plugin, добавьте фильтр rest_authentication_errors. Он срабатывает до выполнения REST-запроса и позволяет запретить доступ гостям.
Лучше всего размещать такой код не в основной теме, а в дочерней теме или в отдельном мини-плагине. Тогда ограничение не исчезнет после обновления темы.
Перед внесением изменений сделайте резервную копию файлов и проверьте, нет ли на сайте фронтенд-скриптов, которые используют REST API без авторизации. Если такие запросы есть, они начнут получать ошибку доступа.
Вот рабочий вариант кода:
add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
if ( is_user_logged_in() ) {
return $result;
}
return new WP_Error(
'rest_disabled',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
} );Что делает этот код:
- не мешает другим проверкам, если WordPress или плагин уже вернул ошибку;
- пропускает авторизованных пользователей;
- для гостей возвращает ответ
401 Unauthorized.
Если вам нужен более жёсткий вариант, можно вернуть 403 вместо 401. На практике разница небольшая: оба кода означают отказ в доступе, но 401 чаще используют именно для неавторизованных запросов.
Куда вставить код, чтобы не потерять его после обновления
Есть три нормальных варианта:
- дочерняя тема — если вы уже используете её и понимаете, где находится
functions.php; - небольшой собственный плагин — самый аккуратный способ для постоянного ограничения;
- mu-plugin в каталоге
wp-content/mu-plugins— если нужно, чтобы правило включалось всегда и не зависело от активации обычных плагинов.
Для большинства сайтов удобнее отдельный мини-плагин или mu-plugin. Так вы не привязываете безопасность к теме оформления.
Как проверить, что REST API закрыт только для гостей
После добавления кода откройте сайт в режиме инкогнито или выйдите из админки. Затем перейдите по адресу https://ваш-домен.ru/wp-json/. Вместо списка маршрутов вы должны увидеть сообщение об ошибке доступа или ответ с кодом 401.
Дальше проверьте тот же адрес, уже будучи авторизованным в админке. Если всё настроено правильно, REST API должен открываться, а редактор записей и страницы — работать без ошибок.
Если у вас есть фронтенд-форма, поиск, фильтры или другой JavaScript, который обращается к REST API, проверьте именно эти сценарии. Иногда сайт в целом открывается нормально, но на отдельных страницах ломается подгрузка данных. Это означает, что какой-то публичный запрос всё-таки нужен, и его придётся либо оставить открытым, либо точечно разрешить.
Когда лучше не отключать REST API целиком
Есть несколько ситуаций, в которых полное ограничение для гостей может оказаться лишним или вредным:
- сайт использует блоковый редактор и сторонние плагины, которые ожидают доступ к части REST-маршрутов;
- на фронтенде есть AJAX-подгрузка данных через REST API;
- подключено внешнее приложение, которое получает контент из WordPress;
- на сайте используются плагины, завязанные на публичные маршруты API.
В таких случаях лучше не рубить всё подряд, а сначала понять, какие маршруты реально используются. Иногда достаточно ограничить только часть запросов, а не весь API. Но это уже отдельная задача, и без анализа конкретного сайта здесь легко сломать рабочие сценарии.
Если нужен более простой вариант через плагин
Иногда владельцу сайта проще включить готовое решение, чем править код вручную. Это разумно, если вы не хотите поддерживать собственный фрагмент PHP и вам нужен понятный интерфейс с переключателем. Но здесь важно смотреть не на «отключение всего подряд», а именно на возможность ограничить REST API для гостей без поломки админки.
Если используете плагин, после активации всё равно проверьте /wp-json/ в гостевом режиме и убедитесь, что вход в админку, редактор и нужные плагины работают как раньше. Любой готовый инструмент нужно тестировать на вашем наборе тем и расширений, потому что поведение зависит от конкретного сайта.
Что делать, если после ограничения что-то сломалось
Если после закрытия REST API перестал работать редактор, не грузятся данные на фронтенде или появились ошибки JavaScript, сначала временно отключите добавленный код и проверьте, исчезла ли проблема. Это самый быстрый способ понять, связано ли всё именно с REST API.
Дальше действуйте по шагам:
- проверьте, какие страницы и функции перестали работать;
- посмотрите консоль браузера на ошибки запросов к
/wp-json/; - определите, нужен ли доступ только авторизованным пользователям или часть маршрутов должна остаться публичной;
- если нужен частичный доступ, не закрывайте API целиком, а настраивайте более точечное ограничение.
Если сайт критически зависит от REST API, полное закрытие для гостей — не лучший путь. В таком случае безопаснее ограничить только конкретные маршруты или защитить сайт другими способами, не затрагивая рабочие запросы WordPress.
Для большинства обычных сайтов, где REST API не используется публично, вариант с фильтром rest_authentication_errors даёт нужный баланс: гости не получают доступ к /wp-json/, а админка и редактор продолжают работать. Это и есть тот случай, когда ограничение полезно, но не разрушает сайт.