Если на сайте не нужны внешние интеграции, мобильное приложение, редактор блоков или публичные запросы к данным, REST API действительно можно ограничить. Но полностью отключать его вслепую не стоит: в WordPress он используется не только «для внешних сервисов», а и внутри самой системы. Поэтому сначала нужно понять, что именно вы хотите убрать — публичный доступ к эндпоинтам или саму возможность работы API для авторизованных пользователей и внутренних запросов.
Коротко: если задача — снизить поверхность атаки и убрать лишние публичные ответы, чаще всего достаточно закрыть доступ к неавторизованным запросам. Полное отключение имеет смысл только на очень простых сайтах, где точно не используются блоки, headless-сценарии, мобильные клиенты, интеграции и сторонние сервисы, которые ходят в REST API.
Когда REST API лучше не отключать полностью
REST API в WordPress задействован шире, чем кажется на первый взгляд. Он нужен не только разработчикам, но и самому ядру WordPress, плагинам и теме. Если вы отключите его грубо, можно получить побочные эффекты: от неработающих блоков в редакторе до проблем с плагинами, которые подгружают данные через API.
Оставить API включённым обычно разумнее, если у вас:
- используется редактор блоков Gutenberg;
- есть фронтенд-скрипты, которые получают данные через REST API;
- на сайте работает мобильное приложение или внешняя интеграция;
- есть headless-архитектура или отдельный фронтенд;
- вы не уверены, какие плагины обращаются к API.
В этих случаях лучше не «рубить» REST API целиком, а ограничить доступ к публичным эндпоинтам или закрыть только те маршруты, которые вам не нужны.
Что именно можно ограничить
У WordPress есть несколько практических сценариев защиты. Самый безопасный из них — оставить REST API доступным для авторизованных пользователей и внутренних задач, но скрыть или заблокировать ответы для незалогиненных посетителей. Это снижает видимость данных сайта для сканеров и ботов, но не ломает админку и большинство штатных сценариев.
Есть и более жёсткий вариант — полностью отключить REST API для всех запросов. Его стоит рассматривать только тогда, когда вы точно понимаете последствия и проверили, что сайт не зависит от API. На обычном сайте с темой и плагинами это рискованнее, чем кажется.
Как ограничить REST API для незалогиненных пользователей
Если вам нужно убрать публичный доступ, но не ломать работу WordPress для администраторов и авторизованных пользователей, используйте фильтр rest_authentication_errors. Его удобно добавить в плагин для сайта или в functions.php дочерней темы. Для продакшена плагин безопаснее: при смене темы правило не потеряется.
Ниже пример, который запрещает доступ к REST API для неавторизованных пользователей и возвращает стандартную ошибку rest_forbidden:
add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
if ( ! is_user_logged_in() ) {
return new WP_Error(
'rest_forbidden',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
}
return $result;
} );Что делает этот код: если пользователь не вошёл в систему, REST API отвечает ошибкой 401. Для админов и других авторизованных пользователей API остаётся доступным. Это хороший вариант, если вы хотите уменьшить публичную поверхность атаки, но не ломать внутреннюю работу сайта.
После добавления кода проверьте две вещи: в приватном окне браузера откройте адрес /wp-json/ и убедитесь, что видите ошибку, а затем войдите в админку и проверьте, что редактор блоков и нужные плагины работают как раньше.
Как отключить REST API полностью
Полное отключение — более жёсткий шаг. Его имеет смысл делать только на простом сайте без зависимостей от API. Если вы всё же уверены, что он не нужен, можно использовать фильтр rest_enabled. Он отключает REST API на уровне WordPress.
Пример кода:
add_filter( 'rest_enabled', '__return_false' );Это короткое решение, но у него есть важный минус: оно отключает REST API для всех, включая внутренние сценарии, которые могут быть вам неочевидны. Если после этого что-то перестало работать, первым делом проверьте редактор блоков, плагины с фронтенд-формами, интеграции и любые виджеты, которые подгружают данные через JSON.
Если сайт работает на старой или сильно кастомизированной сборке, тестировать нужно особенно аккуратно. На некоторых проектах проблема проявляется не сразу, а только после сохранения записи, загрузки медиафайлов или обращения плагина к собственному маршруту REST API.
Можно ли закрыть только часть маршрутов
Да, и это часто более разумно, чем полное отключение. Если вам не нужен конкретный маршрут, его можно заблокировать точечно через фильтр rest_endpoints. Такой подход полезен, когда вы хотите оставить API для ядра и нужных плагинов, но убрать отдельные публичные маршруты.
Пример: удаляем из списка маршрутов один конкретный endpoint. Перед использованием нужно знать точный ключ маршрута, который вы хотите убрать.
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( isset( $endpoints['/wp/v2/users'] ) ) {
unset( $endpoints['/wp/v2/users'] );
}
return $endpoints;
} );Такой способ требует аккуратности: если вы удалите маршрут, который нужен теме или плагину, получите скрытую поломку. Поэтому точечное отключение подходит только тогда, когда вы понимаете, какой именно endpoint лишний.
Что проверить после изменения
После любого ограничения REST API не ограничивайтесь проверкой главной страницы. Откройте несколько сценариев, которые реально используются на сайте:
- вход в админку и открытие редактора записей;
- сохранение записи или страницы;
- работу форм, если они завязаны на AJAX и REST;
- отображение блоков и динамического контента на фронтенде;
- вызовы сторонних сервисов, если они есть.
Для быстрой проверки можно открыть https://ваш-домен/wp-json/ в браузере. Если API ограничен для гостей, вы увидите ошибку или отказ в доступе. Если API оставлен включённым, должен открываться JSON-ответ с информацией о корневом маршруте. Но этот тест не заменяет проверку рабочих сценариев сайта.
Когда лучше не трогать WordPress-код, а ограничить доступ на уровне сервера
Если ваша цель — не функциональное отключение, а именно снижение публичного доступа, иногда удобнее закрыть доступ к /wp-json/ на уровне веб-сервера или через WAF. Это особенно полезно, когда вы хотите отсеять лишние запросы ещё до загрузки WordPress. Но такой подход зависит от конфигурации хостинга и веб-сервера: для Apache и Nginx правила будут разными, а на управляемом хостинге часть настроек может быть недоступна.
При этом серверное ограничение не всегда лучше кода. Если вы заблокируете маршрут слишком грубо, можно сломать легитимные запросы, а диагностика станет сложнее. На практике для большинства сайтов проще и безопаснее сначала ограничить REST API через WordPress-фильтр, а уже потом, если нужно, усиливать защиту на уровне сервера или CDN.
Как выбрать подходящий вариант
| Сценарий | Что делать |
|---|---|
| Сайт использует Gutenberg, плагины и интеграции | Не отключать полностью, а ограничить доступ для гостей |
| Нужен только внутренний доступ для авторизованных пользователей | Использовать rest_authentication_errors |
| Сайт простой, без зависимостей от API | Можно отключить REST API фильтром rest_enabled, но только после проверки |
| Нужно убрать один конкретный маршрут | Использовать rest_endpoints |
Если сомневаетесь, начинайте с мягкого ограничения для незалогиненных пользователей. Это самый практичный вариант: он уменьшает публичную поверхность атаки и при этом оставляет WordPress работоспособным для штатных задач. Полное отключение имеет смысл только после проверки всех зависимостей сайта, а не «на всякий случай».
}