Как отключить открытые JSON REST API endpoints в WordPress

REST API в WordPress нужен не только для Gutenberg и современных плагинов. Но на обычных сайтах часть endpoint'ов оказывается лишней: они светят структуру контента, создают шум в логах и иногда становятся точкой для перебора данных. Полностью выключать REST API обычно плохая идея — проще и безопаснее убрать только то, что реально не используется.

Когда проблема действительно есть

Сначала стоит понять, что именно вы хотите отключить. Часто под «открытым REST API» имеют в виду разные вещи: публичные записи и страницы в /wp-json/wp/v2/, служебные маршруты плагинов, endpoint'ы для пользователей, комментариев или медиа. Если сайт работает на Gutenberg, отключение всего API сломает редактор и часть админки. Если же контент редактируется классически, а внешние интеграции отсутствуют, можно точечно ограничить доступ.

Что проверить до изменений

Используется ли блоковый редактор Gutenberg.
Есть ли плагины, которые обращаются к REST API на фронтенде.
Нужны ли внешние интеграции: мобильное приложение, headless-фронтенд, формы, CRM.
Есть ли в логах частые запросы к /wp-json/ без понятной причины.

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

Диагностика: что именно открыто

Перед правками посмотрите, какие маршруты вообще доступны. Самый простой способ — открыть /wp-json/ в браузере или через curl. Это покажет список namespace'ов и endpoint'ов. Дальше можно понять, что относится к ядру WordPress, а что добавлено темой или плагинами.

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

Если ответ 200 OK, API доступен. Это нормально. Вопрос не в самом факте доступности, а в том, какие данные отдаются без необходимости. Для проверки конкретного маршрута можно запросить, например, записи:

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

Если в ответе видны заголовки, excerpt, ссылки на авторов и так далее, значит endpoint работает как задумано. Дальше решаем, нужно ли это на публичной части сайта.

Как отключить лишние REST API endpoint'ы

Есть три рабочих подхода: плагин для точечной настройки, код в functions.php или mu-plugin, и серверная фильтрация на уровне веб-сервера. Для большинства сайтов достаточно кода в отдельном мини-плагине или mu-plugin: так проще контролировать изменения и не потерять их при обновлении темы.

Подход	Когда подходит	Минус
Плагин	Если нужен интерфейс и быстрый откат	Лишняя зависимость и риск конфликтов
Код	Если нужен точечный контроль	Нужно аккуратно тестировать
Серверная блокировка	Если нужно резать доступ до PHP	Можно случайно сломать интеграции

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

Если сайт не использует публичный API, можно ограничить доступ к данным для гостей. Этот вариант не выключает REST API полностью, но скрывает ответы для неавторизованных запросов. Код лучше размещать в mu-plugin, чтобы он работал независимо от темы.

<?php
/**
 * Plugin Name: Restrict REST API for guests
 */

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

Этот способ грубый, но понятный. Он подходит для внутренних сайтов, корпоративных порталов и проектов, где API нужен только в админке. Для публичных сайтов с Gutenberg его использовать нельзя: редактор и часть запросов перестанут работать.

Вариант 2: скрыть только отдельные маршруты

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

<?php
add_filter( 'rest_endpoints', function( $endpoints ) {
    unset( $endpoints['/wp/v2/users'] );
    unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );

    return $endpoints;
} );

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

Вариант 3: закрыть REST API на уровне сервера

Иногда администраторы пытаются блокировать /wp-json/ через .htaccess или nginx. Это допустимо только если вы точно знаете, что API не нужен вообще. Иначе легко получить скрытые ошибки в редакторе, формах и интеграциях. Серверная блокировка имеет смысл для очень старых сайтов без Gutenberg и без внешних подключений.

Для Apache можно ограничить доступ к маршруту, но лучше сначала протестировать на staging. Для nginx логика будет другой, и универсального безопасного шаблона здесь нет: конфигурация зависит от того, как именно у вас отдаются permalink'и и какие исключения нужны.

Пошаговое решение без поломки сайта

Проверьте, используется ли Gutenberg и REST API-плагины.
Сделайте резервную копию файлов и базы.
Добавьте код в mu-plugin или отдельный плагин, а не в активную тему.
Сначала ограничьте только один маршрут, например /wp/v2/users.
Проверьте фронтенд, админку и редактор.
Если всё работает, при необходимости расширяйте список отключаемых endpoint'ов.

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

Как проверить, что решение сработало

После внедрения проверьте не только код ответа, но и побочные эффекты. Для этого достаточно нескольких ручных тестов.

Откройте /wp-json/ в браузере и убедитесь, что нужные маршруты остались доступны.
Проверьте страницу записи в редакторе Gutenberg.
Откройте фронтенд сайта в режиме инкогнито.
Посмотрите консоль браузера на наличие ошибок запросов к REST API.
Если есть формы или виджеты, отправьте тестовый запрос и проверьте ответ сервера.

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

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

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

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

Полностью отключили REST API на живом сайте

Это самая частая проблема. После такого решения ломается Gutenberg, AJAX-запросы плагинов и иногда даже часть темы. Исправление простое: вернуть API и ограничить только ненужные маршруты или доступ для гостей.

Добавили код в тему

Если код лежит в functions.php, он исчезнет при смене темы. Для технических ограничений лучше использовать mu-plugin или отдельный мини-плагин. Так вы не привязываете безопасность и инфраструктурную логику к дизайну.

Удалили маршрут, который использовал плагин

Некоторые плагины обращаются к REST API незаметно для администратора. После удаления endpoint'а появляются ошибки в консоли или не работают отдельные блоки. Решение — найти источник запроса через DevTools или лог плагина и либо оставить маршрут, либо заменить плагин.

Проверяли только главную страницу

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

Что делать для безопасности и производительности

Отключение лишних endpoint'ов — не замена базовой гигиене. Если цель в защите, дополнительно проверьте права пользователей, актуальность плагинов и наличие лишних публичных ролей. Если цель в производительности, не ждите чудес: REST API обычно не главный источник нагрузки, но лишние маршруты и ошибки запросов действительно создают шум.

Полезная практика — вести изменения через staging и хранить технические правки отдельно от темы. Если на сайте много SEO- и технических настроек, иногда удобнее собрать их в одном инструменте, чем держать разрозненные сниппеты. Но даже в этом случае важно понимать, какие именно endpoint'ы вы отключаете и зачем.

Если нужен более широкий набор технических настроек, чистка лишних функций и контроль дублей, можно посмотреть Clearfy Pro. Но для задачи с REST API всё равно полезно сначала разобраться, какой маршрут создаёт проблему и не затрагивает ли он редактор или интеграции.

В итоге правильный подход здесь не «выключить всё», а убрать только то, что реально не используется. Это сохраняет совместимость и снижает риск неожиданной поломки после обновлений WordPress или плагинов.