REST API в WordPress часто отключают слишком грубо: ставят блокировку на весь /wp-json/ и потом удивляются, что ломается редактор блоков, автосохранение, формы, мобильные приложения или внешние интеграции. Если задача не в полном запрете API, а именно в том, чтобы закрыть его для гостей, нужен более точный подход.
Ниже разберём рабочую схему: как понять, кто реально использует REST API, как ограничить доступ только для неавторизованных пользователей, чем отличается код от плагина, и как проверить, что после изменений сайт остался рабочим.
Когда REST API действительно стоит ограничить
Не каждый сайт нуждается в открытом REST API для гостей. Но перед отключением важно понять, что именно вы хотите убрать:
- снизить “шум” в ответах сервера и убрать лишние публичные эндпоинты;
- закрыть доступ к данным записей, пользователей и таксономий для анонимных запросов;
- убрать следы WordPress в публичной части сайта;
- сократить поверхность атаки, если API не используется внешними сервисами.
Если у вас работает Gutenberg, мобильное приложение WordPress, headless-фронтенд, формы, которые отправляют данные через REST, или сторонний сервис интеграции — полное отключение не подходит. В таких случаях ограничивают только гостей, а авторизованным пользователям API оставляют.
Диагностика: что именно использует REST API на сайте
Перед изменениями проверьте, есть ли реальные обращения к API. На практике это можно сделать без сложных инструментов.
Что посмотреть в браузере и в консоли
Откройте главную страницу сайта и страницу редактирования записи. В DevTools на вкладке Network отфильтруйте запросы по wp-json. Если видите регулярные запросы к /wp-json/wp/v2/, /wp-json/oembed/1.0/ или к эндпоинтам плагинов, значит API используется.
Отдельно проверьте:
- редактор блоков в админке;
- автосохранение и предпросмотр записей;
- формы, которые отправляют данные без перезагрузки;
- поиск по сайту, если он завязан на AJAX и REST;
- внешние сервисы, которые получают или отправляют данные на сайт.
Быстрая проверка через curl
Если нужен минимальный тест, выполните запрос к публичному эндпоинту:
curl -I https://example.com/wp-json/Для гостя ответ обычно будет 200 OK или редирект на JSON-индекс. После ограничения доступа для неавторизованных пользователей вы должны увидеть либо 401/403, либо ответ, который вы сами определили в коде.
Как ограничить REST API только для гостей
Самый предсказуемый вариант — не отключать API целиком, а вернуть ошибку только для неавторизованных запросов. Для этого подходит фильтр rest_authentication_errors.
Вариант через код в теме или mu-plugin
Лучше добавлять такой код в mu-plugin или в отдельный мини-плагин, а не в functions.php активной темы. Так ограничение не исчезнет после смены темы.
<?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'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';
$allowed = array(
'/wp-json/oembed/1.0/',
);
foreach ( $allowed as $path ) {
if ( strpos( $uri, $path ) !== false ) {
return $result;
}
}
return new WP_Error(
'rest_forbidden',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
} );Что делает этот код:
- не трогает уже существующие ошибки аутентификации;
- оставляет доступ авторизованным пользователям;
- может разрешить отдельные публичные маршруты, если они нужны;
- возвращает понятный статус
401для гостей.
Если у вас есть конкретные публичные эндпоинты плагинов, их лучше добавить в белый список точечно, а не открывать весь API.
Вариант через плагин
Если не хотите писать код, можно использовать плагин для технической очистки сайта. Например, в Clearfy Pro есть функции, связанные с отключением лишних компонентов WordPress и сокращением публичной поверхности сайта: https://wpshop.ru/plugins/clearfy. Но даже в этом случае логику доступа стоит проверить вручную: на некоторых сайтах нужен не полный запрет, а частичное ограничение.
| Подход | Плюсы | Минусы |
|---|---|---|
Код через rest_authentication_errors | Точно контролируете доступ, можно оставить исключения | Нужно тестировать зависимости вручную |
| Плагин для технической очистки | Быстрее внедрить, меньше ручной рутины | Не всегда подходит для нестандартных интеграций |
Полная блокировка /wp-json/ на уровне сервера | Жёстко закрывает маршрут | Чаще всего ломает редактор и сторонние сервисы |
Почему не стоит резать REST API на уровне .htaccess без проверки
Иногда советуют просто закрыть /wp-json/ через веб-сервер. Это выглядит быстро, но на практике слишком грубо. WordPress и плагины используют REST не только для публичных данных. Если заблокировать маршрут на уровне Apache или Nginx, вы не сможете гибко разрешить отдельные эндпоинты.
Такой способ допустим только если вы точно знаете, что сайт не использует REST API вообще. Для обычного WordPress-сайта это редкий случай. Даже если на фронтенде ничего не видно, админка может обращаться к API постоянно.
Пошаговое внедрение без поломки сайта
- Сделайте резервную копию файлов и базы.
- Проверьте, какие запросы к
/wp-json/идут на фронтенде и в админке. - Добавьте ограничение через
rest_authentication_errorsв mu-plugin или отдельный плагин. - Если нужен публичный эндпоинт, внесите его в белый список.
- Очистите кэш страницы, объектный кэш и CDN, если они есть.
- Проверьте редактор, формы, поиск и интеграции.
Как проверить, что ограничение сработало
После внедрения не ограничивайтесь открытием главной страницы. Проверка должна быть практической.
Минимальный чек-лист
- Откройте
/wp-json/в браузере в режиме инкогнито — для гостя должен быть отказ или ваш кастомный ответ. - Зайдите в админку и откройте редактор записи — автосохранение и предпросмотр должны работать.
- Проверьте отправку форм, если они завязаны на REST.
- Посмотрите консоль браузера на ошибки
401или403по нужным маршрутам. - Проверьте логи сервера, если после изменений выросло число ошибок.
Если что-то сломалось, не ищите проблему только в коде ограничения. Часто виноват конкретный плагин, который использует REST API для AJAX-логики.
Частые ошибки и как их исправить
Полностью блокируют весь /wp-json/
Это самая частая ошибка. В результате ломается редактор блоков, oEmbed, формы и интеграции. Исправление простое: не блокируйте маршрут целиком, а фильтруйте доступ по пользователю и по нужным эндпоинтам.
Добавляют код в functions.php и забывают о теме
После смены темы ограничение исчезает. Для технических правил лучше использовать mu-plugin или отдельный плагин.
Не проверяют сторонние плагины
Некоторые плагины используют REST API для поиска, фильтров, отправки данных и синхронизации. Если после ограничения перестала работать часть интерфейса, сначала отключите подозрительные плагины по одному и посмотрите, какой маршрут им нужен.
Возвращают неправильный статус
Если вместо 401 или 403 вы отдаёте пустой ответ или редирект, диагностика становится сложнее. Лучше явно вернуть WP_Error со статусом.
Безопасность и производительность: что учесть дополнительно
Ограничение REST API само по себе не заменяет базовую защиту сайта. Если цель — уменьшить поверхность атаки, проверьте ещё несколько вещей:
- не оставляйте открытыми ненужные публичные эндпоинты плагинов;
- обновляйте плагины, которые используют REST для AJAX;
- не отключайте API на боевом сайте без теста на staging;
- если есть кэш страниц, убедитесь, что он не отдаёт старые ответы после правок;
- не используйте одинаковый код на всех проектах без белого списка исключений.
Если сайт большой и с несколькими интеграциями, сначала составьте список маршрутов, которые реально используются. Это дешевле, чем потом искать, почему перестала отправляться форма или не сохраняется запись.
В итоге безопаснее всего ограничивать REST API точечно: для гостей — закрыть, для авторизованных — оставить, для нужных публичных маршрутов — сделать исключения. Такой подход даёт контроль без лишних поломок и не превращает техническую настройку в лотерею.