Как закрыть xmlrpc.php в WordPress и не сломать нужные интеграции

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

Но отключать его «в лоб» через .htaccess без проверки — плохая идея. На живом сайте сначала нужно понять, используется ли XML-RPC вообще, а потом выбрать способ блокировки: на уровне сервера, через плагин безопасности или кодом в теме/му-плагине.

Когда xmlrpc.php действительно стоит закрыть

Отключение оправдано, если сайт работает как обычный корпоративный блог, медиа или контентный проект, а публикация идет только через админку WordPress. В таком сценарии XML-RPC чаще приносит риски, чем пользу.

Сначала проверьте, есть ли реальные зависимости

Перед изменениями ответьте на три вопроса:

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

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

Диагностика проблемы: как понять, открыт ли XML-RPC и чем это грозит

Проверка простая: откройте https://ваш-домен.ru/xmlrpc.php в браузере. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не ошибка, а признак того, что файл существует и доступен извне.

Для более практичной проверки можно отправить тестовый запрос с сервера или локальной машины:

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

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

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

Как закрыть xmlrpc.php: три рабочих подхода

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

1. Блокировка на уровне Nginx

Если сайт работает на Nginx, самый чистый вариант — вернуть 403 для xmlrpc.php до передачи запроса в WordPress:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Это решение хорошее тем, что запросы даже не доходят до PHP. Для сайтов с регулярными сканами это заметно экономит ресурсы.

2. Блокировка на уровне Apache

Для Apache можно использовать правило в .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

Если у вас старый стек с Apache 2.2, синтаксис будет другим, но на современных хостингах обычно используется именно Require all denied. После правки проверьте, что файл не открывается напрямую.

3. Отключение через код WordPress

Если нет доступа к конфигу сервера, можно заблокировать XML-RPC через код. Самый безопасный вариант — вынести его в mu-plugin, чтобы он не зависел от темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Такой код отключает XML-RPC на уровне WordPress. Это удобно, если вы не хотите трогать серверные настройки, но важно понимать: сам файл xmlrpc.php останется доступным, просто WordPress будет отвечать отказом.

Если XML-RPC нужен частично: как не сломать интеграции

Иногда полный запрет не подходит. Например, Jetpack еще используется, а редакторы публикуют материалы из внешнего сервиса. В этом случае лучше сначала выяснить, какие именно методы XML-RPC используются, и только потом ограничивать доступ.

Практически это означает одно из двух:

• оставить XML-RPC включенным, но закрыть его на уровне WAF или ограничить по IP;
• перевести интеграцию на REST API, если сервис это поддерживает.

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

Пошаговое решение для типового сайта

Если сайт не использует XML-RPC, действуйте так:

1. Проверьте, нет ли активных интеграций с Jetpack и внешними клиентами.
2. Выберите уровень блокировки: сервер, .htaccess или код.
3. Внесите изменение на тестовой копии сайта, если она есть.
4. Проверьте ответ /xmlrpc.php после правки.
5. Посмотрите логи веб-сервера и убедитесь, что легитимные запросы не ломаются.

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

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

После внедрения нужно проверить не только страницу в браузере, но и реальный HTTP-ответ. Для этого используйте curl:

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

Ожидаемый результат зависит от способа блокировки:

• при блокировке на сервере — 403 Forbidden;
• при отключении через WordPress — ответ может быть 200 или 405, но без доступа к XML-RPC методам;
• при работе через WAF — возможен ответ от защитного слоя, а не от WordPress.

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

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

Отключили XML-RPC, а Jetpack перестал синхронизироваться

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

Правило в .htaccess не сработало

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

Отключили через код в теме и потеряли контроль после обновления

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

Закрыли файл, но атаки в логах остались

Это нормально: сканеры продолжают стучаться по известным URL. Важен не сам факт запросов, а то, что сервер отвечает быстро и без нагрузки. Если запросов слишком много, добавьте ограничение на уровне WAF или fail2ban, если это поддерживает ваш хостинг.

Безопасность и производительность: что еще стоит учесть

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

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

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

Главная проверка здесь простая: если сайт не использует XML-RPC, файл должен быть недоступен извне или хотя бы не принимать полезные запросы. Если используется — ограничивайте доступ аккуратно и фиксируйте, кто и зачем его требует.