Авторизація — найчастіша причина критичних витоків
Проблема рідко в “хакерах”, частіше — в неправильній моделі доступу: ролі не відповідають бізнесу, немає object‑level перевірок, частина ендпоїнтів “забута”.
1) RBAC: ролі як набори прав
- Роль = набір permissions, а не “if admin”.
- Permissions у форматі дія + ресурс (viewInvoice, editUser).
- Least privilege: даємо мінімум необхідного.
2) Object‑level access
- Перевіряй належність об’єкта (tenant/org/project) на бекенді.
- Не довіряй ID, що прийшов з фронту.
- Делегування доступу (share) — окремі правила і аудит.
3) Типові “діри”
- Ендпоїнт “для адмінки”, який випадково доступний користувачу.
- Фільтрація на фронті замість бекенду.
- Експорт/імпорт без перевірки прав на дані.
4) Як тестувати авторизацію
- Тести “матриця доступів” по ролях і ключових діях.
- Негативні кейси: спроба прочитати чужий ресурс.
Підсумок
Сильна модель доступу = RBAC + object‑level перевірки + least privilege + тести. Це зменшує ризик витоків і спрощує масштабування продукту.