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
/**
 * Вимкнення Application Passwords для всіх користувачів.
 */
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, який віддається браузеру.
• Не використовуйте адміністратора там, де достатньо окремого користувача з обмеженими правами.
• Не залишайте тестові ключі на бойовому сайті.
• Не відкладайте аудит після зміни підрядника або складу команди.