WP REST API часто оставляют открытым «как есть», а потом удивляются лишним запросам, утечке служебных данных и шуму в логах. Полностью отключать API обычно плохая идея: Gutenberg, мобильные приложения, некоторые плагины и интеграции используют его штатно. Рабочий подход другой — убрать только то, что не нужно, и оставить доступ для авторизованных пользователей и нужных маршрутов.
Когда это действительно проблема
Ограничение REST API имеет смысл, если вы видите хотя бы один из сценариев:
- в логах много запросов к
/wp-json/от ботов и сканеров; - на сайте есть публичные эндпоинты, которые отдают лишние данные;
- плагин безопасности ругается на перечисление пользователей через REST;
- нужно закрыть API на сайте-витрине, но оставить его для админки и редактора;
- внешняя интеграция работает через конкретный маршрут, а остальное можно ограничить.
Что не стоит делать
Не отключайте REST API целиком через грубые фильтры, если не проверили зависимости. Частая ошибка — сломать редактор блоков, предпросмотр записей, формы обратной связи или синхронизацию с сервисами, которые обращаются к API в фоне.
Диагностика: что именно использует REST API на вашем сайте
Сначала проверьте, какие запросы реально идут. Откройте главную страницу, страницу записи и админку в отдельной вкладке, а затем посмотрите сетевые запросы в DevTools по фильтру wp-json. Если есть доступ к серверным логам или плагину аудита, посмотрите, какие маршруты вызываются чаще всего.
Минимальный чек-лист перед изменениями:
- проверить, используется ли Gutenberg;
- проверить формы, которые отправляют данные через REST;
- зафиксировать сторонние интеграции: CRM, чат, поиск, headless-часть;
- сделать резервную копию файлов и базы;
- внести изменения сначала на staging, если он есть.
Пошаговое решение: ограничиваем REST API точечно
Самый безопасный вариант — не блокировать всё, а возвращать ошибку для неавторизованных запросов, кроме нужных маршрутов. Ниже пример, который оставляет доступ для админки и авторизованных пользователей, а для остальных ограничивает публичные запросы.
<?php
add_filter('rest_authentication_errors', function ($result) {
if (!empty($result)) {
return $result;
}
if (is_user_logged_in()) {
return $result;
}
$uri = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '';
// Разрешаем только нужные маршруты, если они реально используются.
$allowed = array(
'/wp-json/oembed/1.0/',
'/wp-json/wp/v2/posts',
'/wp-json/wp/v2/pages',
);
foreach ($allowed as $path) {
if (strpos($uri, $path) !== false) {
return $result;
}
}
return new WP_Error(
'rest_forbidden',
__('REST API доступен только авторизованным пользователям.'),
array('status' => 401)
);
});Этот вариант подходит не для всех сайтов. Если у вас есть публичный поиск, комментарии, формы или интеграция с внешним сервисом, список $allowed нужно подстроить под реальные маршруты. Иначе вы получите не «защиту», а поломку функциональности.
Если нужно скрыть только данные пользователей
Частая задача — убрать публичную выдачу пользователей через REST, но не трогать остальной API. Для этого достаточно ограничить маршрут пользователей:
<?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;
});Это не универсальная защита, но для многих обычных сайтов она решает конкретную задачу: убрать лишнюю поверхность атаки без вмешательства в остальной API.
Плагин, код или серверное правило: что выбрать
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин безопасности | Нужно быстро закрыть часть маршрутов без разработки | Может добавлять лишнюю логику и зависимость от настроек |
| Код в теме или mu-plugin | Нужен точный контроль над маршрутами | Требует проверки после обновлений и тестирования |
| Серверное правило | Нужно блокировать запросы на уровне nginx/apache | Легко сломать легитимные запросы, если не знать маршруты |
Если задача типовая и без сложных интеграций, код в mu-plugin обычно удобнее: он не зависит от темы и не отключится случайно после обновления.
Проверка результата после внедрения
После изменений проверьте не только главную страницу, но и функции, которые часто завязаны на REST API:
- открывается ли редактор записей;
- работает ли предпросмотр;
- отправляются ли формы;
- не появились ли ошибки в консоли браузера;
- не вернулись ли 401/403 на нужных маршрутах;
- не сломались ли интеграции с внешними сервисами.
Быстрая проверка из браузера:
https://example.com/wp-json/Если сайт должен отдавать API только авторизованным пользователям, в ответе для гостя вы должны видеть ограничение доступа, а не полный список маршрутов. Если какой-то плагин перестал работать, ищите его запросы в DevTools и добавляйте нужный маршрут в исключения.
Частые ошибки и как их исправить
Сломали Gutenberg
Причина обычно в том, что заблокировали слишком общий маршрут или весь /wp-json/. Решение: вернуть доступ для авторизованных пользователей и не резать маршруты, которые использует редактор.
Отключили API, но забыли про внешнюю интеграцию
CRM, чат-виджеты, формы и headless-части могут обращаться к REST API без очевидных признаков. Сначала проверьте сетевые запросы и только потом ограничивайте доступ.
Проверяли только главную страницу
На главной всё может быть тихо, а на записи или в админке уже появятся ошибки. Тестируйте разные типы страниц и сценарии входа в систему.
Использовали серверный запрет без исключений
Если блокировать /wp-json/ на уровне сервера, можно случайно закрыть полезные маршруты, которые не видны на первый взгляд. Такой способ имеет смысл только когда вы точно знаете, что именно должно остаться доступным.
Практические советы по безопасности и производительности
Если цель — не только безопасность, но и снижение шума, не гонитесь за полным отключением API. Лучше:
- убрать ненужные публичные маршруты;
- ограничить выдачу пользовательских данных;
- оставить доступ только для авторизованных запросов там, где это допустимо;
- проверить, не создаёт ли плагин лишние REST-запросы на каждой странице;
- держать изменения в
mu-plugin, если они должны переживать смену темы.
Если вам нужен более широкий набор мер по чистке сайта и удалению лишних поверхностей WordPress, имеет смысл посмотреть в сторону инструментов класса Clearfy Pro: он помогает убирать часть технического мусора и дублирующих функций, но перед применением всё равно нужно проверять, что именно отключается на вашем сайте. Ссылка без слеша: Clearfy Pro.
Главный критерий успеха здесь простой: сайт продолжает работать, а лишние публичные маршруты больше не доступны без необходимости. Если после правок вы не видите ошибок в админке, редактор открывается, а ненужные запросы к REST API исчезли или стали недоступны для гостей, решение внедрено корректно.