Payment webhook signature verified

Verifies

Every endpoint that receives a webhook of an external provider (payment gateways first: Stripe, PayPal, Braintree, Adyen, Square, Mollie, Razorpay, Paddle, Checkout.com, Redsys, Mercado Pago, NOWPayments, Coinbase Commerce; also GitHub, GitLab, Slack, Twilio, Shopify and the usual senders) verifies the provider signature before acting on the event. An internal service-to-service callback is not a webhook of a third party. No AI engine is involved: the verdict is reproducible from the source alone.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP), analysed statically: tokens (strings, template literals, regex literals and comments told apart), function units, calls, imports and route registrations of Next, Express, Fastify, Koa, Hono, Nest, Lambda, Django, Flask, FastAPI and Laravel. A handler is a FUNCTION that receives an HTTP request (a route handler, a decorated view, a controller action, a Lambda handler, or an exported function reading the request object) and that reads a provider signature header, calls a provider verification API, serves a /webhook(s)/<provider> route, or serves a webhook route while its file uses a provider SDK. Files that mention webhooks without receiving a request are ignored; a webhook route authenticated as an internal callback (service token, bearer token, own secret, session gate) without a provider header, route or API is listed and left out. The verification is searched in the handler's body, then in the functions it calls (same file), its route middleware and decorators, and the functions it imports from other files of the checkout (resolved by the imported name, up to 3 module hops). Paths listed in excludes (test, spec and tmp files, __tests__, __mocks__, fixtures, test, tests and audit-scripts folders) are never analysed. Nothing of the checkout is executed.

Decision rule

Not applicable when no function receives a webhook of an external provider (the reason lists the internal callbacks and the routes of unknown senders that were left out). For each handler the check requires ONE of: a provider verification API (constructEvent, Webhook.construct_event, WebhookSignature::verifyHeader, HmacValidator, webhookNotification.parse, verify_webhook_signature and equivalents), an HMAC computed over the body (createHmac, hmac.new, hash_hmac…), a constant-time comparison of a signature (timingSafeEqual, compare_digest, hash_equals, safeEqual…), a signature or token header compared against the configured secret, or a call named like a signature verification into an external library (svix, @octokit/webhooks, a provider SDK) — in the handler itself or in a function reached through its call graph within 3 module hops. FAIL (HIGH, with the handler's line) when a handler has none. FAIL (HIGH) when the signing secret is a literal in the handler or in the function that verifies. An HMAC or a header compared with a non-constant-time operator (===, ==, !=) is MEDIUM (blocks in Extended suites). A call named like a verification that cannot be resolved into the checkout is LOW, informative, and never counts as the verification. PASS when every handler verifies; the summary names each handler and where it verifies (file, line, kind, chain). Not judged by this check (declared): whether the verification can be skipped by configuration (a branch that trusts the body when the secret is missing), or whether the body was re-serialised before signing; those are the matter of a review. A fixture-looking secret value (sk_test_, example, dummy) in real code is LOW, informative.

Type

deterministic

1.1.1: a callee whose root is a name that `Object.prototype` also carries (`build().toString()` tokenizes to the bare callee `toString`; also `constructor`, `valueOf`, `hasOwnProperty`) was looked up in the plain object that holds the imported names, so it resolved to the INHERITED FUNCTION instead of to nothing and the whole check died with "name.includes is not a function". Only a real binding counts now, and the name of a unit is always read as a string. Found on a 1 319-file checkout (2fa-available and session-expiry-rotation, 2026-09-24); the same line was in the 15 scripts that walk the call graph, so all fifteen ship the fix. (1.1.0: deterministic: the rule runs over the static analysis kit (tokens, function units, calls, imports, routes) with no AI engine; exact decisionRule and languages published; not-applicable with the reason when the checkout gives nothing to evaluate. Handlers are function units (route handler, decorated view, controller action, Lambda handler); the verification (provider API, HMAC over the body with a constant-time comparison, signature or token header compared, external verification library) is searched in the handler, its middleware and decorators, and the functions it calls within 3 module hops (resolved by the imported name); none on any path is FAIL with the handler line; a loose comparison is MEDIUM; a hard-coded secret is HIGH. (1.0.2: evaluates only endpoints that RECEIVE a webhook of an external provider (provider SDK verification such as constructEvent, a provider signature header such as stripe-signature or x-hub-signature, or a /webhook(s)/<provider> route); an internal service-to-service callback authenticated with a service token, a bearer token or the application's own HMAC is not a third-party webhook (not-applicable with the callbacks listed, or PASS when real handlers exist); files that only mention webhooks and a provider without receiving a request are not reported; verification delegated to an imported module of the checkout counts and the module is reviewed together with the handler (assess mode); never analyses temporary files (*.tmp.*; spec.excludes follows AUDITOR_ANALYSIS_EXCLUDES). (1.0.1: never analyses test, spec, fixture and mock paths nor the auditor's own scripts (spec.excludes = AUDITOR_ANALYSIS_EXCLUDES); a fixture-looking secret (sk_test_, example, dummy) in real code is LOW, informative; every model call stays under the engine prompt cap (spec.promptMaxChars = AUDITOR_AI_PROMPT_MAX_CHARS): assess mode sends the candidate set in parts and aggregates the verdicts (a HIGH in any part is a FAIL, an unsatisfied part is a FAIL).)))

The full script is disclosed on request in a read-only viewer (never published on GitHub); the attestation binds to this exact hash.