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