HMAC secrets, webhook integrity, and the governance gap for IAM

At a glance

What this is: This is a practical guide to HMAC secrets that explains how message authentication works and where implementations commonly fail.

Why it matters: It matters to IAM and NHI practitioners because HMAC secrets behave like sensitive non-human credentials and must be governed as such across code, runtime, and secret storage.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read GitGuardian's guide to HMAC secrets and webhook verification

Context

HMAC secrets are shared credentials used to prove that a message has not changed in transit and came from a trusted sender. In practice, they sit in the same governance bucket as other non-human identities because they often secure webhooks, service-to-service calls, and session mechanisms that are easy to deploy and easy to mishandle.

For IAM and NHI teams, the issue is not whether HMAC works. The issue is whether the organisation can protect the secret, verify the raw payload correctly, prevent replay, and rotate credentials without breaking production workflows. That makes this topic a control problem, not just a developer convenience problem.

Key questions

Q: How should security teams protect HMAC secrets in production systems?

A: Treat HMAC secrets like any other high-value NHI credential. Store them in a secrets manager, restrict access to the smallest viable set of services, rotate them on a defined schedule, and scan repositories and CI logs for accidental exposure. Detection alone is not enough if revocation is slow or ownership is unclear.

Q: Why do webhook signatures fail even when the secret is correct?

A: They often fail because the verification code signs the wrong bytes. Teams must verify the raw request body exactly as received, keep the algorithm consistent on both sides, and avoid reformatting JSON before checking the signature. Header parsing errors and encoding mismatches are common causes of false failures.

Q: What is the difference between HMAC and JWT for authentication?

A: HMAC is a cryptographic primitive that proves a message was signed with a shared secret, while JWT is a token format that may use HMAC or asymmetric signing under the hood. HMAC fits direct system-to-system trust, while JWT is a better fit for distributed token handling and session claims.

Q: When does HMAC create more risk than it reduces?

A: HMAC becomes risky when the shared secret is long-lived, reused across systems, or hardcoded into code or configuration. In that situation, one leak can compromise multiple workflows at once. The control improves security only when paired with narrow scope, rotation, replay protection, and continuous secret scanning.

Technical breakdown

How HMAC signing actually works

HMAC is a symmetric message authentication construction built from a shared secret and a hash function such as SHA-256. It is not the same as plain hash concatenation, which is vulnerable to length extension attacks. The sender computes a signature over the raw message and the receiver recomputes it with the same secret, then compares the outputs. The security property comes from the secret, the hash design, and the fact that both sides must possess the same key. In identity terms, the secret is an NHI credential with a very narrow trust boundary, so its lifecycle matters as much as the algorithm choice.

Practical implication: Treat every HMAC secret as a governed credential with ownership, scope, storage, and rotation requirements.

Why constant-time verification matters for webhook security

A naive string comparison can reveal how much of a signature is correct because it stops at the first mismatch. That creates a timing side channel that lets an attacker guess a signature byte by byte. Constant-time comparison avoids that leak by taking the same amount of time regardless of where the mismatch occurs. The same principle applies to any signature check that is exposed to an external caller. In webhook systems, verification errors often come from the comparison step rather than the cryptography itself, which is why secure libraries matter more than home-grown logic.

Practical implication: Use constant-time verification functions everywhere a signature is checked against an untrusted request.

Replay protection and context binding for shared-secret APIs

A valid HMAC signature can be reused unless the design binds it to time and request context. Timestamping reduces the replay window, while context binding ties the signature to the method, host, path, and body so it cannot be moved to a different endpoint. For sensitive systems, nonce-based one-time tokens add stronger replay resistance. This is especially important for internal APIs because a secret that proves authenticity on one route can become an authorisation bypass on another if the canonical string is too loose. The control question is not only who signed the request, but what exactly was signed.

Practical implication: Bind signatures to time and request context before allowing HMAC-based authentication in production.

Threat narrative

Attacker objective: The attacker wants to send malicious traffic that looks legitimate to downstream services and automate trusted actions without user interaction.

1. Entry via a leaked HMAC secret in source code, logs, or a poorly managed repository.
2. Escalation through forged webhook or API requests that pass signature checks because the attacker knows the shared key.
3. Impact through impersonated system events, tampered workflow data, or unauthorized internal actions accepted as trusted input.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

HMAC secrets are NHI credentials, not just implementation details. Teams often treat webhook keys and service tokens as disposable configuration values, but they behave like high-trust non-human identities with real blast radius. Once a shared secret leaks, the attacker does not need to defeat the protocol. They only need to reuse the trust relationship the organisation already created. The governance lesson is simple: classify HMAC keys as secrets with ownership, scope, and revocation requirements.

Raw-body verification is a control boundary, not a coding preference. Many webhook failures begin when teams hash parsed JSON instead of the original bytes, or when they compare signatures with ordinary string functions. That is an implementation flaw with security consequences, not a minor bug. Practitioners should treat canonicalisation, header handling, and comparison logic as part of the trust model, because signature validation is only as strong as the exact bytes being verified.

Ephemeral validity does not remove the need for lifecycle management. A timestamp narrows replay risk, but it does not solve exposure, scoping, or rotation. If the secret is long-lived, copied broadly, or shared across multiple integrations, the attack surface expands quickly. For NHI governance, the right standard is short-lived trust backed by controlled issuance, monitored use, and rapid revocation when compromise is suspected.

Replay resistance must be designed into the authentication pattern. HMAC by itself proves message integrity and origin, but it does not prove freshness or destination. That distinction matters because attackers frequently exploit valid credentials in the wrong context. Organisations that already use Zero Trust should align HMAC-based workflows with the same assumptions: least privilege, narrow scope, and verification of the full request context before trust is granted.

Hardcoded HMAC keys are part of the wider secrets sprawl problem. The same leakage patterns that affect API keys and tokens also affect webhook secrets, CI variables, and session-signing material. Once those credentials appear in repositories or collaboration tools, revocation is often delayed and visibility is incomplete. Practitioners should fold HMAC secrets into the same monitoring, scanning, and rotation regime as other NHI secrets.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• GitGuardian also found that 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• For a broader control view, compare that exposure pattern with Guide to the Secret Sprawl Challenge for the lifecycle steps that reduce standing trust.

What this signals

Ephemeral signature trust: organisations are moving toward shorter-lived credentials, but the control burden shifts rather than disappears. If HMAC secrets remain embedded in pipelines and callbacks, the programme still needs ownership, rotation, and revocation discipline, plus alignment with OWASP Non-Human Identity Top 10.

The governance signal is broader than webhooks. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the pattern is clear: any shared secret used by agents, tools, or automation must be managed as a lifecycle object, not a developer convenience.

Teams should expect HMAC-like signing patterns to appear in more agentic workflows, especially where tools exchange messages at machine speed. That makes NIST SP 800-207 Zero Trust Architecture a useful lens for binding requests to context before trust is granted.

For practitioners

• Inventory every HMAC secret and assign ownership Map webhook keys, API signing secrets, and session-signing material to a named service owner, then record where each secret is stored, used, and rotated. Include repository variables, CI systems, and secret managers in the same inventory.
• Enforce constant-time signature verification Use the standard library comparison functions provided by your language and verify the signature against the exact raw request bytes before any parsing or normalisation. Reject implementations that compare strings directly or re-serialise JSON before checking the signature.
• Add replay controls to every external callback Require a timestamp in the signed payload, reject stale requests outside a narrow window, and use nonces for high-risk actions where a replay would have material impact. Bind the signature to method, host, and path where the workflow supports it.
• Rotate shared secrets without downtime Support an overlap period where both the old and new HMAC keys are accepted, then cut over once all senders have updated. This reduces operational risk while still shrinking the time a leaked key remains useful.
• Scan for hardcoded signing material continuously Run secret detection in repositories, CI logs, and collaboration tools so HMAC keys are found before an attacker can reuse them. Pair detection with automated revocation so exposure does not become a standing trust problem.

Key takeaways

• HMAC is only as secure as the secret lifecycle behind it, which means governance matters as much as cryptography.
• The biggest implementation failures are usually around raw-body verification, constant-time comparison, and replay protection rather than the hash algorithm itself.
• For IAM and NHI teams, HMAC secrets should be inventoried, rotated, scoped, and scanned like any other high-trust credential.

Key terms

• Hmac Secret: A shared cryptographic key used to generate and verify a message authentication code. In practice, it is a sensitive non-human credential that must be stored, rotated, and revoked carefully because anyone who holds it can create valid signatures.
• Constant-Time Comparison: A verification method that takes the same amount of time regardless of how much of a signature matches. It reduces timing side channels that attackers can use to infer valid signatures one character at a time during online verification attempts.
• Replay Attack: An attack where a previously valid signed message is captured and sent again later to trigger the same trusted action. Timestamping, nonces, and context binding are the main controls that reduce replay risk in HMAC-based systems.
• Canonical Request String: The exact set of request fields that are included in a signature calculation, often including the method, host, path, timestamp, and body. A well-defined canonical string prevents attackers from reusing a valid signature on a different endpoint or action.

What's in the full article

GitGuardian's full guide covers the operational detail this post intentionally leaves for the source:

• Language-specific code examples for generating and verifying HMAC signatures in Python and Node.js
• Step-by-step webhook verification patterns, including raw-body capture and constant-time comparison
• Replay-prevention patterns using timestamps, nonces, and request-context binding
• Practical troubleshooting checks for encoding, header names, and signature mismatches

👉 GitGuardian's full post covers implementation examples, replay controls, and troubleshooting details.

Deepen your knowledge

HMAC secrets, webhook verification, and replay-resistant authentication are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls around shared-secret workflows or automation callbacks, it is worth exploring.