Broken Access Control
Обидва баги належать до A01: Broken Access Control — категорії №1 в OWASP Top 10. Суть: сервер довіряє клієнту там, де мав би перевіряти права.
IDOR (Insecure Direct Object Reference)
Застосунок бере ідентифікатор об'єкта прямо з запиту й віддає об'єкт без перевірки, чи має користувач до нього право.
GET /api/invoices/1043 → твій рахунок
GET /api/invoices/1044 → чужий рахунок (!)
Як шукати: будь-який id, user_id, uuid, filename у URL, параметрах,
тілі чи cookie. Ітеруй, підставляй чужі значення, порівнюй відповіді.
UUID не рятує, якщо його можна десь дізнатися (у витоку, в іншому ендпоінті).
Чому виникає: розробник перевірив автентифікацію (ти залогінений), але не авторизацію (чи це твій об'єкт).
Mass Assignment
Фреймворки часто автоматично маплять поля запиту на поля моделі/об'єкта. Якщо це роблять «наосліп», атакуючий надсилає зайві поля, які не мав контролювати:
POST /api/profile
{"display_name": "Bob", "role": "admin"} ← role не мав бути редагованим
Сервер копіює всі поля → ти став адміном. Це класична ескалація привілеїв.
Як шукати: додавай у запити поля на кшталт role, is_admin, isAdmin,
account_balance, verified, user_id — і дивись, чи вони застосувалися.
Захист
- IDOR: на кожному запиті перевіряй, що об'єкт належить поточному
користувачу (
WHERE id=? AND owner_id=current_user). Не покладайся на «непередбачуваність» ID. - Mass Assignment: використовуй allow-list полів (binding whitelist /
DTO / serializer з явними полями). Ніколи не роби
user.update(**request.json). - Тестуй авторизацію окремо від автентифікації — це різні речі.
Практика: BankApp: JWT + IDOR + Mass Assignment і капстоун Meridian (mass assignment → role=admin) у курсі.