<b>HMAC-подпись на входящем хуке: без неё вы принимаете любой мусор как «событие»</b>

<b>HMAC-подпись на входящем хуке: без неё вы принимаете любой мусор как «событие»</b>

Подпись проверяем до разбора полезной нагрузки. Иначе вы сначала парсите JSON, а потом удивляетесь, почему в хендлер прилетел мусор, кривой UTF-8 или поддельный запрос. Смотрим в тело запроса как есть: байты, порядок полей и оригинальный raw body — именно их надо использовать для расчёта HMAC.

Базовый пайплайн простой:
— забираем secret из защищённого хранилища, не из конфига в репозитории;
— считаем HMAC от raw body тем же алгоритмом, который ожидает отправитель;
— сравниваем подпись через constant-time compare, а не через обычный `==`;
— при несовпадении отвечаем 401/403 и не ставим событие в очередь.

Типовая ошибка — нормализовать JSON перед проверкой. Пересортировали поля, убрали пробелы, перекодировали строку — получили другой байтовый поток, подпись «сломалась», а виноват не отправитель, а ваш хендлер. Ещё хуже, когда принимают подпись из query string: это уже не защита, а декорация.

Идемпотентность — это не роскошь, а база. Даже валидная подпись не спасает от ретраев и дублей: храните `event_id`, timestamp или nonce, режьте повторы и ставьте TTL на дедупликацию. Если нужен ответ быстро — подтверждаем 2xx после валидации, а тяжёлую обработку уводим в очередь. Ретрай-политика решает всё.

Если подпись не сошлась — логируем причину, но не сам secret и не полный raw body. Дальше уже дело техники: IP-whitelist, ротация ключей, отдельный секрет на каждого провайдера. Без этого любой вебхук — просто открытый POST-эндпоинт.