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