Как запретить XML-RPC для части пользователей в WordPress без поломки админки

Полное отключение XML-RPC подходит не всегда. На живом сайте через него могут работать внешние сервисы, мобильное приложение WordPress или интеграции, которые вы не хотите ломать. Но если проблема в том, что доступ к xmlrpc.php используют лишние пользователи, боты или отдельные роли, лучше ограничить доступ точечно.

Ниже — рабочий сценарий: запретить XML-RPC для части пользователей, оставить его для нужных IP или ролей и проверить, что сайт не потерял полезные интеграции.

Когда это нужно и как понять, что проблема именно в XML-RPC

Сначала стоит убедиться, что вы действительно упираетесь в XML-RPC, а не в обычную авторизацию или REST API. Типичные признаки:

• в логах много запросов к /xmlrpc.php с ошибками авторизации;
• видны попытки system.multicall или pingback.ping;
• на сайте есть внешние сервисы, которые продолжают работать через XML-RPC, и их нельзя отключить полностью;
• нужно ограничить доступ только для редакторов, авторов, тестовых аккаунтов или конкретных IP.

Если у вас просто массовый brute force по xmlrpc.php, иногда проще закрыть endpoint целиком. Но если есть исключения, точечный запрет безопаснее.

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

• используется ли мобильное приложение WordPress;
• подключены ли внешние публикации или синхронизация через XML-RPC;
• есть ли у сайта кэш или WAF, который уже фильтрует запросы;
• какие роли должны иметь доступ, а какие — нет.

Как ограничить XML-RPC по ролям и IP

Самый предсказуемый вариант — фильтровать запросы на уровне xmlrpc_enabled. Этот фильтр позволяет отключить XML-RPC не глобально, а по условиям. Например, оставить доступ только администраторам с конкретного IP.

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

<?php
add_filter('xmlrpc_enabled', function ($enabled) {
    if (!$enabled) {
        return false;
    }

    // Разрешаем только с доверенного IP.
    $allowed_ips = array(
        '203.0.113.10',
        '203.0.113.11',
    );

    $remote_ip = $_SERVER['REMOTE_ADDR'] ?? '';
    if (in_array($remote_ip, $allowed_ips, true)) {
        return true;
    }

    // Дополнительно можно разрешить только администраторам,
    // если запрос идет из wp-admin или через авторизованную сессию.
    if (is_user_logged_in() && current_user_can('manage_options')) {
        return true;
    }

    return false;
});

Этот вариант не идеален для всех сценариев, но он понятный и проверяемый. Если нужно запретить XML-RPC только для конкретной роли, можно добавить проверку роли пользователя. Важно: XML-RPC вызывается до обычной страницы профиля, поэтому полагаться только на роль без авторизации часто бессмысленно. На практике надежнее сочетать роль и IP или вообще ограничивать endpoint на уровне сервера.

Более жесткий вариант: блокировать отдельные методы XML-RPC

Если вам нужен XML-RPC, но не нужны опасные методы вроде pingback, можно отфильтровать список доступных методов через xmlrpc_methods. Это полезно, когда нужно оставить публикацию постов, но убрать пингбеки и часть лишних вызовов.

<?php
add_filter('xmlrpc_methods', function ($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    unset($methods['system.multicall']);

    return $methods;
});

Здесь есть нюанс: отключение system.multicall может сломать некоторые клиенты, которые делают несколько запросов за один вызов. Поэтому сначала проверьте, нужен ли он вашим интеграциям.

Сравнение подходов: плагин, код, сервер

Если нужен быстрый и понятный контроль, начинайте с кода. Если у вас высокий трафик атак, добавляйте блокировку на уровне nginx, Apache или WAF.

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

1. Сделайте бэкап файлов и базы.
2. Проверьте, какие сервисы реально используют XML-RPC.
3. Добавьте код в mu-plugin или дочернюю тему.
4. Ограничьте доступ по IP или ролям.
5. Сохраните список исключений для администраторов и интеграций.
6. Проверьте логи после изменения.

Если вы используете mu-plugin, создайте файл wp-content/mu-plugins/restrict-xmlrpc.php. Пример минимального файла:

<?php
/**
 * Plugin Name: Restrict XML-RPC Access
 */

add_filter('xmlrpc_enabled', function ($enabled) {
    $allowed_ips = array('203.0.113.10');
    $remote_ip = $_SERVER['REMOTE_ADDR'] ?? '';

    if (in_array($remote_ip, $allowed_ips, true)) {
        return true;
    }

    if (is_user_logged_in() && current_user_can('manage_options')) {
        return true;
    }

    return false;
});

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

Проверка должна быть не только визуальной. Нужны два теста: с разрешенного адреса и с запрещенного.

• Откройте /xmlrpc.php в браузере или через curl с разрешенного IP — ответ не должен быть заблокирован вашим правилом.
• С запрещенного IP отправьте тестовый запрос и убедитесь, что WordPress возвращает отказ.
• Проверьте, работают ли нужные внешние интеграции.
• Посмотрите error log и access log: количество обращений к xmlrpc.php должно измениться предсказуемо.

Пример проверки через curl:

curl -i https://example.com/xmlrpc.php

Если вы блокируете endpoint на уровне сервера, ответ может быть 403 Forbidden. Если ограничение сделано в WordPress-коде, поведение зависит от логики фильтра и конкретного запроса.

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

Сломали мобильное приложение или внешнюю публикацию

Причина обычно одна: XML-RPC отключили полностью, хотя сервис использовал его для авторизации или публикации. Решение — вернуть доступ только для нужного IP или пересмотреть интеграцию.

Проверяют только роль, но не IP

Если запрос не проходит через авторизованную сессию, проверка роли не помогает. Для XML-RPC лучше использовать серверные ограничения или сочетание условий.

Отключили system.multicall без теста

Некоторые клиенты используют мультизапросы. Если после изменения перестала работать синхронизация, верните этот метод и блокируйте только pingback.ping или сам endpoint для лишних адресов.

Добавили код в тему, а потом потеряли его после обновления

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

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

Если атаки идут массово, одно только ограничение в WordPress не всегда достаточно. Хорошая схема выглядит так:

• на сервере или в WAF режете очевидный мусор;
• в WordPress оставляете точечные исключения;
• в логах отслеживаете повторяющиеся IP и методы;
• не храните список разрешенных адресов в нескольких местах без синхронизации.

Для сайтов с высокой нагрузкой лучше вынести фильтрацию на уровень nginx или Cloudflare, а в WordPress оставить только бизнес-логику исключений. Так вы не тратите PHP-процессы на заведомо нежелательные запросы.

Если вам нужен более широкий набор инструментов для чистки дублей, SEO-ограничений и технической оптимизации, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpmentor.ru&utm_medium=article&utm_campaign=kak-zapretit-xmlrpc-otdelnym-polzovatelyam-v-wordpress

Главная идея простая: не отключайте XML-RPC вслепую. Сначала выясните, кто и зачем его использует, потом ограничьте доступ точечно и только после этого ужесточайте правила на сервере.