Почему для авторизации выбирают определенный HTTP метод
Что проверяют
Разбираетесь ли вы в семантике методов и умеете ли проверить, что выбранный метод соблюдён на практике. Для тестировщика это вопрос не про теорию, а про то, какие проверки вы придумаете для формы входа.
Как отвечать
Вход меняет состояние: создаётся сессия или выдаётся токен, поэтому метод POST. GET исключается по трём причинам:
- логин и пароль ушли бы в строку адреса, а она попадает в историю браузера, закладки, логи прокси и в заголовок
Refererпри переходе на внешний ресурс; - GET кэшируется и предзагружается, ответ с токеном может осесть в общем кэше и достаться следующему пользователю;
- повтор GET считается безопасным, поэтому автоматический ретрай посредника способен обнулить чужую сессию.
PUT и PATCH не подходят по смыслу: они про обновление ресурса по известному адресу. Выход из сессии тоже делают POST или DELETE, иначе предзагрузка ссылки разлогинит пользователя.
Что из этого проверяет тестировщик:
- подменить метод на GET и убедиться, что приходит
405, а не успешный вход; - проверить, что пароля нет ни в адресе, ни в логах, ни в теле ответа;
- заголовки ответа:
Cache-Control: no-store, кука сHttpOnly,Secure,SameSite; - поведение при повторной отправке, при неверном пароле (одинаковый текст ошибки и сопоставимое время ответа) и при серии неудачных попыток.
Где спотыкаются
Отвечают, что POST шифрует данные. Шифрует TLS, причём весь запрос целиком вместе с адресом. Метод меняет только то, где параметры остаются в открытом виде у клиента и посредников.
Второе: проверяют исключительно сценарий через форму. Метод проверяется на уровне запроса: curl или перехватывающий прокси быстро покажут, принимает ли сервер тот же вход через GET, и нередко оказывается, что принимает.
Третье: считают вопрос закрытым после выбора метода. POST без ограничения числа попыток, без no-store и с токеном, который клиент кладёт в localStorage, не безопаснее GET, и тест-план обязан это ловить.