Application Passwords в WordPress: как проверить и защитить доступ к API

Что такое Application Passwords и чем они отличаются от обычного пароля

Application Password — это отдельный ключ доступа, созданный в профиле пользователя WordPress для определённой интеграции. Например, его могут использовать CRM, мобильное приложение, сервис автоматической публикации, внешняя система резервного копирования или скрипт, обращающийся к REST API.

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

Ключ не предоставляет больше прав, чем есть у пользователя, которому он принадлежит. Application Password администратора может иметь последствия уровня администратора, а ключ редактора предоставляет только доступы, разрешённые ролью редактора и конкретными возможностями WordPress.

При создании WordPress показывает Application Password полностью только один раз. Его нельзя передавать в открытом виде через чаты, электронную почту, репозитории или конфигурационные файлы, доступные из веба.

• Основной пароль пользователя не нужно передавать внешней системе.
• Для каждой интеграции можно создать отдельный ключ с понятным названием.
• Отдельный ключ можно отозвать без смены основного пароля.
• Компрометация ключа означает компрометацию доступа соответствующего пользователя.

Какие риски создают старые или неизвестные ключи

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

Уровень риска зависит от роли пользователя. Неизвестный ключ администратора особенно опасен: через API он может позволять изменять контент, управлять пользователями и настройками или работать с установленными компонентами, если соответствующие действия доступны через конкретные endpoint-ы. Ключ редактора также нельзя считать безвредным: злоумышленник может изменять материалы, загружать медиафайлы и выполнять другие разрешённые действия.

Application Passwords не позволяют обходить права WordPress. Однако они могут незаметно обеспечивать длительный доступ, особенно если владелец сайта не отслеживает API-запросы и не проводит аудит учётных записей.

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

Как провести аудит Application Passwords

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

В профиле каждого пользователя проверьте список созданных Application Passwords. Обычно в нём отображаются название ключа и дата создания, но не сам секретный пароль. Если название не объясняет назначение доступа, обратитесь к ответственному за интеграцию или проверьте конфигурацию сервиса.

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

• Составьте список всех активных интеграций, обращающихся к WordPress.
• Свяжите каждую интеграцию с конкретным пользователем и Application Password.
• Уточните у владельцев сервисов, действительно ли ключ используется.
• Удалите ключи без подтверждённого назначения.
• После аудита проверьте журналы ошибок и работу автоматизаций.

Что делать, если ключ мог утечь

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

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

• Отзовите скомпрометированный ключ.
• Проверьте действия учётной записи в журналах.
• Проверьте новых пользователей и изменения контента или настроек.
• Замените ключ в сервисе, если интеграция должна остаться активной.

Как отозвать или заменить Application Password

Отзыв выполняется в профиле соответствующего пользователя WordPress. Найдите нужный ключ по названию и удалите его. После этого все запросы, аутентифицированные с помощью этого ключа, должны перестать выполняться.

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

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

Убедитесь, что интеграция передаёт Application Password через HTTPS и заголовок авторизации, а не добавляет секрет в URL. Не записывайте значение ключа в журналы запросов или сообщения об ошибках.

• Используйте отдельный ключ для каждой интеграции.
• Давайте ключам понятные названия, например «CRM продакшн» или «Мобильное приложение — тест».
• Храните секреты в менеджере секретов или защищённых переменных окружения.
• Не вставляйте ключи непосредственно в файлы темы или плагина и в публичный репозиторий.
• После смены ключа проверьте не только успешный запрос, но и ошибки автоматизации.

Как отключить Application Passwords, если доступ к API не нужен

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

Для постоянной настройки используйте mu-plugin, а не временный фрагмент в файле темы. Код в теме может исчезнуть после её обновления или смены, тогда как mu-plugin загружается независимо от активной темы. Создайте PHP-файл в каталоге обязательных плагинов WordPress и добавьте:

• Перед отключением проверьте CRM, мобильные приложения и автоматическую публикацию.
• Проверьте, не использует ли сторонний сервис XML-RPC или REST API.
• После изменения протестируйте формы, импорт, синхронизацию и фоновые задачи.
• Задокументируйте причину отключения, чтобы другой администратор не включил функцию без проверки.

<?php
/**
 * Disable Application Passwords for all users.
 */
add_filter( 'wp_is_application_passwords_supported', '__return_false' );

Когда не стоит отключать функцию без проверки

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

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

• Не добавляйте код в functions.php, если это должно быть постоянным правилом безопасности.
• Не используйте отключение Application Passwords вместо аудита пользователей.
• Не удаляйте все ключи без согласования, если сайт зависит от автоматизаций.

Типичные ошибки при работе с ключами

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

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

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

• Не передавайте ключ в URL или открытых параметрах запроса.
• Не храните секрет в JavaScript, который отправляется в браузер.
• Не используйте администратора там, где достаточно отдельного пользователя с ограниченными правами.
• Не оставляйте тестовые ключи на рабочем сайте.
• Не откладывайте аудит после смены подрядчика или состава команды.