Если цель — уменьшить поверхность атаки или убрать лишние публичные ответы API, полностью «выключать REST API» в WordPress обычно не лучшая идея. На практике ломаются редактор блоков, часть тем, плагины форм, кэширования, интеграции и даже собственные скрипты сайта, если они ходят в /wp-json/. Рабочий подход другой: не отключать всё подряд, а ограничить доступ к публичным эндпоинтам и оставить то, что нужно самому WordPress и установленным плагинам.
Ниже разберём, что можно безопасно закрыть, какие способы реально работают, и как проверить, что сайт после этого не потерял нужный функционал.
Что именно можно отключать, а что лучше не трогать
REST API в WordPress — это не одна кнопка, а набор маршрутов. Часть из них открыта всем, часть требует авторизации, часть используется ядром, темой или плагинами. Поэтому задача обычно сводится не к полному запрету, а к фильтрации запросов.
Если говорить практично, чаще всего можно ограничивать:
- публичные ответы для неавторизованных посетителей;
- доступ к пользовательским данным и служебным маршрутам, если они не нужны вашему сайту;
- лишние маршруты, которые добавляют плагины и которыми вы не пользуетесь.
А вот что лучше оставить:
- маршруты, которые использует редактор блоков и админка;
- эндпоинты, на которые завязаны формы, поиск, фильтры, фронтенд-скрипты;
- всё, что требуется активным плагинам и теме для работы на фронтенде.
Если вы не уверены, какие именно запросы использует ваш сайт, не начинайте с жёсткого отключения через functions.php или глобальные правила на сервере. Это как раз тот случай, когда «сначала отключим, потом посмотрим» часто заканчивается неработающей страницей или ошибками в консоли браузера.
Самый безопасный вариант: закрыть REST API только для неавторизованных пользователей
Для большинства сайтов достаточно запретить доступ к REST API гостям, но оставить его для вошедших пользователей. Такой вариант снижает видимость публичных данных и при этом не ломает админку и многие внутренние сценарии WordPress.
Добавьте код в functions.php дочерней темы или, что надёжнее, в небольшой mu-plugin. Перед изменениями сделайте резервную копию: если на сайте есть фронтенд-логика, завязанная на REST API, после жёсткой блокировки она может перестать работать.
add_filter( 'rest_authentication_errors', function ( $result ) {
if ( true === $result || is_wp_error( $result ) ) {
return $result;
}
if ( ! is_user_logged_in() ) {
return new WP_Error(
'rest_disabled',
'REST API доступен только авторизованным пользователям.',
array( 'status' => 401 )
);
}
return $result;
} );Что делает этот код: для гостей он возвращает ошибку 401, а для авторизованных пользователей пропускает запрос дальше. Это не «выключение» REST API в абсолютном смысле, но для задачи ограничения публичного доступа обычно именно это и нужно.
Такой способ подходит, если сайт — обычный корпоративный проект, блог или контентный ресурс, где REST API не используется внешними сервисами. Если у вас есть мобильное приложение, headless-фронтенд, интеграция с CRM или кастомный интерфейс, сначала проверьте, какие запросы идут в API, иначе можно отрезать рабочую интеграцию.
Когда нужно отключить только часть REST API
Иногда проблема не в самом API, а в конкретных маршрутах. Например, вам не нужны публичные данные о пользователях, но нужен REST API для редактора и некоторых плагинов. В таком случае лучше блокировать точечно, а не рубить всё целиком.
Для этого можно использовать фильтр rest_endpoints. Он позволяет убрать отдельные маршруты из списка доступных эндпоинтов. Это уже более тонкая настройка, но и риск выше: если удалить не тот маршрут, сломается функциональность, которая внешне не выглядит связанной с API.
Пример ниже убирает только пользовательские маршруты. Используйте его только если вы понимаете, что на сайте не нужны публичные запросы к пользователям:
add_filter( 'rest_endpoints', function( $endpoints ) {
unset( $endpoints['/wp/v2/users'] );
unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
return $endpoints;
} );Этот вариант не отключает REST API целиком и не мешает остальным маршрутам работать. Но он не универсален: плагины могут добавлять свои эндпоинты с другими путями, и их придётся анализировать отдельно.
Почему не стоит отключать REST API через .htaccess или nginx «в лоб»
На форумах часто советуют просто запретить доступ к /wp-json/ на уровне веб-сервера. Технически это возможно, но для WordPress это самый грубый вариант. Он может сработать на одном сайте и сломать другой, потому что вы блокируете не только публичные ответы, но и внутренние запросы, которые ожидают тема или плагин.
Проблемы такого подхода обычно проявляются не сразу:
- редактор блоков начинает вести себя нестабильно;
- часть AJAX- или REST-запросов на фронтенде получает 403 или 404;
- появляются ошибки в консоли браузера;
- интеграции с внешними сервисами перестают получать данные.
Если всё же нужен серверный запрет, его стоит применять только после проверки, что сайт не использует REST API вообще. Для обычного WordPress-сайта это редкий случай. На практике безопаснее ограничивать доступ на уровне WordPress, а не веб-сервера.
Как проверить, что сайт не сломался после отключения
После изменения нужно проверить не только главную страницу, но и те места, где REST API используется чаще всего. Минимальный набор проверки выглядит так:
- откройте сайт в обычном режиме и убедитесь, что страницы загружаются без ошибок;
- зайдите в админку и откройте редактор записи или страницы;
- проверьте формы, поиск, фильтры, слайдеры и другие интерактивные элементы на фронтенде;
- посмотрите консоль браузера на наличие ошибок, связанных с запросами к
/wp-json/; - если есть интеграции или внешние сервисы, проверьте их отдельно.
Самый простой тест публичного доступа — открыть в браузере адрес /wp-json/ на вашем домене. Если вы закрывали API для гостей, ответ должен быть ошибкой доступа, а не полным списком маршрутов. Если же вы ограничивали только отдельные эндпоинты, общий ответ может остаться доступным — это нормально.
Для точной диагностики удобнее смотреть сетевые запросы в инструментах разработчика браузера. Если после отключения REST API на странице появились ошибки 401, 403 или 404 именно на запросах к API, значит, вы заблокировали нужный маршрут и нужно вернуть его обратно или ослабить ограничение.
Какой способ выбрать в реальном проекте
| Сценарий | Что делать | Риск поломки |
|---|---|---|
| Обычный сайт без внешних интеграций | Ограничить REST API для неавторизованных пользователей | Низкий |
| Нужно убрать только часть публичных данных | Отключить отдельные эндпоинты через rest_endpoints | Средний |
| Есть headless-фронтенд, мобильное приложение или сложные плагины | Не отключать без анализа, а сначала проверить используемые маршруты | Высокий |
Если задача именно в снижении видимости и уменьшении лишних публичных ответов, чаще всего достаточно первого варианта. Он даёт понятный результат и не требует лезть в серверные правила. Полное отключение REST API имеет смысл только тогда, когда вы точно знаете, что сайт не использует его ни на фронтенде, ни в админке, ни через плагины.
Именно поэтому правильная стратегия для WordPress — не «выключить всё», а убрать лишнее без ущерба для рабочих сценариев. Это особенно важно на сайтах, где тему и плагины подбирали не вы сами и не контролируете весь код целиком.
}