Если на сайте WordPress нужно сократить лишние запросы или закрыть часть поверхности атаки, обычно речь идёт не о полном отключении REST API, а об ограничении доступа для гостей. Полностью рубить API на живом сайте опасно: многие темы, блоки редактора, формы, поиск, AJAX-сценарии и плагины используют его для работы. Гораздо безопаснее запретить доступ неавторизованным пользователям только к тем эндпоинтам, которые действительно не должны быть публичными.
Ниже — практичный вариант: что именно ограничивать, что оставить открытым и как проверить, что после правки сайт не начал сыпаться ошибками.
Что именно отключают, когда говорят про REST API
REST API в WordPress — это набор HTTP-эндпоинтов вида /wp-json/. Через них сайт отдаёт данные о записях, страницах, пользователях, таксономиях, настройках и многом другом. Для гостя часть этих данных может быть лишней, но не всё в API одинаково безопасно отключать.
Если задача — ограничить доступ только для неавторизованных пользователей, обычно делают так:
- закрывают доступ к большинству эндпоинтов для гостей;
- оставляют доступ к тем запросам, которые нужны фронтенду сайта или внешним сервисам;
- не трогают сам WordPress-редактор и внутренние запросы, если сайт ими пользуется.
Важно понимать разницу между отключить REST API и запретить его для всех. Второй вариант часто ломает сайт сильнее, чем кажется на первый взгляд.
Когда REST API лучше не закрывать полностью
Полное отключение API оправдано редко. На обычном сайте это может привести к таким последствиям:
- перестанут работать блоки и некоторые функции редактора;
- сломаются формы, слайдеры, фильтры, поиск или другие элементы, которые получают данные через API;
- появятся ошибки в консоли браузера;
- часть плагинов начнёт возвращать пустые ответы или 401/403.
Если сайт использует Gutenberg, headless-сценарии, мобильное приложение, интеграции или внешние сервисы, закрывать REST API без проверки нельзя. В таких случаях обычно ограничивают только публичные запросы, а не весь механизм целиком.
Безопасный способ: запретить REST API для гостей через код
Если нужен контролируемый вариант без установки лишних плагинов, проще всего добавить небольшой фильтр в functions.php дочерней темы или в собственный мини-плагин. Этот способ позволяет вернуть ошибку гостям, но оставить доступ авторизованным пользователям.
Перед изменением кода сделайте резервную копию файла или работайте через дочернюю тему. Если вставить код с ошибкой, можно получить белый экран или поломать админку.
Вот рабочий пример, который запрещает доступ к REST API всем неавторизованным пользователям, кроме нескольких публичных маршрутов:
add_filter( 'rest_authentication_errors', function ( $result ) {
if ( true === $result ) {
return $result;
}
if ( ! empty( $result ) ) {
return $result;
}
if ( is_user_logged_in() ) {
return $result;
}
$request_uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';
$allowed_prefixes = array(
'/wp-json/wp/v2/posts',
'/wp-json/wp/v2/pages',
'/wp-json/oembed/1.0',
);
foreach ( $allowed_prefixes as $prefix ) {
if ( str_starts_with( $request_uri, $prefix ) ) {
return $result;
}
}
return new WP_Error(
'rest_forbidden',
__( 'REST API доступен только авторизованным пользователям.', 'textdomain' ),
array( 'status' => 401 )
);
} );Этот пример намеренно простой. Он проверяет, вошёл ли пользователь в систему, и если нет — блокирует запрос. При этом можно оставить отдельные публичные маршруты. Но у такого подхода есть нюанс: он ориентируется на URI запроса, а не на объект маршрута WordPress, поэтому для сложных проектов лучше делать более точную проверку через сам маршрут.
Если вам нужен более аккуратный контроль, используйте фильтр rest_pre_dispatch или проверяйте конкретные маршруты через rest_endpoints. Но для большинства сайтов достаточно либо ограничить доступ к API целиком для гостей, либо оставить только несколько публичных маршрутов.
Как оставить доступными только нужные эндпоинты
На практике обычно не нужно открывать весь REST API. Чаще всего достаточно разрешить только те запросы, которые реально используются на фронтенде. Например:
/wp-json/wp/v2/posts— если тема или виджеты подгружают записи;/wp-json/wp/v2/pages— если на сайте есть публичная выдача страниц;/wp-json/oembed/1.0— если вы встраиваете внешние материалы и не хотите ломать oEmbed;- кастомные маршруты плагинов, если они отвечают за форму, фильтр или каталог.
Не стоит по привычке оставлять открытым всё подряд. Чем меньше публичных маршрутов, тем проще контролировать поведение сайта и тем меньше лишних запросов будет приходить от ботов и внешних сканеров.
Если вы не уверены, какие маршруты нужны, сначала проверьте сайт в обычном режиме: откройте главную, записи, страницы, архивы, формы, поиск и интерактивные элементы. Затем посмотрите, какие запросы идут в /wp-json/ через инструменты разработчика браузера. Это самый надёжный способ понять, что реально используется именно вашим сайтом.
Как проверить, что ограничение работает и ничего не сломалось
После внесения изменений проверьте сайт в двух состояниях: как гость и как авторизованный пользователь.
Для гостя откройте в браузере адрес https://ваш-домен.ru/wp-json/. Если вы закрыли API полностью, должен вернуться ответ с ошибкой доступа, а не список маршрутов. Если вы оставили только часть эндпоинтов, проверьте именно их: например, /wp-json/wp/v2/posts или нужный маршрут плагина.
Затем откройте сайт в обычном режиме и убедитесь, что:
- страницы загружаются без ошибок;
- формы отправляются;
- поиск работает;
- в консоли браузера нет массовых ошибок 401 или 403 по REST-запросам;
- админка и редактор работают как раньше.
Если после ограничения API что-то перестало работать, не пытайтесь сразу отключать всё обратно. Сначала найдите конкретный запрос, который нужен теме или плагину, и добавьте только его в список разрешённых маршрутов.
Что делать, если нужен именно полный запрет для гостей
Иногда задача сформулирована жёстко: никаких публичных ответов REST API. Это допустимо только если вы точно знаете, что сайт не использует API на фронтенде и не зависит от внешних интеграций. В таком случае можно оставить доступ только авторизованным пользователям и заблокировать гостей целиком.
Но перед этим проверьте три вещи:
- не использует ли тема REST API для подгрузки контента;
- нет ли плагинов с фронтенд-формами, фильтрами или каталогами;
- не завязаны ли на API сторонние сервисы, которые получают данные с сайта.
Если хотя бы один из пунктов под вопросом, лучше не делать полный запрет. На практике безопаснее ограничить доступ к чувствительным маршрутам и оставить публичными только те, что действительно нужны.
Когда лучше использовать плагин, а когда код
Если вы не хотите править тему вручную, можно использовать плагин для ограничения REST API. Это удобно, когда нужно быстро включить защиту без редактирования файлов. Но у плагина есть минус: он добавляет ещё один слой логики, который нужно поддерживать и проверять после обновлений.
Код в дочерней теме или мини-плагине обычно надёжнее, если задача простая и понятная: закрыть API для гостей, оставить несколько маршрутов, проверить результат. Для сайта с нестандартными интеграциями код тоже предпочтительнее, потому что вы сами контролируете, что именно разрешено.
Если же у вас нет доступа к файлам сайта или вы не хотите рисковать, плагин может быть временным решением. Но и в этом случае проверка после включения обязательна: REST API часто связан не только с безопасностью, но и с работой интерфейса.
Итог здесь практический: не отключайте REST API вслепую. Сначала определите, какие запросы действительно нужны сайту, затем закройте лишнее для гостей и только после этого проверьте фронтенд, админку и консоль браузера. Так вы получите и более закрытый сайт, и меньше шансов сломать тему или плагины.