HMAC-подпись входящего хука: без неё ваш endpoint — открытая дверь

HMAC-подпись входящего хука: без неё ваш endpoint — открытая дверь

Смотрим в тело запроса: HMAC валидируется по raw body, а не по распарсенному JSON. Любой лишний пробел, другой порядок полей или перекодировка — и подпись уедет. Поэтому сначала сохраняем байты как есть, потом считаем digest и только потом парсим payload.

Минимальный чек-лист:
• секрет хранится вне кода и ротируется вручную или через vault
• сравнение делается через constant-time compare, без обычного ==
• отдельно проверяются timestamp и окно допустимой задержки, иначе прилетит replay
• при ошибке — 401/403, без подробностей в ответе, чтобы не кормить атакующего

Типовая ошибка — валидировать уже после бизнес-логики. Это значит, что вы успеете создать запись, дернуть очередь или отправить письмо из мусорного запроса. Правильный порядок такой: verify signature → dedup by event_id → enqueue → ack. Идемпотентность — это не роскошь, а база, потому что один и тот же хук вам почти наверняка доставят повторно.

Если провайдер шлет подпись в заголовке, нормализуйте схему явно: один заголовок = один алгоритм = одна версия формата. И да, логируйте только метаданные: request_id, kid, результат проверки. Сам HMAC и сырой секрет в логах — это не аудит, это утечка с удобным интерфейсом.

Проверяйте подпись до любого сайд-эффекта, иначе потом будете ловить 5xx на ровном месте и искать фантомов в очереди.