Друзі, привіт! Як ваші вихідні - я вже вийшов з лікарняного то повертаюсь до роботи) І зразу добрався до розбору цього пула - і це прямо улюблена класика для 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) - мислите правильно. Хто ні - тепер знає, де копати наступного разу. Всім гарного дня і безпечних логінів)Обняв 🤗🤗🤗