AVGZ / INSIGHTS
Інтеграції: ролі, повтори та журнал
Що перевіряти між двома програмними системами.
Постановка задачі
Доступ до API слід обмежити необхідними операціями. Те, що користувач не бачить кнопку в інтерфейсі, не замінює серверної перевірки прав.
Порядок перевірки
Для кожної операції задайте ідентифікатор, результат і спосіб повторного виконання. Повтор запиту після втрати відповіді не повинен вдруге списати кошти або створити дубль документа.
Межі та типові помилки
Журнал має допомагати відтворити подію, але не містити паролів чи ключів доступу. Перевіряйте відмови й помилки інтеграції так само, як успішний сценарій.
Приклад перевірки
Система відправила команду, але відповідь загубилася. Повтор запиту має повернути стан тієї самої операції або безпечно продовжити її, а не створити нове списання. Поведінка повтору є частиною контракту інтеграції.
| Контроль | Питання до системи |
|---|---|
| Доступ | Хто має право виконувати цю операцію над цим об’єктом? |
| Повтор | Чи має запит стабільний ідентифікатор? |
| Стан | Як відрізнити відмову від невідомого результату? |
| Аудит | Чи можна відтворити подію без розкриття секретів? |
Тестовий набір включає відсутні права, повтор, затримку, втрату відповіді та часткову помилку залежності. Для кожного випадку визначають очікуваний стан даних. Повідомлення про технічну помилку не повинно розкривати паролі, внутрішні запити чи стек застосунку.
Чи достатньо випадкового ключа API?
Ні. Потрібні межі повноважень, захист самого ключа, його відкликання та перевірка прав на кожному запиті.
Джерела та подальше читання
OWASP Top Ten — технічна довідка. Описаний порядок перевірки є редакційним інженерним підходом, а не звітом про впроваджений проєкт.