Если цель — сократить лишние внешние запросы и закрыть публичные эндпоинты, REST API в WordPress действительно можно ограничить. Но полностью отключать его на живом сайте без проверки не стоит: REST API используют не только сторонние сервисы, но и сам WordPress, редактор блоков, некоторые темы и плагины.
Практически правильный подход такой: не ломать API целиком, а убрать публичный доступ там, где он не нужен, и оставить работу для авторизованных пользователей и внутренних задач сайта.
Что именно можно отключать, а что лучше не трогать
REST API — это не одна кнопка, а набор маршрутов. Часть из них действительно можно закрыть, если сайт не использует внешние интеграции, мобильные приложения, headless-режим или публичную выдачу данных. Но есть запросы, которые нужны самому WordPress.
Не стоит бездумно отключать:
- эндпоинты, которые использует редактор блоков в админке;
- запросы, связанные с авторизацией и работой пользователя в панели;
- маршруты, которые нужны активным плагинам и теме;
- REST API целиком, если сайт редактируется через Gutenberg или использует современные плагины с AJAX-логикой на REST.
Обычно безопаснее ограничить доступ для неавторизованных посетителей, чем ломать API полностью. Для владельца обычного сайта это чаще всего и есть нужный результат: посторонние не видят лишние данные, а админка продолжает работать.
Самый безопасный вариант: закрыть REST API для гостей, но оставить его для админки
Если задача именно в сокращении публичных запросов, используйте фильтр rest_authentication_errors. Он позволяет запретить доступ к REST API для неавторизованных пользователей, при этом авторизованные администраторы и редакторы смогут работать как обычно.
Добавьте код в functions.php дочерней темы или, что лучше, в небольшой mu-plugin. Перед изменениями сделайте резервную копию и проверьте сайт на тестовой копии, если она есть.
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 доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 403 )
);
}
return $result;
} );Что делает этот код:
- не вмешивается, если WordPress уже вернул ошибку;
- пропускает авторизованных пользователей;
- для гостей возвращает
403 Forbidden.
Это не «полное отключение», а именно ограничение публичного доступа. Для большинства сайтов это самый разумный компромисс.
Когда нужно отключить только часть REST API
Иногда проблема не в самом API, а в конкретных маршрутах. Например, сайт не использует публичные данные пользователей, записей или таксономий, но редактор и внутренние запросы должны работать. В таком случае лучше ограничивать отдельные эндпоинты через проверку маршрута.
Ниже пример для ситуации, когда нужно закрыть только публичные запросы к данным пользователей. Такой подход уже требует аккуратности: если плагин или тема обращаются к этим маршрутам на фронтенде, они перестанут работать.
add_filter( 'rest_endpoints', function ( $endpoints ) {
if ( isset( $endpoints['/wp/v2/users'] ) ) {
unset( $endpoints['/wp/v2/users'] );
}
if ( isset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] ) ) {
unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
}
return $endpoints;
} );Такой способ подходит только если вы понимаете, какие маршруты реально используются на сайте. Если сомневаетесь, лучше не удалять эндпоинты вручную, а ограничить доступ через rest_authentication_errors.
Чего не стоит делать, если не хотите сломать сайт
В сети часто советуют «вырубить REST API одной строкой». На практике это нередко заканчивается ошибками в редакторе, проблемами с сохранением записей или поломанной работой плагинов.
Опасные сценарии:
- полное отключение REST API без проверки, использует ли сайт Gutenberg;
- удаление всех маршрутов через грубые фильтры, не понимая, какие из них нужны теме и плагинам;
- установка плагина, который блокирует REST API целиком, без режима исключений;
- одновременное ограничение REST API и других механизмов, которые использует админка, без тестирования.
Если сайт старый и редактируется классическим редактором, риск ниже. Но даже в этом случае сторонние плагины могут использовать REST API для поиска, форм, статистики, кэша, интеграций и фоновых задач.
Как проверить, что ограничение работает и ничего не сломалось
После внесения изменений проверьте не только главную страницу, но и админку. Это важнее, чем просто увидеть ошибку в браузере на публичном URL.
Минимальная проверка выглядит так:
- Откройте сайт в приватном окне браузера и перейдите на адрес
/wp-json/. - Если вы закрывали REST API для гостей, должен вернуться отказ в доступе или пустой ответ в зависимости от способа ограничения.
- Войдите в админку WordPress и откройте редактор записи или страницы.
- Попробуйте сохранить запись, обновить страницу и проверить работу блоков.
- Если на сайте есть формы, поиск, фильтры или интеграции, протестируйте их отдельно.
Если редактор блоков начал выдавать ошибки, значит ограничение задело нужные маршруты. В этом случае откатите изменения и переходите к более мягкому варианту — ограничению только для неавторизованных пользователей.
Плагин или код: что выбрать
Если нужен быстрый способ без правки файлов темы, удобнее использовать плагин, который умеет ограничивать REST API точечно. Но у плагина есть минус: вы зависите от его логики и обновлений, а иногда он закрывает больше, чем нужно.
Код через rest_authentication_errors обычно надежнее и прозрачнее. Вы точно понимаете, что происходит: гости получают запрет, авторизованные пользователи работают дальше. Для сайта, где задача сводится к сокращению публичных запросов, это чаще всего лучший вариант.
Если же у вас сложный сайт с несколькими интеграциями, сначала проверьте, какие маршруты реально используются. Иногда достаточно закрыть только отдельные публичные эндпоинты, а не весь REST API для гостей.
Практический вывод
Полностью отключать REST API в WordPress без анализа не стоит. Безопаснее ограничить его для неавторизованных пользователей и оставить доступ для админки и внутренних задач. Если нужно, можно точечно убрать отдельные маршруты, но только после проверки, что они не используются темой или плагинами.
Для обычного сайта самый рабочий сценарий — не ломать REST API целиком, а закрыть публичный доступ через код или аккуратный плагин и затем проверить редактор, сохранение записей и ключевые функции сайта.