REST API в WordPress часто отключают «на всякий случай», а потом ловят странные ошибки в редакторе, плагинах кэширования, формах, мобильных приложениях и внешних сервисах. Проблема не в самом API, а в том, что его нередко рубят целиком, не проверив, кто именно его использует.
Если задача — убрать лишнюю поверхность атаки или закрыть публичный доступ к части эндпоинтов, это можно сделать аккуратно. Если же на сайте уже работают Gutenberg, headless-интеграции, мобильные клиенты или плагины статистики и форм, полное отключение почти наверняка создаст побочные эффекты.
Когда REST API действительно мешает
Сначала стоит понять, что именно вы хотите исправить. Для WordPress REST API — это не только «внешний JSON», но и рабочий канал для редактора блоков, некоторых виджетов, автосохранения, поиска по сайту и интеграций плагинов. Поэтому вопрос обычно звучит не «отключить или нет», а «что можно ограничить без поломки сайта».
Типичные сценарии
- на сайте есть публичные эндпоинты, которые не нужны посетителям и индексируются сканерами;
- нужно закрыть доступ к данным для неавторизованных пользователей, но оставить работу админки;
- в логах много запросов к
/wp-json/, и вы хотите снизить шум; - плагин безопасности ругается на открытый REST API, но не объясняет, что именно отключать;
- часть сайта работает через REST API, и полное отключение уже ломало редактор или формы.
Диагностика: что использует REST API на вашем сайте
Перед изменениями проверьте, есть ли реальные зависимости. Самый простой способ — открыть главную и страницу записи с включенной консолью браузера и посмотреть сетевые запросы к /wp-json/. Если там идут запросы от редактора, темы или плагинов, отключать всё целиком нельзя.
На сервере полезно посмотреть, встречаются ли обращения к REST API в access-логах. Если у вас есть SSH, можно быстро отфильтровать запросы:
grep -R "wp-json" /var/log/nginx/access.log | tail -n 50Если логов нет или доступ ограничен, проверьте хотя бы поведение фронтенда и админки после временного ограничения доступа на тестовой копии. Это безопаснее, чем сразу править боевой сайт.
Как отключить REST API частично, а не ломать всё
Самый практичный вариант — не отключать API полностью, а ограничить доступ для неавторизованных пользователей. Тогда редактор и внутренние механизмы WordPress продолжат работать, а публичные запросы будут получать отказ.
Вариант через код в теме или mu-plugin
Ниже пример, который блокирует REST API для гостей, но оставляет доступ авторизованным пользователям. Это не универсальное решение для всех сайтов, зато оно предсказуемое и легко откатывается.
<?php
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_forbidden',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
}
return $result;
} );Код лучше класть не в functions.php активной темы, а в небольшой mu-plugin. Так он не потеряется при смене темы и проще контролируется.
Если нужно закрыть только часть эндпоинтов
Иногда проблема не в API как таковом, а в конкретных маршрутах. Тогда можно фильтровать по запросу и блокировать только то, что не нужно. Например, если вы не хотите отдавать список записей гостям через REST, но оставляете остальное:
<?php
add_filter( 'rest_pre_dispatch', function( $result, $server, $request ) {
if ( is_user_logged_in() ) {
return $result;
}
$route = $request->get_route();
if ( 0 === strpos( $route, '/wp/v2/posts' ) ) {
return new WP_Error(
'rest_forbidden_route',
__( 'Этот маршрут REST API закрыт для гостей.', 'textdomain' ),
array( 'status' => 403 )
);
}
return $result;
}, 10, 3 );Такой подход уже требует понимания, какие маршруты реально используются. Если сомневаетесь, сначала соберите список запросов в браузере и логи, а потом режьте точечно.
Сравнение подходов
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Ограничивает REST API настройками | Быстро, без кода | Может скрывать детали и конфликтовать с другими плагинами |
| Код через фильтры | Блокирует доступ по вашим правилам | Точно и прозрачно | Нужна аккуратная проверка зависимостей |
| Полное отключение | Рубит REST API целиком | Просто на бумаге | Часто ломает редактор и интеграции |
Если у вас обычный контентный сайт, чаще всего достаточно ограничить доступ для гостей. Полное отключение имеет смысл только после проверки, что сайт не использует REST API ни в админке, ни на фронтенде.
Проверка результата после внедрения
После изменения не ограничивайтесь открытием главной страницы. Нужно проверить несколько точек, иначе поломка всплывет позже — например, при редактировании записи или отправке формы.
- откройте
/wp-json/в браузере: для гостей должен быть отказ или пустой ответ по вашей логике; - зайдите в админку и откройте редактор записи;
- проверьте автосохранение и публикацию черновика;
- протестируйте формы, поиск, комментарии и любые интеграции с внешними сервисами;
- посмотрите консоль браузера на ошибки запросов к REST API;
- если есть кэш, очистите его и повторите проверку в инкогнито.
Хороший признак — на фронтенде нет лишних публичных запросов, а в админке редактор и плагины продолжают работать без ошибок 401/403.
Частые ошибки и как их исправить
Полное отключение без теста
Самая частая ошибка — поставить жесткий запрет на все REST-запросы и сразу выкатить на боевой сайт. Если после этого перестал работать редактор блоков, откатите изменение и переходите к ограничению только для гостей или только для отдельных маршрутов.
Правка в functions.php без резервной копии
Если в коде ошибка синтаксиса, можно получить белый экран или потерять доступ к админке. Для таких правок безопаснее использовать mu-plugin или хотя бы заранее проверить файл локально.
Игнорирование плагинов и темы
Некоторые плагины обращаются к REST API неочевидно: через AJAX, блоки, виджеты, формы, синхронизацию данных. Если вы не проверили список активных плагинов, отключение может сломать не сам WordPress, а конкретный функционал темы или расширения.
Проверка только под админом
Авторизованный пользователь может не заметить проблему, потому что ему доступен другой набор маршрутов. Обязательно тестируйте как гость, иначе вы пропустите реальные ограничения для посетителей.
Практические советы по безопасности и производительности
Если цель — не «выключить всё», а уменьшить поверхность атаки, лучше идти по приоритетам. Сначала ограничьте доступ к чувствительным маршрутам, затем проверьте заголовки, кэширование и логи. Полное отключение REST API редко дает заметный выигрыш само по себе, зато часто создает новые проблемы в поддержке.
Для сайтов с большим количеством плагинов полезно вести короткий список зависимостей: какие плагины используют REST API, какие страницы это затрагивает и что нужно проверить после обновления. Это экономит время при следующем релизе и помогает быстро понять, кто сломал запросы.
Если вы регулярно чистите сайт от лишнего функционала, имеет смысл делать это системно: отключать только то, что не используется, а не вырезать весь механизм целиком. В таких задачах часто помогает Clearfy Pro, если нужен набор настроек для чистки и контроля лишних элементов, но даже с ним логику отключения REST API лучше проверять вручную на вашем сайте.
Главный критерий здесь простой: после изменений сайт должен работать так же, как раньше, но с меньшим количеством ненужных публичных точек доступа. Если этого не получилось, значит, ограничение было слишком грубым и его нужно сузить.