Можно ли изменять данные с помощью GET метода
Что проверяют
Понимаете ли вы семантику HTTP-методов и умеете ли превратить её в проверки. Для тестировщика следующий вопрос почти всегда такой: «Как вы проверите, что GET-эндпоинт ничего не меняет, и что будет, если меняет?»
Как отвечать
Технически можно: HTTP ничего не запрещает, сервер выполнит тот код, который в нём написан. По спецификации (актуальная RFC 9110, она заменила RFC 7231) GET относится к безопасным методам, то есть клиент не просит им менять состояние сервера. Побочные эффекты вроде записи в лог или счётчика просмотров допустимы, изменение бизнес-данных нет.
Дальше разведите два понятия, их часто путают:
- безопасность: метод не меняет состояние. Безопасны
GET,HEAD,OPTIONS; - идемпотентность: повтор запроса даёт тот же эффект, что и один вызов. Идемпотентны все безопасные методы, а также
PUTиDELETE.POSTиPATCHпо умолчанию нет.
Почему изменение через GET опасно на практике: такие ссылки открывают поисковые роботы, предзагрузка в браузере, превью ссылок в мессенджерах и почтовые антивирусы; ответ может закешироваться; прокси и клиенты повторяют GET при сбое сети. И главное: запрос через <img src="..."> на чужой странице уйдёт с куками пользователя, это готовая CSRF-атака.
Как это тестировать: вызвать GET и сверить состояние через другой запрос или прямо в базе; убедиться, что на неподходящий метод сервер отвечает 405 Method Not Allowed; поискать эндпоинты вида /delete?id= или /confirm?token= и открыть их из другой вкладки или без авторизации.
Где спотыкаются
Отвечают «нельзя» без оговорок. Точнее так: можно, но это нарушение стандарта и потенциальный баг, который тестировщик должен найти и завести.
Определяют идемпотентность как «не меняет данные». Это определение безопасности, а DELETE идемпотентен, хотя данные удаляет.
Сводят разницу между GET и POST к тому, где лежат параметры. Отсюда токены и персональные данные в URL, которые оседают в логах сервера, истории браузера и заголовке Referer.