Какие HTTP методы считаются безопасными

Что проверяют

Знаете ли вы определение из спецификации и отличаете ли безопасность метода от идемпотентности. Почти всегда следом звучит: «А какие методы идемпотентны?» и «Как это влияет на тестирование?».

Как отвечать

По RFC 9110 безопасны методы, которыми клиент не просит изменить состояние на сервере:

• GET: получение ресурса;
• HEAD: то же, что GET, но без тела ответа, только заголовки;
• OPTIONS: какие методы и параметры доступны для ресурса, на нём строится CORS preflight;
• TRACE: эхо запроса для диагностики. Формально безопасен, но на проде его обычно отключают из-за атаки Cross-Site Tracing.

Уточнение, которое отличает сильный ответ: «безопасный» значит, что клиент не запрашивает изменений, а не что сервер ничего не делает. Запись в лог, счётчик просмотров, кеш допустимы.

Затем идемпотентность: повтор запроса даёт тот же эффект на состояние сервера, что и один запрос. Все безопасные методы идемпотентны, к ним добавляются PUT и DELETE. POST не идемпотентен, PATCH по спецификации тоже этого не гарантирует.

Связь с тестированием:

• GET не должен ничего менять. Ссылка вида GET /orders/5/cancel это баг: её выполнит краулер, предзагрузка браузера или повторное открытие вкладки;
• защита от CSRF обычно пропускает безопасные методы без токена, поэтому изменяющий GET сразу превращается в уязвимость;
• повтор DELETE не должен ломать сервер: второй вызов вернёт 404 или 204, но не 500;
• ответы на GET и HEAD кешируются, проверьте Cache-Control на ответах с личными данными.

Где спотыкаются

Путают «безопасный» с «защищённым» и начинают говорить про HTTPS и шифрование.

Сливают безопасные и идемпотентные методы в один список и добавляют туда PUT или DELETE.

Уверенно говорят, что GET «никогда не меняет данные». Это требование к реализации, а не гарантия, и проверить его как раз задача тестировщика.