Друзі, привіт! Як ваші вихідні - я вже вийшов з лікарняного то повертаюсь до роботи)

І зразу добрався до розбору цього пула - і це прямо улюблена класика для 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) - мислите правильно.
Хто ні - тепер знає, де копати наступного разу.

Всім гарного дня і безпечних логінів)

Обняв 🤗🤗🤗