Welcome to Bug or Defect?
youtube - https://www.youtube.com/@BugOrDefect
instagram - https://www.instagram.com/bugordefect_life?igsh=MTFlYzZyMncwZWd4eQ==
Post #833
951
Bug or Defect? Завдання дня для QA: Ви тестуєте API /login. Він приймає email і password та ходить у базу. Після одного з запитів API повертає 200 OK, хоча пароль явно неправильний. Що КУА має перевірити?
Друзі, привіт! Як ваші вихідні - я вже вийшов з лікарняного то повертаюсь до роботи)
І зразу добрався до розбору цього пула - і це прямо улюблена класика для QA + security.
Отже, що маємо:
API /login повертає 200 OK з неправильним паролем.
І тут починається найцікавіше)
Чому не (A) “чи не закешувався запит”
Кеш для /login - це антипатерн, але теоретично може бути неправильний кеш на рівні проксі/CDN. Проте це менш імовірно, ніж логіка/ін’єкція, і точно не перша гіпотеза
Якщо API реально кешує /login, то це вже окремий серйозний баг, але це не перше, що перевіряємо.
Чому не (B) “логи бекенду”
Логи це реально важливо, але це другий крок.
Куа спочатку має зрозуміти тип проблеми, а вже потім іти в логи.
Без гіпотези логи, це просто чорна діра на пів години.
Чому не (D) “UI-валідація”
Ми тестуємо API.
UI тут взагалі ні при чому.
Навіть ідеальна UI-валідація не врятує, якщо бекенд приймає будь-що.
І чому правильна відповідь (C) - SQL-інʼєкція
Бо це критичний security-сигнал.
Класика жанру:
' OR '1'='1
Якщо пароль підставляється в SQL без параметризації, бекенд може: ігнорувати пароль або повертати першого юзера завжди логінити з 200 OK
І це вже не просто баг - це security vulnerability.
Що я хочу вам сказати) Якщо: пароль неправильний але API каже 200 OK, це не “дивна логіка”, це потенційна вразливість
І саме тут куа перестає бути “клікером”
і стає людиною, яка реально захищає продукт.
Хто обрав (C) - мислите правильно.
Хто ні - тепер знає, де копати наступного разу.
Всім гарного дня і безпечних логінів)
Обняв 🤗🤗🤗
І зразу добрався до розбору цього пула - і це прямо улюблена класика для QA + security.
Отже, що маємо:
API /login повертає 200 OK з неправильним паролем.
І тут починається найцікавіше)
Чому не (A) “чи не закешувався запит”
Кеш для /login - це антипатерн, але теоретично може бути неправильний кеш на рівні проксі/CDN. Проте це менш імовірно, ніж логіка/ін’єкція, і точно не перша гіпотеза
Якщо API реально кешує /login, то це вже окремий серйозний баг, але це не перше, що перевіряємо.
Чому не (B) “логи бекенду”
Логи це реально важливо, але це другий крок.
Куа спочатку має зрозуміти тип проблеми, а вже потім іти в логи.
Без гіпотези логи, це просто чорна діра на пів години.
Чому не (D) “UI-валідація”
Ми тестуємо API.
UI тут взагалі ні при чому.
Навіть ідеальна UI-валідація не врятує, якщо бекенд приймає будь-що.
І чому правильна відповідь (C) - SQL-інʼєкція
Бо це критичний security-сигнал.
Класика жанру:
' OR '1'='1
Якщо пароль підставляється в SQL без параметризації, бекенд може: ігнорувати пароль або повертати першого юзера завжди логінити з 200 OK
І це вже не просто баг - це security vulnerability.
Що я хочу вам сказати) Якщо: пароль неправильний але API каже 200 OK, це не “дивна логіка”, це потенційна вразливість
І саме тут куа перестає бути “клікером”
і стає людиною, яка реально захищає продукт.
Хто обрав (C) - мислите правильно.
Хто ні - тепер знає, де копати наступного разу.
Всім гарного дня і безпечних логінів)
Обняв 🤗🤗🤗
- 🔥 25
- ✍ 8
- ❤ 5
- 👍 2
- 💯 2
- 🤓 1






