HTTP-методы без мистики: что нужно сайту по умолчанию

HTTP-методы без мистики: что нужно сайту по умолчанию

Разбираем роль GET, HEAD и POST, а также когда действительно требуются PUT, PATCH, DELETE и OPTIONS.

image

HTTP-метод — это своего рода команда в первой строке запроса, которая объясняет серверу, что именно от него хотят. GET читает данные, POST создаёт новые, PUT заменяет целиком, DELETE удаляет. Вроде бы элементарно, правда?

Но как всегда, дьявол притаился в мелочах: один криво реализованный метод способен превратить безобидный GET-запрос в настоящую катастрофу или распахнуть ворота для CSRF-атак. А уж сколько разработчиков попадалось на том, что PUT и PATCH — это не одно и то же...

Грамотная работа с HTTP-методами — это фундамент предсказуемого API, эффективного кеширования и безопасности веб-сервиса. Сегодня разберём не только классические GET и POST, но и тонкости PATCH, особенности WebDAV, паттерны «мягкого» удаления и защиту от распространённых уязвимостей.

Где искать истину: стандарты и свойства методов

Семантика HTTP-методов описана в современном стандарте RFC 9110 (HTTP Semantics). Метод PATCH живёт отдельно в RFC 5789, а популярные форматы частичных обновлений можно найти в RFC 6902 (JSON Patch) и RFC 7386 (JSON Merge Patch). Для быстрого освежения знаний удобно заглядывать на MDN.

У каждого HTTP-метода есть три ключевые характеристики, которые определяют его поведение:

  • Безопасность — метод не должен изменять состояние сервера. Сюда относятся GET, HEAD, OPTIONS.
  • Идемпотентность — повторный запрос даёт тот же результат. Это GET, HEAD, PUT, DELETE, OPTIONS.
  • Кешируемость — ответ можно кешировать по правилам HTTP. Чаще всего это GET и HEAD.

Основные персонажи: краткий справочник

GET — чтение без последствий

Что делает: Получает представление ресурса. По определению безопасен и идемпотентен. Идеальный выбор для страниц сайта и чтения данных через API.

Особенности: Прекрасно кешируется при правильных заголовках (Cache-Control, ETag, Last-Modified). Главное правило — никогда не передавайте секретные данные в строке запроса, потому что они попадут в логи сервера и историю браузера.

HEAD — GET без лишнего веса

Что делает: То же самое, что GET, но возвращает только заголовки без тела ответа. Незаменим для проверки наличия ресурса, его размера, даты изменения или для мониторинга состояния сервиса.

Особенности: Экономит трафик и время — особенно полезно для проверок работоспособности или валидации кеша.

POST — универсальный солдат

Что делает: Создаёт ресурсы или выполняет операции с побочными эффектами: отправка формы, запуск обработки, авторизация пользователя.

Особенности: Не идемпотентен по своей природе. Требует защиты от CSRF, валидации входных данных и ограничений размера. POST — это как швейцарский нож среди HTTP-методов: может всё, но каждое применение нужно продумать.

PUT — полная замена

Что делает: Заменяет ресурс целиком по известному адресу. Идемпотентен: можете слать один и тот же PUT хоть сто раз — результат будет одинаковый.

Особенности: Подходит для случаев, когда клиент отправляет полную новую версию объекта. Требует строгого контроля прав доступа и валидации тела запроса.

PATCH — точечная хирургия

Что делает: Частично обновляет ресурс. Спасение для случаев, когда пересылать весь объект неэффективно или просто глупо.

Особенности: По умолчанию может быть неидемпотентным, хотя идемпотентная реализация тоже возможна. Критически важно чётко объявлять формат патча (об этом подробнее ниже).

DELETE — цифровой ластик

Что делает: Удаляет ресурс. Идемпотентен по результату: повторное удаление уже несуществующего ресурса не должно ломать систему.

Особенности: Обязательны аутентификация, авторизация и аудит всех операций удаления. В продакшене часто применяют «мягкое» удаление — помечают записи как удалённые вместо физического стирания.

OPTIONS — разведчик

Что делает: Выясняет, какие методы и заголовки поддерживает конкретный ресурс. Активно используется браузерами в предварительных запросах при CORS.

Особенности: Важно корректно возвращать заголовок Allow и заголовки Access-Control-Allow-*. Ошибки в настройке CORS — одна из самых частых причин проблем безопасности.

TRACE — диагностический инструмент

Что делает: Диагностика: сервер «отражает» запрос обратно. В реальном мире практически не используется и создаёт потенциальные уязвимости.

Рекомендация: Отключать на продакшн-серверах без сожалений.

CONNECT — туннельщик

Что делает: Создаёт туннель через прокси-сервер (например, для HTTPS-соединений).

Риски: На обычных веб-сайтах не нужен. Неправильная настройка может превратить ваш сервер в открытый прокси для всех желающих.

PATCH под микроскопом: война форматов

С PATCH всё не так просто, как кажется. Существует два основных подхода к частичному обновлению, и выбор между ними может серьёзно повлиять на архитектуру вашего API.

JSON Merge Patch — простота превыше всего

Описан в RFC 7386. Это простой «сливающий» формат: вы отправляете мини-JSON только с изменяемыми полями, а сервер накладывает эти значения поверх существующего ресурса. Чтобы удалить поле, передаёте null. Подходит для большинства повседневных задач и легко реализуется.

Пример Merge Patch:

PATCH /api/users/100
Content-Type: application/merge-patch+json

{ "email": "new@example.com", "middleName": null }

Здесь поле email изменится, а middleName логически удалится.

JSON Patch — мощь и гибкость

Описан в RFC 6902. Гораздо более мощный, но и сложнее в реализации: вы отправляете последовательность операций над документом с использованием JSON Pointer. Поддерживает точечные вставки в массивы, перемещения элементов, условные проверки.

Пример JSON Patch:

PATCH /api/users/100
Content-Type: application/json-patch+json

[
  { "op": "test", "path": "/version", "value": 7 },
  { "op": "replace", "path": "/email", "value": "new@example.com" },
  { "op": "remove", "path": "/middleName" },
  { "op": "add", "path": "/tags/-", "value": "trusted" }
]

Операция test помогает реализовать оптимистичную блокировку — обновлять только если версия объекта совпадает. Операция add с путём /- добавляет элемент в конец массива.

Когда что выбирать: Если нужны простые правки по полям — берите Merge Patch. Если важны точные операции над массивами, условные проверки или перенос значений — JSON Patch ваш выбор. В любом случае обязательно фиксируйте формат в Content-Type и документации.

WebDAV: когда друг становится врагом

WebDAV — это расширение HTTP для работы с файлами и «коллекциями» (каталогами), описанное в RFC 4918. Его методы (PROPFIND, MKCOL, COPY, MOVE, LOCK, UNLOCK, PROPPATCH, SEARCH) изначально проектировались как универсальный стандарт для удалённого редактирования и управления версиями.

Где реально живёт: Корпоративные файловые хранилища, системы совместной работы, редакционные процессы в CMS, подключение сетевых дисков в операционных системах, интеграции офисных приложений. Довольно распространён в частных облачных решениях.

Почему на публичном сайте это головная боль: Эти методы позволяют создавать, перемещать и блокировать файлы на сервере. При неправильной настройке это прямая дорога к загрузке вредоносного содержимого и установке веб-шеллов. Если по бизнес-логике WebDAV не требуется — отключайте модуль и блокируйте методы без сожалений.

«Мягкое» удаление: деликатный подход

Суть концепции: Вместо физического удаления записи из базы данных вы помечаете её как удалённую: например, is_deleted = true или deleted_at = NOW(). Данные остаются доступными для восстановления, аудита и анализа.

Преимущества: Простое восстановление по ошибке, прозрачный аудит всех операций, возможность сохранять связи и историю изменений.

Подводные камни: Нужно помнить о фильтрации «живых» записей во всех запросах к базе. Правила уникальности при «мягком» удалении требуют частичных индексов. Есть юридические аспекты: политика хранения данных, сроки окончательного удаления, соблюдение права на забвение.

Пример реализации:

-- Помечаем как удалённое вместо настоящего удаления
UPDATE users SET is_deleted = TRUE, deleted_at = NOW() WHERE id = 100;

-- Получаем только активные записи
SELECT * FROM users WHERE is_deleted = FALSE;

CSRF «на пальцах»: как вас могут обмануть

Что это такое простыми словами: Межсайтовая подделка запроса (CSRF) — это когда злоумышленник заставляет браузер жертвы отправить нежелательный запрос на доверенный сайт. Браузер честно прикладывает все куки с сессией, и сервер думает, что запрос легитимный.

Как это работает на практике: Пользователь авторизован в вашем сервисе и имеет активную сессию в куки. Он заходит на вредоносный сайт и случайно кликает по ссылке или форме, которая отправляет POST-запрос на ваш домен. Браузер автоматически подставляет куки — и вуаля, сервер видит «авторизованного» пользователя.

Методы защиты: Токены синхронизации (скрытые поля в формах и заголовки для проверки на сервере), политика SameSite для куки (минимум Lax), проверка заголовков Origin/Referer, подход «двойных куки». В одностраничных приложениях, где используется отдельный токен авторизации в заголовках вместо куки, риск CSRF снижается, но появляются другие угрозы типа XSS.

Детальные инструкции и практические чек-листы можно найти в памятке OWASP по защите от CSRF.

Какие методы действительно нужны

Всё зависит от специфики проекта, но разумный минимализм ещё никому не навредил.

  • Статический сайт, блог, новостной портал: GET и HEAD вполне достаточно.
  • Сайт с формами обратной связи: GET, HEAD, POST. Остальное добавляйте по мере необходимости.
  • Публичный API: GET, HEAD, POST, PUT, PATCH, DELETE плюс OPTIONS для поддержки CORS.

Золотое правило: включайте только то, что реально используется, а остальное явно блокируйте. Для удобства диагностики отвечайте кодом 405 Method Not Allowed с корректным заголовком Allow.

Методы повышенной опасности

Сами по себе они не злодеи, но в неумелых руках становятся источником головной боли.

  • TRACE: Может «подсветить» внутренние заголовки и куки; практически никогда не нужен. Отключайте без сомнений.
  • CONNECT: Необходим только для прокси-серверов; на обычном хостинге представляет угрозу. Блокируйте.
  • WebDAV-методы: Если не используете осознанно — модули лучше удалить, а методы запретить.
  • PUT/PATCH/DELETE без аутентификации: Прямая дорога к изменению ваших данных посторонними людьми.

CORS и OPTIONS: краткий ликбез по предварительным запросам

Когда веб-страница пытается обратиться к другому домену, браузер может сначала отправить разведочный OPTIONS-запрос, чтобы убедиться в разрешении операции. Ключевые моменты:

  • Access-Control-Allow-Origin — перечисляйте конкретные доверенные источники, не используйте * вместе с куки;
  • Access-Control-Allow-Methods — только реально поддерживаемые методы;
  • Access-Control-Allow-Headers — минимально необходимый список заголовков.

Подробную информацию о CORS можно найти на MDN и в материалах OWASP.

Практические примеры настройки

Nginx — лаконично и эффективно

server {
    listen 443 ssl;
    server_name example.com;

    # Базовый набор для обычного сайта
    location / {
        limit_except GET HEAD POST { deny all; }
    }

    # API с полным набором CRUD-операций
    location /api/ {
        limit_except GET HEAD POST PUT PATCH DELETE OPTIONS { deny all; }

        # Настройка CORS
        add_header Access-Control-Allow-Origin https://app.example.com always;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE, OPTIONS" always;
        add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;

        # Быстрый ответ на предварительный запрос
        if ($request_method = OPTIONS) { return 204; }
    }

    # Явно блокируем потенциально опасные методы
    if ($request_method = TRACE)   { return 405; }
    if ($request_method = CONNECT) { return 405; }
}

Apache — классический подход

<VirtualHost *:443>
    ServerName example.com

    <Directory "/var/www/html">
        Require all granted
        <LimitExcept GET POST HEAD>
            Require all denied
        </LimitExcept>
    </Directory>

    <Location "/api/">
        <LimitExcept GET POST HEAD PUT PATCH DELETE OPTIONS>
            Require all denied
        </LimitExcept>
    </Location>

    # Отключаем TRACE на уровне сервера
    TraceEnable Off
</VirtualHost>

# Если WebDAV не используется, отключаем модули:
# a2dismod dav dav_fs dav_lock

Мониторинг и логирование — ваши глаза и уши

Обязательно записывайте HTTP-метод, путь запроса, код ответа, размер тела запроса и ключевые заголовки. Настройте уведомления на всплески OPTIONS/TRACE-запросов, неожиданные PUT/DELETE на публичных путях и аномальное количество ошибок 405/501.

Для критически важных эндпоинтов внедрите ограничения частоты запросов (rate limiting) и защитите административные зоны дополнительными сетевыми правилами плюс усиленной аутентификацией.

Особое внимание уделите мониторингу запросов с нестандартными методами — они могут сигнализировать о попытках атак или неправильно настроенных клиентах. Регулярный анализ логов поможет выявить подозрительные паттерны активности задолго до того, как они перерастут в серьёзные проблемы.

Чек-лист для самопроверки

  1. Включите только необходимые методы; для остальных возвращайте 405 с корректным заголовком Allow.
  2. POST/PUT/PATCH/DELETE используйте только после аутентификации и проверки прав на конкретный ресурс.
  3. Реализуйте защиту от CSRF везде, где используются куки и сессии.
  4. Отключите TRACE/CONNECT, если вы не прокси-сервер и не диагностический узел.
  5. Для PATCH явно зафиксируйте формат: Merge Patch или JSON Patch.
  6. При использовании «мягкого» удаления не забывайте фильтровать активные записи и правильно настраивайте индексы.
  7. Настраивайте CORS точечно; избегайте использования * вместе с куки.
  8. Кешируйте ответы безопасных методов GET/HEAD с правильными директивами кеширования.

Финальные мысли

Для подавляющего большинства веб-сайтов вполне достаточно классической тройки GET/HEAD/POST. Публичным API потребуются дополнительно PUT/PATCH/DELETE и OPTIONS для поддержки кросс-доменных запросов. От TRACE, CONNECT и набора WebDAV-методов лучше отказаться сразу, если нет абсолютно чёткого понимания их необходимости.

Везде, где разрешены методы изменения данных, критически важны аутентификация, авторизация, защита от CSRF, осознанный выбор формата для PATCH и понятная политика удаления с объяснением, когда «мягкое» удаление предпочтительнее физического.

Чем строже вы следуете семантике HTTP-методов и принципу минимальной достаточности, тем стабильнее и безопаснее получается сервис. Помните: лучше потратить время на правильную настройку с самого начала, чем потом в авральном режиме ликвидировать последствия успешной атаки или архитектурного просчёта.

Ideco NGFW Novum: трансформируем подход к сетевой безопасности.

25 сентября в 11:00 приглашаем на прямой эфир, посвященный новому продукту Ideco.

Присоединяетесь

Реклама. 16+ ООО «Айдеко», ИНН 6670208848