Захист REST API і webhook у WordPress: автентифікація, підписи та журнали

WordPress REST API є штатним інтерфейсом платформи: через нього працюють редактор, мобільні клієнти та зовнішні системи. Сам факт, що публічний контент доступний у JSON, не означає витік. Ризик з’являється, коли приватна дія має слабку авторизацію, endpoint приймає неперевірені дані або секрет інтеграції неможливо відкликати окремо.

Webhook — це подієвий HTTP-запит між системами. Наприклад, магазин повідомляє CRM про замовлення, а платіжний сервіс — про зміну статусу. Одержувач повинен довести, що запит надійшов від очікуваного джерела, не був змінений і не обробляється повторно небезпечним способом.

Почніть з інвентаризації маршрутів

Складіть список стандартних і кастомних namespace/route, HTTP-методів, власників коду та систем, які їх викликають. Для кожного endpoint зафіксуйте: які дані читає або змінює, кому він потрібен, як автентифікується, які права перевіряє, чи записує персональні дані та що відбувається при повторі.

Не закривайте весь REST API одним глобальним фільтром без аналізу: це може порушити редактор і легітимні інтеграції. Краще обмежувати конкретні операції відповідно до їхнього призначення.

Authentication не замінює authorization

Автентифікація відповідає на запитання «хто це?», а авторизація — «чи може ця особа виконати дію?». Кастомний REST endpoint має містити permission_callback. Офіційна документація WordPress про додавання endpoint рекомендує перевіряти capability через current_user_can(), а не лише факт входу.

Право повинно відповідати дії. Користувач, який може читати звіт, не обов’язково повинен змінювати замовлення. Адміністраторський токен для простого імпорту публічних даних створює надмірний ризик.

Cookie, nonce та зовнішній доступ

Для запитів усередині WordPress стандартна cookie-автентифікація доповнюється nonce, що захищає від CSRF. Документація REST API Authentication пояснює використання X-WP-Nonce для same-origin JavaScript. Nonce не є постійним API-ключем і не повинен використовуватися як єдина авторизація зовнішнього сервісу.

Для зовнішніх скриптів WordPress підтримує Application Passwords через HTTPS. Окремий пароль створюють для кожної інтеграції, називають зрозуміло й прив’язують до користувача з мінімальними правами. Його можна відкликати, не змінюючи основний пароль людини. Офіційний посібник з Application Passwords також описує last used та last IP для контролю використання.

Валідація і санітизація вхідних даних

Endpoint повинен описувати required, типи, допустимі значення, довжину й формат. WordPress дозволяє задавати validate_callback і sanitize_callback для аргументів. Валідація відхиляє некоректне значення, а санітизація приводить прийнятне значення до безпечної форми.

Не передавайте довільні імена полів напряму в SQL, назви файлів або системні команди. Навіть після валідації використовуйте підготовлені запити, API WordPress і контекстне екранування відповіді.

Підпис вхідного webhook

Надійна схема залежить від протоколу постачальника, але часто включає HMAC-підпис тіла запиту спільним секретом. Одержувач читає raw body, обчислює підпис тим самим алгоритмом і порівнює значення у constant-time. Секрет не передають у URL і не записують у відкритий журнал.

До підпису корисно включати timestamp та ідентифікатор події. Перевірка допустимого вікна часу й таблиця вже оброблених event ID зменшують ризик replay. IP allowlist може бути додатковим шаром, але не є повною заміною криптографічної перевірки: адреси можуть змінюватися або проходити через проксі.

Ідемпотентність і повтори

Постачальник може повторити webhook, якщо не отримав вчасну відповідь. Обробка тієї самої події не повинна двічі списувати кошти, створювати замовлення або надсилати клієнту дубль. Зберігайте стабільний event ID або власний idempotency key і повертайте узгоджений результат для вже виконаної події.

Важку роботу краще підтвердити швидко й передати в контрольовану чергу. Якщо endpoint чекає CRM, пошту та ще три API, постачальник може вирішити, що запит не прийнято, і повторити його.

Rate limit і контроль ресурсу

Ліміт запитів має враховувати endpoint, клієнта й ризик операції. Публічний пошук і створення замовлення потребують різних правил. Відповідь 429 повинна бути передбачуваною, а обмеження — не блокувати всіх користувачів через одну спільну адресу проксі.

Обмежуйте розмір body, кількість елементів у batch, дозволені MIME-типи та час зовнішніх викликів. Це захищає не лише від атаки, а й від помилки інтеграції, що нескінченно надсилає великі payload.

Секрети та ротація

• один секрет або Application Password на одну інтеграцію;
• мінімальні права окремого технічного користувача;
• HTTPS для всіх API-запитів;
• секрети поза репозиторієм і публічними налаштуваннями;
• планова ротація та негайне відкликання після підозри;
• короткий період паралельної підтримки старого й нового ключа, якщо протокол це дозволяє.

Журнали без витоку даних

Записуйте час, endpoint, event ID, статус автентифікації, результат, тривалість і correlation ID. Не зберігайте повні Authorization headers, application passwords, HMAC secrets, платіжні реквізити або надмірний payload. Доступ до журналів також потрібно обмежити, визначити строк зберігання й процедуру перегляду.

Чекліст тестування

1. Запит без автентифікації та з неправильним секретом відхиляється.
2. Правильний користувач без потрібної capability не виконує дію.
3. Невірний тип, завелике поле й невідоме значення повертають безпечну помилку.
4. Змінене тіло webhook не проходить перевірку підпису.
5. Стара timestamp і повторний event ID не створюють повторного ефекту.
6. Timeout зовнішньої системи не залишає дані у суперечливому стані.
7. У журналах немає секретів і персональних даних без необхідності.

Базовий контекст містить наш чекліст безпеки WordPress. Для перевірки інтеграцій, доступів і журналів перегляньте послугу безпеки сайту.

FAQ

Поширені запитання

Чи потрібно повністю вимикати REST API WordPress?

Зазвичай ні. REST API використовується ядром, редактором і легітимними інтеграціями. Обмежуйте конкретні приватні дії та перевіряйте права.

Чи є nonce API-ключем для зовнішньої інтеграції?

Ні. WordPress nonce використовується разом із cookie-автентифікацією для same-origin запитів і захисту від CSRF. Для зовнішнього доступу потрібен відповідний метод автентифікації.

Чи можна використовувати основний пароль адміністратора?

Не варто. Для API створіть окремий Application Password або інший підтримуваний credential для технічного користувача з мінімальними правами.

Навіщо webhook потрібен event ID?

Він дає змогу розпізнати повторну доставку й зробити обробку ідемпотентною, щоб одна подія не створила подвійний результат.

Чи достатньо дозволити IP постачальника?

IP allowlist може бути додатковим шаром, але не замінює підпис, перевірку часу, авторизацію й валідацію даних.