Webhook Trust Fall
What it is
Webhook paths appear present without visible signature verification or idempotency proof.
This usually appears when generated checkout code focuses on the happy path and leaves fulfillment, signature verification, or entitlement state as a thin demo layer.
How to fix it
Verify provider signatures, reject unsigned events, add idempotency keys, and test replay attempts.
- 1Verify provider signatures before parsing or trusting events.
- 2Reject unsigned or malformed webhook requests.
- 3Add idempotency keys and replay-attempt tests.
How VibeAudit checks for this
VibeAudit checks this with SAST_LOCAL_STRUCTURAL route/control evidence for checkout, webhook signature handling, idempotency, and entitlement persistence; authorized DAST_Q1_ACTIVE probes can corroborate route behavior but not provider account state. The free tier may show the surface name only, without private evidence or remediation details. Metadata-only surface maps do not create missing-control findings. Unsupported private repositories, authenticated behavior, destructive workflows, account configuration, and business logic remain unverified unless the scan includes matching local, imported, or authorized runtime evidence.
Related failure modes
Check your public launch surface and keep unsupported scope visible.
Run Quick Scan