Что такое безопасный (safe) HTTP-запрос?

Question

Что такое безопасный (safe) HTTP-запрос?

Тип вопроса: Тестирование безопасности Вероятность: 23% Категория: AQA / Automation

Ответ

Безопасный (safe) HTTP-метод — это метод, который определен стандартом RFC 7231 как не изменяющий состояние сервера. Такие запросы предназначены только для получения данных и должны быть идемпотентными и не иметь побочных эффектов (side-effects) на сервере.

К безопасным методам относятся:

GET: Запрос для получения представления ресурса. Повторные идентичные GET-запросы должны возвращать один и тот же результат.
HEAD: Аналогичен GET, но сервер возвращает только заголовки ответа без тела. Используется для проверки наличия ресурса или его метаданных.
OPTIONS: Используется для описания параметров соединения с ресурсом (доступные методы).

Небезопасные методы (изменяющие состояние): POST, PUT, DELETE, PATCH.

Практическое значение:

Кеширование: Браузеры и прокси-серверы могут безопасно кешировать ответы на GET и HEAD запросы.
Веб-краулеры: Поисковые роботы индексируют страницы, используя только безопасные методы, не рискуя изменить данные на сайте.
Предсказуемость: Пользователь или клиентское приложение может безопасно повторять безопасные запросы без риска дублирования операций (например, повторное нажатие F5 на странице товара не должно создавать новый заказ).

Пример на Python с requests:

import requests

# Безопасный запрос (GET) - получение информации о пользователе.
# Можно выполнять многократно без последствий для данных.
safe_response = requests.get('https://api.example.com/users/123')
print(f"User data: {safe_response.json()}")
print(f"Status: {safe_response.status_code}")

# Небезопасный запрос (POST) - создание нового пользователя.
# Повторение этого запроса, скорее всего, создаст дублирующую запись.
unsafe_response = requests.post(
    'https://api.example.com/users',
    json={'name': 'Alice', 'email': 'alice@example.com'}
)
print(f"Creation status: {unsafe_response.status_code}")  # 201 Created

Важно: Безопасность метода — это договоренность между клиентом и сервером. Некорректно реализованный серверный API может иметь побочные эффекты и для GET-запросов (например, логирование с записью в БД), что является нарушением REST-архитектурных ограничений и плохой практикой.

Ответ 18+ 🔞

Давай разжую, как есть, про эти ваши безопасные методы, а то тут некоторые, блядь, думают, что POST — это как в туалет сходить, можно хоть десять раз подряд.

Смотри, есть такие методы, которые, по заветам мудрецов из RFC, не должны ебашить серверу по его состоянию. Они как вежливые гости: зашли, посмотрели, ничего не сломали и не передвинули, ушли. Это и есть безопасные (safe).

Кто эти скромники?

GET: Самый популярный чувак. Пришёл, спросил «как дела у ресурса?», получил ответ. Можно его вызывать хоть сто раз — должен показывать одно и то же. Идеальный кандидат для кеширования, ёпта.
HEAD: Его стеснительный брат-близнец. Делает то же самое, что GET, но не показывает тело. Только заголовки. Типа «Привет, ресурс на месте?» — «Да, на месте, рост 180, вес 70». А как выглядит — не покажу. Для проверки, жив ли вообще.
OPTIONS: Ну это такой разведчик. Приходит и спрашивает: «Эй, а что мне вообще с тобой можно делать? Какие методы принимаешь?». Сервер в ответ шлёт список доступных действий.

А кто тогда бузотёры, которые всё ломают? Да вот они, небезопасные: POST, PUT, DELETE, PATCH. Их вызов — это всегда риск что-то создать, поменять или нахуй удалить.

А нахуя это всё надо?

Кеширование, блядь. На GET и HEAD ответы можно спокойно складывать в кеш (в браузере, на прокси). Потому что они не меняются от частых запросов. Представь, если бы кешировали ответ на «оформи заказ» — был бы пиздец.
Поисковые роботы. Эти пауки ползают по сайтам только безопасными методами. А то представь, гуглобот зайдёт и нахуй удалит твой каталог товаров. Веселуха.
Предсказуемость для пользователя. Ты можешь жать F5 на странице товара до усрачки, и это не создаст тебе сто пятьдесят корзин в магазине. Потому что обновление страницы — это GET. А вот если бы это был POST на «купить» — всё, пиши пропало, закажешь весь склад.

Смотри, как это выглядит в коде (его не трогаем, он святой):

import requests

# Это безопасно. Получить данные юзера. Можно делать хоть в цикле.
safe_response = requests.get('https://api.example.com/users/123')
print(f"User data: {safe_response.json()}")
print(f"Status: {safe_response.status_code}")

# А это уже нет. Создать юзера. Два раза нажмёшь — получишь двух Алис, и потом разбирайся, какая из них настоящая.
unsafe_response = requests.post(
    'https://api.example.com/users',
    json={'name': 'Alice', 'email': 'alice@example.com'}
)
print(f"Creation status: {unsafe_response.status_code}")  # 201 Created

И главное, на чём сломается твой мозг: Это всё — договорённость, ебать её в сраку. Если программист-распиздяй на сервере в методе GET начнёт логировать каждый запрос в базу данных (а это side-effect), или, того хуже, сбрасывать счётчик просмотров — он нарушает контракт. Сервер-то будет работать, но архитектурно это говно, а не REST. Клиенты и кеши будут в шоке.

Так что безопасность метода — это не железное правило железа, а обещание сервера клиенту: «Чувак, вызывай этот метод — я тебе ничего не сломаю». А держит он это обещание или нет — уже вопрос совести и квалификации того, кто его писал.