Как отключить публичные REST API endpoints в WordPress и не сломать сайт

Публичный REST API в WordPress часто оставляют как есть, а потом удивляются лишним запросам к /wp-json/, светящимся именам авторов, лишнему шуму в логах и конфликтам с защитными плагинами. Полностью «выключать всё» обычно плохая идея: редактор блоков, мобильные приложения, некоторые темы и плагины используют REST API для работы. Поэтому задача на практике звучит иначе: ограничить публичные endpoints там, где они не нужны, и не сломать админку, редактор и интеграции.

Ниже — рабочий сценарий: как понять, что именно открыто, что можно закрыть, как проверить результат и где чаще всего ошибаются.

Когда REST API действительно стоит ограничивать

Не каждый сайт нуждается в полном доступе к публичным данным через REST. Если у вас обычный корпоративный сайт, блог или контентный проект без внешних интеграций, часто достаточно оставить только те endpoints, которые нужны редактору и внутренним механизмам WordPress. Остальное можно скрыть или ограничить по правам.

Типичные сигналы, что тема актуальна:

• в логах много запросов к /wp-json/wp/v2/users и другим публичным маршрутам;
• сканеры видят список авторов или структуру контента через REST;
• плагин безопасности ругается на открытые endpoints;
• на сайте есть кастомные endpoints, но нет понимания, кто их использует;
• нужно закрыть API от анонимных запросов, но оставить работу редактора и админки.

Диагностика: что именно открыто и кто это использует

Сначала не трогайте код. Проверьте, какие маршруты доступны и какие из них реально нужны. Самый простой способ — открыть /wp-json/ в браузере и посмотреть список namespace. Но этого мало: важно понять, какие endpoints отдают данные без авторизации.

Проверка через браузер и curl

Посмотрите ответ на базовый адрес REST API и несколько типовых маршрутов:

curl -I https://example.com/wp-json/

curl https://example.com/wp-json/wp/v2/posts?per_page=1

curl https://example.com/wp-json/wp/v2/users

Если последний запрос возвращает список пользователей или хотя бы метаданные, это уже повод проверить, нужен ли вам такой уровень открытости. На некоторых сайтах WordPress сам по себе ограничивает часть данных, но полагаться только на это не стоит.

Что проверить в админке и в плагинах

Перед ограничением REST API ответьте на три вопроса:

• используется ли редактор блоков Gutenberg;
• есть ли формы, фильтры, поиск, автодополнение или фронтенд-виджеты, которые ходят в REST;
• есть ли внешние сервисы, которые получают данные с сайта через API.

Если на сайте есть кастомная тема или плагины с AJAX-логикой, не закрывайте всё подряд. Сначала найдите конкретные маршруты, которые нужны фронтенду.

Пошаговое решение: ограничить публичный REST API точечно

Самый безопасный путь — не отключать REST API целиком, а ограничить доступ к чувствительным маршрутам для неавторизованных пользователей. Для этого удобно использовать фильтр rest_endpoints. Он позволяет убрать отдельные маршруты из публичного списка.

Вариант 1: убрать чувствительные endpoints

Добавьте код в functions.php дочерней темы или в собственный мини-плагин. Так проще контролировать изменения и не потерять их при обновлении темы.

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 API, но скрывает публичные маршруты пользователей. На большинстве сайтов этого уже достаточно, чтобы убрать лишнюю информацию для сканеров.

Вариант 2: запретить REST API для неавторизованных пользователей

Если сайт не использует публичный API вообще, можно ограничить доступ ко всем маршрутам для гостей. Но делать это нужно аккуратно: редактор и админка должны продолжать работать для авторизованных пользователей.

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 доступен только авторизованным пользователям.' ),
		array( 'status' => 401 )
	);
} );

Это уже жесткое ограничение. Его стоит применять только тогда, когда вы уверены, что фронтенд и внешние сервисы не зависят от публичного API.

Вариант 3: закрыть только отдельные маршруты через права

Если у вас есть собственный endpoint, лучше проверять права внутри callback или через permission_callback. Это правильнее, чем пытаться закрывать всё на уровне сервера.

register_rest_route( 'myplugin/v1', '/stats', array(
	'methods'             => 'GET',
	'callback'            => 'myplugin_get_stats',
	'permission_callback' => function() {
		return current_user_can( 'manage_options' );
	},
) );

Такой подход удобен для внутренних панелей, отчетов и служебных данных.

Сравнение подходов: что выбрать на практике

Если задача — убрать только утечку данных о пользователях, достаточно первого варианта. Если сайт вообще не использует публичный API, можно рассмотреть второй, но только после тестов.

Проверка результата после внедрения

После изменений не ограничивайтесь визуальной проверкой. Проверьте ответы API напрямую.

• Откройте /wp-json/wp/v2/users в браузере в режиме инкогнито.
• Проверьте, что нужные endpoints редактора и админки продолжают отвечать для авторизованного пользователя.
• Посмотрите консоль браузера на фронтенде: нет ли ошибок загрузки данных.
• Проверьте логи сервера и ошибки JavaScript после публикации записи или открытия страницы с блоками.

Если вы закрывали весь REST для гостей, протестируйте:

curl -I https://example.com/wp-json/wp/v2/posts

Ожидаемое поведение зависит от выбранной схемы: либо 401 Unauthorized, либо маршрут недоступен, либо возвращается только разрешенный набор данных.

Частые ошибки и как их исправить

Сломали редактор блоков

Это самая частая проблема после агрессивного ограничения REST API. Gutenberg и связанные с ним интерфейсы используют REST для загрузки и сохранения данных. Если после правки редактор начал выдавать ошибки, значит вы закрыли слишком много маршрутов или сделали ограничение без проверки авторизации.

Что делать: откатить жесткий запрет и перейти к точечному удалению чувствительных endpoints.

Закрыли API, но забыли про внешние интеграции

Формы, мобильные приложения, headless-фронтенд, сервисы импорта и вебхуки могут зависеть от REST. Если после изменения перестали работать отправка данных или подгрузка контента, ищите конкретный маршрут в сетевых запросах браузера и возвращайте доступ только ему.

Пытались закрыть REST через robots.txt

Это не работает так, как ожидают. robots.txt не запрещает доступ к API, а только дает указания поисковым роботам. Для защиты от сканеров и лишних запросов нужен серверный контроль доступа или фильтры WordPress.

Использовали плагин без понимания его правил

Некоторые плагины безопасности умеют ограничивать REST API, но делают это по своим сценариям. Перед включением проверьте, какие маршруты они блокируют и есть ли исключения для админки, редактора и авторизованных пользователей. Иначе получите трудно диагностируемую ошибку без явной причины.

Практические советы по безопасности и производительности

Если цель — не только безопасность, но и снижение шума, не гонитесь за полным отключением всего подряд. Лучше убрать только то, что реально не используется. Это уменьшает риск поломки и упрощает поддержку.

• держите изменения в отдельном мини-плагине, а не в теме;
• после каждого обновления плагинов проверяйте сетевые запросы в браузере;
• не закрывайте REST API на боевом сайте без теста на staging;
• если нужен только один свой endpoint, задавайте permission_callback сразу при регистрации;
• для массовой чистки технических дублей и лишних сущностей в WordPress можно использовать инструменты вроде Clearfy Pro, но только если вы понимаете, что именно отключаете и зачем.

Если у вас есть собственный код, лучше строить доступ по принципу минимально необходимого: открывать только те маршруты, которые реально нужны фронтенду или интеграциям, а не наоборот.

Когда лучше не отключать REST API

Есть ситуации, где полный или почти полный запрет принесет больше проблем, чем пользы. Это сайты с кастомным фронтендом, headless-сценарием, активным использованием Gutenberg, сложными формами и внешними сервисами, которые читают или пишут данные через API. В таких проектах правильнее не отключать REST, а ревизовать список маршрутов и права доступа.

Если сомневаетесь, начните с малого: уберите публичные endpoints пользователей, проверьте логи и только потом решайте, нужен ли более жесткий режим.