AI Coding Agents
Security
Webhook verification for coding agent changes
September 27, 2026 - 2 minute read
Webhook verification is easy to weaken during an otherwise routine handler change. A coding agent may add an event type, move request parsing, or update middleware while preserving the happy path. The endpoint still accepts legitimate deliveries, but it may verify transformed bytes, compare signatures unsafely, or admit stale requests.
Provider contracts define the evidence. GitHub's webhook validation guidance requires computing an HMAC over the received payload and recommends constant-time comparison. Stripe's signature documentation requires the unmodified request body and includes a signed timestamp for replay resistance.
Review webhook verification at the byte boundary
Trace the request from the network adapter to the verification call. Signature verification must receive the exact bytes sent by the provider. JSON parsing, character conversion, whitespace normalization, and middleware that consumes the body can all change that input.
Keep parsing after authentication. Select the secret from trusted configuration rather than request data. Confirm that the implementation rejects an unsupported algorithm, malformed header, missing signature, and invalid encoding without falling through to event handling.
A coding agent should preserve the provider's canonical construction rather than invent a shared abstraction across incompatible schemes. GitHub signs the payload with a configured secret. Stripe signs a timestamp and payload according to its documented header format. Similar names do not make those protocols interchangeable.
Framework upgrades deserve a focused adapter test. Capture a synthetic byte sequence at the HTTP boundary, sign those bytes, and confirm the verifier receives them unchanged. This catches body-parser behavior that a direct unit test of the cryptographic verification function cannot observe.
Test webhook verification failures
Positive fixtures prove only that one valid sample works. Add negative cases that mutate the body after signing, change one signature byte, omit required fields, and use the wrong secret. For timestamped schemes, test both sides of the accepted tolerance and control the clock so the suite stays deterministic.
Replay behavior also depends on application state. A valid delivery may arrive more than once. Store the provider's stable delivery or event identifier when the operation has side effects, and prove that processing the duplicate does not repeat a payment, notification, or state transition.
Secret rotation needs an explicit overlap policy. Test the old and new secret during the allowed window, then prove the old value fails after retirement. Never put real endpoint secrets or captured customer payloads in fixtures.
Give reviewers security evidence
The pull request should identify the provider documentation, raw-body path, comparison function, timestamp policy, duplicate-handling rule, and tests run. Reviewers can then distinguish protocol-preserving refactoring from a change to the trust boundary.
Factory's security review workflow applies repository threat-model context and reports specific affected locations. Pair that review with executable fixtures because static inspection cannot prove how a framework passes raw request bytes at runtime. Factory's Automated QA can exercise the running API and preserve behavioral evidence for the pull request.
Stop the change when the provider contract, raw-body behavior, or production secret rotation policy is unknown. A passing valid-delivery test is not enough evidence for an internet-facing endpoint.
