wpnotes.ru wordpress WP Notes

Как отключить XML-RPC в WordPress выборочно и оставить доступ только для нужных приложений

|

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

Более безопасный сценарий — не выключать XML-RPC «в ноль», а ограничить его только теми методами, которые вам действительно нужны. Для большинства сайтов это означает: оставить доступ к нескольким методам, а всё остальное отклонять с понятной ошибкой.

Когда выборочное отключение XML-RPC действительно нужно

Сценарий обычно один из трёх:

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

Если XML-RPC вам не нужен вообще, проще и надёжнее закрыть его полностью на уровне сервера или через WordPress. Но если хотя бы один клиент зависит от него, лучше ограничить методы точечно.

Диагностика: что именно использует XML-RPC на сайте

Перед изменениями проверьте, есть ли реальные обращения к endpoint. Это можно сделать по логам веб-сервера, по WAF или по запросам в аналитике безопасности. Ищите обращения к /xmlrpc.php и посмотрите, какие методы вызываются чаще всего.

Что проверить в первую очередь

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

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

Как ограничить XML-RPC без полного отключения

Самый практичный вариант — добавить фильтр xmlrpc_methods и оставить только нужные методы. Ниже пример, который разрешает только базовую авторизацию и публикацию записей, а всё остальное убирает из списка доступных методов.

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    $allowed = array(
        'system.listMethods',
        'system.getCapabilities',
        'wp.getUsersBlogs',
        'wp.newPost',
        'wp.editPost',
        'wp.getPost',
        'wp.getPosts',
        'wp.deletePost',
        'wp.uploadFile',
        'metaWeblog.newPost',
        'metaWeblog.editPost',
        'metaWeblog.getPost',
        'metaWeblog.getRecentPosts',
        'metaWeblog.newMediaObject',
    );

    return array_intersect_key( $methods, array_flip( $allowed ) );
} );

Этот подход удобен тем, что вы не трогаете сам файл xmlrpc.php и не правите ядро. Код лучше размещать в мини-плагине или в functions.php дочерней темы, если у вас нет отдельного места для служебных доработок.

Если нужно закрыть XML-RPC для всех, кроме отдельных IP

Иногда интеграция работает только с фиксированного адреса. Тогда можно оставить endpoint доступным, но отклонять запросы не с доверенных IP. Это уже не про методы, а про транспортный уровень контроля.

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

    $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;
    }

    return false;
} );

У этого варианта есть ограничение: если сайт стоит за прокси или CDN, REMOTE_ADDR может показывать не реальный клиентский IP. В таком случае проверку нужно адаптировать под вашу инфраструктуру, иначе вы случайно заблокируете легитимные запросы.

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

ПодходКогда подходитПлюсыМинусы
Полное отключение XML-RPCИнтеграций нетМаксимально простоЛомает клиентов и сервисы, если они есть
Ограничение методов через xmlrpc_methodsНужны только отдельные функцииГибко, без правки ядраНужно знать, какие методы реально используются
Ограничение по IPЕсть фиксированный источник запросовХорошо для закрытых интеграцийСложнее при прокси, VPN и динамических IP

Пошаговая настройка на живом сайте

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

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

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

Проверка должна быть не только визуальной. Нужны как минимум три уровня контроля:

  • открывается ли /xmlrpc.php в браузере или через curl;
  • проходит ли нужный клиент публикации;
  • отклоняются ли лишние методы и не растёт ли число ошибок в логах.

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

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

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

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

Отключили XML-RPC, а потом перестал работать редактор на телефоне

Значит, приложение действительно использовало этот канал. Решение — вернуть доступ и перейти на выборочное ограничение методов или на IP-фильтрацию.

Фильтр добавили, но ничего не изменилось

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

Сайт за Cloudflare или reverse proxy, а IP-проверка не работает

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

Оставили слишком много методов

Если вы не уверены, не надо оставлять весь список «на всякий случай». Чем меньше методов доступно, тем меньше поверхность атаки. Начинайте с минимального набора и расширяйте его только по факту.

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

Выборочное отключение XML-RPC не заменяет базовую защиту. Если endpoint остаётся доступным, дополнительно проверьте:

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

Если вам нужен более широкий набор технических чисток и отключение лишних возможностей WordPress, иногда удобнее собрать это в одном инструменте, чем держать набор разрозненных сниппетов. Например, в Clearfy Pro есть функции для отключения части лишнего функционала и технической оптимизации сайта: https://wpshop.ru/plugins/clearfy.

Но даже если вы используете плагин, логику доступа к XML-RPC всё равно стоит понимать руками. Это тот случай, когда автоматизация помогает, но не отменяет диагностику.

×

Время действовать!

Суперцены на
WordPress!

-20%
на премиум темы

Не упусти шанс ⋙