Как ограничить доступ к WP REST API для неавторизованных запросов в WordPress

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

Типичный сценарий: в логах много запросов к /wp-json/, в отчётах по безопасности видны обращения к маршрутам API, а сайт при этом не использует внешние приложения, мобильные клиенты или публичные эндпоинты. В такой ситуации имеет смысл ограничить доступ для неавторизованных пользователей и отдельно проверить, не зависит ли от API тема или плагины.

Когда ограничение REST API действительно уместно

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

Если же на сайте есть:

• редактор блоков Gutenberg;
• фронтенд-формы, которые отправляют данные через REST;
• мобильное приложение;
• интеграция с внешним сервисом;
• кастомная тема или плагин, который получает данные через wp-json;

тогда нужно ограничивать точечно, а не рубить API целиком.

Диагностика: что именно обращается к wp-json

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

Проверка в браузере и логах

Откройте страницу сайта и в DevTools посмотрите вкладку Network. Если видите запросы к /wp-json/, обратите внимание на источник: это может быть сам WordPress, тема, блоки, плагин аналитики или внешний скрипт.

В access-логах nginx или Apache полезно искать строки с /wp-json/. Если запросы идут массово от неизвестных ботов, это уже аргумент в пользу ограничения.

Быстрая проверка через код

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

<?php
add_filter('rest_pre_dispatch', function ($result, $server, $request) {
    if (!is_user_logged_in()) {
        error_log('REST request: ' . $request->get_route());
    }
    return $result;
}, 10, 3);

После проверки код лучше убрать, чтобы не засорять логи.

Пошаговое решение: ограничить REST API для гостей

Самый безопасный вариант — разрешить REST API для авторизованных пользователей и заблокировать публичные запросы, если они не нужны. Для этого можно использовать фильтр rest_authentication_errors.

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

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

Более мягкий вариант: закрыть только часть маршрутов

Если нужно оставить, например, /wp-json/wp/v2/posts для публичного чтения, а закрыть служебные маршруты, используйте проверку маршрута и возвращайте ошибку только для нужных путей.

<?php
add_filter('rest_pre_dispatch', function ($result, $server, $request) {
    if (is_user_logged_in()) {
        return $result;
    }

    $route = $request->get_route();

    $blocked_prefixes = array(
        '/wp/v2/users',
        '/wp/v2/settings',
        '/wp/v2/media',
    );

    foreach ($blocked_prefixes as $prefix) {
        if (strpos($route, $prefix) === 0) {
            return new WP_Error(
                'rest_forbidden_route',
                __('Этот маршрут REST API закрыт для гостей.', 'textdomain'),
                array('status' => 403)
            );
        }
    }

    return $result;
}, 10, 3);

Такой подход удобнее, если вы не хотите ломать публичные данные, но хотите убрать чувствительные маршруты.

Сравнение подходов

Если нужен быстрый старт без разработки, можно использовать плагин из класса security-плагинов. Но если задача техническая и у вас есть доступ к теме или mu-plugins, код обычно предсказуемее.

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

После внедрения откройте несколько проверок вручную:

• в браузере зайдите на /wp-json/ в режиме инкогнито;
• проверьте страницу записи и главную;
• если используется редактор блоков, откройте запись в админке;
• посмотрите, не появились ли ошибки JavaScript в консоли;
• проверьте, не сломались ли формы, виджеты или блоки, которые подгружают данные через REST.

Для технической проверки удобно использовать curl:

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

Если вы закрыли API для гостей, ответ должен соответствовать вашей логике: 401 или 403, а не полноценный JSON-ответ с данными.

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

Полностью отключили REST API и сломали редактор

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

Решение: не отключайте API целиком, если сайт активно редактируется в блоковом редакторе. Лучше ограничить только публичные запросы или отдельные маршруты.

Забыли про внешние интеграции

Иногда сайт подключён к CRM, мобильному приложению или кастомному фронтенду. После блокировки API такие интеграции перестают работать, а ошибка проявляется не сразу.

Решение: перед изменениями проверьте, какие URL вызываются извне, и составьте список маршрутов, которые нельзя закрывать.

Сделали блокировку на уровне сервера без исключений

Если закрыть /wp-json/ через nginx или .htaccess, WordPress уже не сможет отдать корректный ответ, а диагностика станет сложнее. Такой способ допустим только если вы точно понимаете последствия и не используете REST API вообще.

Для большинства сайтов безопаснее сначала ограничить доступ на уровне WordPress, а не веб-сервера.

Практические советы по безопасности и производительности

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

• уберите неиспользуемые плагины, которые регистрируют собственные маршруты;
• проверьте, не отдают ли публичные маршруты лишние данные, например списки пользователей;
• ограничьте доступ к /wp-json/wp/v2/users, если он не нужен;
• следите за логами 401/403 после внедрения, чтобы быстро увидеть конфликт;
• если сайт большой, тестируйте изменения на staging, а не на бою.

Если вам нужен именно набор для чистки и технической оптимизации WordPress, иногда удобнее закрыть часть проблем через специализированный плагин вроде Clearfy Pro, но и там важно не включать всё подряд без проверки совместимости: сначала диагностика, потом точечная настройка.

В итоге рабочая схема выглядит так: сначала выясняете, кто реально использует REST API, затем ограничиваете доступ для гостей или только для чувствительных маршрутов, после этого проверяете редактор, фронтенд и интеграции. Такой порядок снижает риск поломки и даёт понятный контроль над тем, что именно осталось открытым.