2026-05-31 · Чтение 1 мин
HMAC-подпись для webhooks
Используйте shared secret и стабильный algorithm — проверяйте на сервере, не доверяйте только client-side checks.
Основные выводы
- HMAC требует secret key — относитесь к secondary input как к чувствительным данным и не логируйте.
- Предпочитайте SHA-256, если legacy partners не требуют SHA-1.
Основы
Обе стороны согласуют algorithm (например HMAC-SHA256) и encoding (обычно hex или Base64).
Подписывайте raw request body bytes — изменения whitespace ломают verification.
Безопасная отладка
Используйте test secrets в browser tools; rotate production secrets при случайной вставке.
Сравните HMAC output с docs провайдера на их sample payload.
Ротация секретов и проверка на сервере
Храните production-секрет только в переменных окружения или секрет-хранилище; в браузерных утилитах используйте отдельный тестовый ключ.
При смене секрета у провайдера webhook настройте окно, когда принимаются обе подписи (старый и новый алгоритм/ключ), иначе часть доставок отвалится.
Сравнивайте подпись по сырым байтам тела запроса: любые прокси, которые переписывают JSON или нормализуют переводы строк, ломают HMAC.
Часто задаваемые вопросы
HMAC — это password hash?
Нет. HMAC использует secret key с message; password hashing — salts и slow algorithms.
Можно verify HMAC в браузере?
Можно прототипировать, но production verification должна работать server-side с protected keys.
Нужно ли логировать заголовок подписи?
Логируйте только идентификатор события и результат проверки (pass/fail). Не пишите в лог секрет, полное тело с PII и значение подписи.