Если цель — уменьшить лишнюю поверхность атаки и убрать публичные ответы API для незалогиненных посетителей, REST API в WordPress можно ограничить только для гостей. Полностью выключать его обычно не стоит: многие темы, блоки редактора, формы, AJAX-логика и некоторые плагины используют REST API для нормальной работы сайта.
Практически задача сводится не к «выключить всё», а к тому, чтобы запретить доступ к REST API для неавторизованных пользователей и при этом не сломать то, что нужно самому WordPress и установленным плагинам.
Что именно имеет смысл отключать
REST API в WordPress отвечает на запросы к адресам вида /wp-json/. Для гостя это означает, что сайт может отдавать публичные данные о записях, страницах, таксономиях, авторах и других сущностях, если они доступны через API. Для большинства обычных сайтов это не критично, но если вы хотите сократить публичную экспозицию, разумно ограничить именно ответы для неавторизованных пользователей.
При этом не стоит путать REST API с внутренними механизмами WordPress. Полное отключение API «в лоб» часто ломает:
- редактор блоков Gutenberg;
- некоторые формы и интерактивные элементы;
- поиск, фильтры и динамические блоки в теме;
- плагины, которые обращаются к REST API для своих функций.
Поэтому безопаснее не удалять REST API целиком, а закрыть его для гостей и оставить доступ для авторизованных пользователей.
Самый простой способ: запретить REST API для гостей через код
Если у вас есть доступ к файлам темы или лучше к небольшому mu-plugin, можно добавить фильтр, который будет блокировать REST API для неавторизованных посетителей. Это рабочий вариант, если вам нужно именно ограничение по логике входа в систему.
Надёжнее всего поместить код в отдельный мини-плагин или в functions.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 доступен только авторизованным пользователям.' ),
array( 'status' => 401 )
);
}
return $result;
} );Что делает этот код:
- не вмешивается, если WordPress уже вернул ошибку или другой результат аутентификации;
- проверяет, вошёл ли пользователь в систему;
- если пользователь не авторизован, возвращает ошибку
401 Unauthorized.
После добавления кода откройте сайт в режиме инкогнито и проверьте адрес /wp-json/. Для гостя должен вернуться отказ, а для авторизованного администратора — обычный ответ API.
Как не сломать сайт: что лучше оставить доступным
Если вы закрываете REST API для гостей, важно понимать, что не все запросы одинаково полезны для блокировки. На практике чаще всего нужно оставить работу для авторизованных пользователей, потому что именно они редактируют контент, используют админку и взаимодействуют с плагинами, которым нужен API.
Если на сайте есть публичные функции, завязанные на REST API, например динамические блоки или отдельные интеграции, их придётся проверить отдельно. Универсального списка «безопасно отключить вот это, а это оставить» нет: всё зависит от темы и набора плагинов. Поэтому после ограничения доступа обязательно пройдитесь по ключевым страницам сайта и проверьте:
- главную страницу и шаблоны записей;
- формы обратной связи;
- поиск и фильтры;
- редактирование записей в админке;
- любые блоки или виджеты, которые подгружают данные динамически.
Если что-то перестало работать, причина часто не в самом WordPress, а в плагине или теме, которые ожидали доступ к REST API без авторизации.
Когда лучше не отключать REST API полностью
Есть сценарии, где жёсткое ограничение REST API для всех гостей создаёт больше проблем, чем пользы. Например, если сайт использует headless-подход, внешние сервисы, мобильное приложение, публичные интеграции или сложные интерфейсы на фронтенде, REST API может быть частью штатной архитектуры.
В таких случаях лучше не резать всё подряд, а ограничивать только лишние маршруты или защищать конкретные эндпоинты авторизацией. Это уже более точечная настройка, и она зависит от того, какие именно запросы нужны вашему проекту.
Если же сайт обычный, без внешних интеграций и без сложной фронтенд-логики, ограничение REST API для гостей обычно даёт именно тот эффект, который нужен: меньше публичных ответов и меньше лишнего шума в открытом доступе.
Как проверить, что ограничение работает
Проверка занимает пару минут и лучше делать её сразу после изменения. Откройте сайт в приватном окне браузера и перейдите на /wp-json/. Если всё настроено правильно, вы увидите отказ в доступе, а не список маршрутов API.
Затем войдите в админку под обычной учётной записью и снова откройте /wp-json/. Авторизованный пользователь должен получать ответ API, иначе вы заблокировали не только гостей, но и рабочие сценарии WordPress.
Если у вас есть кэш на уровне плагина, сервера или CDN, после изменений очистите его. Иначе вы можете увидеть старый ответ и решить, что правило не сработало.
Что делать, если после отключения появились ошибки
Если на сайте начали сыпаться ошибки JavaScript, перестали работать блоки или формы, первым делом временно отключите добавленный фильтр и проверьте, исчезла ли проблема. Это самый быстрый способ понять, связано ли поведение именно с ограничением REST API.
Если проблема подтверждается, не возвращайте открытый API целиком без разбора. Лучше найти конкретный плагин или участок темы, который делает запросы к REST API, и уже там решать, нужен ли доступ гостям, авторизация или другой способ получения данных.
Для большинства сайтов безопасная стратегия такая: закрыть REST API для неавторизованных посетителей, оставить его для входящих в систему пользователей и обязательно протестировать ключевые сценарии после изменения. Это даёт баланс между безопасностью и совместимостью, а не просто «выключает что-то лишнее» без понимания последствий.