REST API в WordPress часто отключают «на всякий случай», а потом ловят странные симптомы: не работает автосохранение в редакторе, ломаются блоки, перестают отвечать формы или интеграции. На практике задача обычно не в полном отключении API, а в том, чтобы закрыть публичный доступ к лишним эндпоинтам и оставить рабочими те запросы, которые нужны сайту.
Если у вас сайт без внешнего приложения, мобильного клиента или headless-архитектуры, можно ограничить REST API для гостей. Но делать это нужно точечно: сначала понять, какие запросы реально используются, потом выбрать способ ограничения и только после этого включать правило на боевом сайте.
Когда REST API мешает и что именно нужно ограничивать
Публичный REST API сам по себе не является ошибкой. Проблемы начинаются, когда сайт получает лишнюю поверхность атаки или когда в логах видно много запросов к эндпоинтам, которые вам не нужны. Типичный сценарий — сайт на классическом WordPress, без внешних приложений, но с открытыми маршрутами вроде /wp-json/wp/v2/posts, /wp-json/wp/v2/users и служебными запросами, которые можно не отдавать гостям.
Что стоит проверить до изменений
- Использует ли сайт Gutenberg или редактор блоков.
- Есть ли плагины, которые работают через REST API: формы, поиск, фильтры, кеширование, аналитика.
- Есть ли внешние интеграции: мобильное приложение, headless-фронтенд, CRM, чат-бот.
- Появляются ли в логах запросы к
/wp-json/от ботов или сканеров.
Если редактор блоков используется, полностью отключать REST API нельзя. В этом случае лучше закрыть только часть маршрутов для неавторизованных пользователей или для конкретных типов запросов.
Диагностика: как понять, что REST API нужен сайту
Самый быстрый способ — открыть сайт в браузере, авторизоваться как администратор и посмотреть, не появляются ли ошибки в консоли. Если редактор Gutenberg уже работает нестабильно, сначала исправьте эти ошибки, а не режьте API. Второй шаг — проверить, какие запросы идут к /wp-json/ при загрузке страницы и в админке.
В Chrome DevTools откройте вкладку Network и отфильтруйте по wp-json. Если запросы идут только в админке и редакторе, а на фронтенде их нет, ограничение для гостей обычно безопаснее, чем полный запрет.
Еще один практичный тест — временно включить логирование и посмотреть, кто обращается к REST API. Для этого не нужен отдельный плагин, достаточно стандартного сервера и журнала доступа. Если в логах много запросов к /wp-json/wp/v2/users или другим публичным маршрутам, это уже аргумент в пользу ограничения.
Пошаговое решение: ограничить REST API для гостей
Ниже — рабочий вариант через фильтр rest_authentication_errors. Он не отключает API полностью, а возвращает ошибку для неавторизованных пользователей. Такой подход подходит только если вы уверены, что гостям REST API не нужен.
<?php
add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
if ( is_user_logged_in() ) {
return $result;
}
return new WP_Error(
'rest_disabled',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
} );Код можно добавить в дочернюю тему или в собственный мини-плагин. Для продакшена мини-плагин надежнее: он не зависит от темы и не пропадет при смене шаблона.
Если нужно оставить API для части запросов
Иногда полный запрет слишком грубый. Тогда лучше ограничить только чувствительные маршруты, например список пользователей. Для этого удобнее использовать фильтр rest_endpoints и убрать конкретные route.
<?php
add_filter( 'rest_endpoints', function( $endpoints ) {
if ( ! is_user_logged_in() ) {
unset( $endpoints['/wp/v2/users'] );
unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
}
return $endpoints;
} );Это более аккуратный вариант, если вам нужно сохранить работу редактора и плагинов, но убрать самые очевидные точки утечки данных.
Сравнение подходов: плагин, код или серверное правило
| Подход | Когда подходит | Минусы |
|---|---|---|
| Плагин безопасности | Если нужен быстрый запуск без кода | Может конфликтовать с другими плагинами, сложнее контролировать точечно |
| Код через фильтры WordPress | Если нужен точный контроль над маршрутами | Нужно тестировать на редакторе, формах и интеграциях |
| Правило на сервере | Если нужно отрезать лишние запросы до PHP | Легко сломать легитимные запросы, особенно для админки и REST |
Для большинства сайтов с обычной темой и без внешнего приложения лучше начинать с кода на уровне WordPress. Серверные правила оставьте на случай, когда вы точно понимаете, какие маршруты нужно блокировать.
Как проверить, что ограничение сработало
После внедрения откройте сайт в режиме инкогнито и проверьте несколько вещей:
- страницы фронтенда загружаются без ошибок;
- редактор записей открывается и сохраняет изменения;
- автосохранение работает;
- в консоли браузера нет ошибок, связанных с
wp-json; - запросы к закрытым маршрутам возвращают
401или отсутствуют вовсе.
Для точечной проверки можно открыть в браузере адрес /wp-json/wp/v2/users. Если вы ограничивали доступ для гостей, неавторизованный запрос должен быть заблокирован. При этом в админке и для авторизованного пользователя поведение должно остаться нормальным.
Если у вас есть формы, поиск или фильтры, обязательно прогоните их отдельно. Некоторые плагины используют REST API неочевидно, и проблема проявляется только при отправке формы или переключении фильтра.
Частые ошибки и как их исправить
Полностью отключили REST API и сломали редактор
Это самая частая ошибка. Gutenberg, автосохранение и часть интерфейса админки завязаны на REST API. Если после отключения редактор начал выдавать ошибки, откатите изменение и переходите к точечному ограничению маршрутов.
Поставили правило в .htaccess без проверки
Серверное правило может заблокировать не только гостей, но и полезные запросы из админки. Если вы не уверены в конфигурации, лучше сначала реализовать ограничение через фильтры WordPress и только потом переносить логику на сервер.
Не проверили плагины форм и кеша
Некоторые плагины работают через REST API даже если это не видно в интерфейсе. После изменения обязательно проверьте формы, AJAX-поиск, фильтры и любые блоки, которые подгружают данные динамически.
Забыли про внешние интеграции
Если сайт подключен к CRM, мобильному приложению или стороннему сервису, ограничение REST API может отрезать обмен данными. Перед внедрением проверьте, какие токены, маршруты и методы используются интеграцией.
Практические советы по безопасности и производительности
Если цель — не просто «выключить что-то лишнее», а реально уменьшить поверхность атаки, начните с аудита. Уберите ненужные публичные маршруты, ограничьте список пользователей в API, проверьте, не светятся ли в ответах лишние поля. Для части задач полезнее не отключение, а настройка кеширования и защита на уровне сервера.
Если на сайте много технических дублей, мусорных архивов и лишних служебных страниц, имеет смысл параллельно навести порядок в SEO-настройках и очистке сайта. Для этого часто используют Clearfy Pro, но только как инструмент для системной чистки, а не как замену пониманию того, что именно вы отключаете.
Хорошая практика — хранить все такие изменения в отдельном мини-плагине и документировать, какие маршруты вы закрыли и почему. Тогда при обновлении темы или переносе сайта не придется вспоминать, где именно была сделана правка.
Когда лучше не отключать REST API
Если сайт использует современный редактор, внешние сервисы или headless-подход, отключение API принесет больше вреда, чем пользы. В таких проектах правильнее ограничивать доступ по ролям, токенам или конкретным маршрутам, а не рубить всё целиком. Это особенно важно для сайтов, где контент редактируют несколько человек и где ошибки в админке стоят дороже, чем потенциальная экономия на «лишних» запросах.