Как ограничить REST API для внешних запросов в WordPress без поломки админки и плагинов

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

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

Сначала стоит понять, что именно вы хотите исправить. Если в логах много запросов к /wp-json/, это еще не всегда атака. Иногда это сканеры, иногда — сторонние сервисы, иногда — сам сайт дергает API через тему или плагин. Ошибка начинается тогда, когда REST API закрывают целиком и потом ломают редактор блоков, поиск, автосохранение или внешнюю интеграцию.

Признаки, что API стоит ограничить

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

Диагностика: что именно использует REST API на сайте

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

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

grep -R "wp-json" /var/log/nginx/access.log | tail -n 50

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

Рабочие варианты: плагин, код или серверное правило

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

Пошаговое решение через код

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

<?php
add_filter( 'rest_authentication_errors', function ( $result ) {
    if ( ! empty( $result ) ) {
        return $result;
    }

    if ( is_user_logged_in() ) {
        return $result;
    }

    // Разрешаем только публичные маршруты, если они вам нужны.
    // При необходимости список можно расширить.
    $request_uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';

    if ( strpos( $request_uri, '/wp-json/wp/v2/posts' ) !== false ) {
        return $result;
    }

    return new WP_Error(
        'rest_forbidden',
        'REST API доступен только авторизованным пользователям.',
        array( 'status' => 401 )
    );
} );

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

Если нужно скрыть только данные пользователей

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

<?php
add_filter( 'rest_endpoints', function ( $endpoints ) {
    if ( isset( $endpoints['/wp/v2/users'] ) ) {
        unset( $endpoints['/wp/v2/users'] );
    }

    if ( isset( $endpoints['/wp/v2/users/(?P<id>[\\d]+)'] ) ) {
        unset( $endpoints['/wp/v2/users/(?P<id>[\\d]+)'] );
    }

    return $endpoints;
} );

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

Что делать, если нужен серверный барьер

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

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

Проверка результата после внедрения

После изменений не ограничивайтесь открытием главной страницы. Проверьте несколько сценариев отдельно: обычный посетитель, авторизованный редактор и интеграция, если она есть.

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

Если API ограничен правильно, вы увидите либо понятный отказ для неавторизованных запросов, либо только те маршруты, которые вы сознательно оставили открытыми. Ошибки 403 и 401 должны появляться только там, где это ожидаемо.

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

Отключили REST API целиком

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

Не проверили сторонние плагины

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

Слишком жесткое правило на сервере

Если блокировка сделана на уровне Nginx или Apache без теста, можно случайно отрезать полезные маршруты. В этом случае откатите правило и перенесите ограничение в WordPress-код, где проще контролировать исключения.

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

Главная может открываться нормально, а редактор уже будет с ошибками. Проверяйте именно те сценарии, которые завязаны на API: админка, автосохранение, AJAX-формы, поиск, фильтры, блоки с динамическим контентом.

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

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

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

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

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