Threat model
Practical security and privacy threats for ATM apps, ticketing flows, webhooks, QR passes, and buyer assertions.
Compatible with the closed-beta ATM app APIs and versioned ATM event headers. Check atm-api-version on every webhook or XRPC receiver event.
Threat categories
ATM’s main security job is keeping money truth, app authority, and public protocol records aligned without leaking private processor, customer, or fulfillment data.
| Threat | Risk | Retry | Cause | Control |
|---|---|---|---|---|
| Spoofed buyer | high | no | App lies about buyer DID or replays assertion. | Verify buyer assertion, expiry, audience, lxm, jti, and DID match. |
| Webhook replay | high | yes | Duplicate or redriven delivery triggers fulfillment twice. | Store delivery id before side effects. |
| Ticket oversell | critical | no | Concurrent buyers exceed scarce capacity. | Use private transactional holds; never rely on relay ordering or public record counts. |
| QR leakage | high | yes | QR contains sensitive or reusable ticket data. | Use opaque scan tokens, hashed secrets, revocation, and one-entry check-in. |
| Visibility creep | medium | no | App sees data for other apps or creator KYC. | Scope app dashboard/events to originated payments and modules. |
Buyer identity spoofing
A checkout can include a payer DID hint for UX, but sensitive flows should prefer a short-lived buyer assertion for the buyer DID. The assertion proves user presence without giving ATM a browser OAuth session or repo write grant.
Webhook replay
- Verify signature or service-auth before parsing trusted fields.
- Store delivery id before fulfillment.
- Return success for duplicate deliveries once prior side effects are confirmed.
- Use app order ids and payment ids as secondary idempotency anchors.
- Keep redrive safe for support and agent-operated integrations.
Ticket oversell
Public event and ticket records are display/catalog refs only. Holds and issuance must be enforced inside ATM Tickets private database transactions. Apps should display availability from the availability endpoint and treat it as a moment-in-time estimate until the hold succeeds.
QR token leakage
| QR payload | Opaque scan token or scan URL only. |
|---|---|
| Never include | DID, email, ticket id, payment id, processor id, attendee answers, or raw secrets. |
| Storage | Hash token secrets and keep wallet provider ids private. |
| Revocation | Void/refund should make verification fail or require review. |
App visibility creep
Apps can receive app-scoped payment facts for payments they originated, but should not receive creator KYC, bank details, connected-account ids, or payments from other apps. Refund authority for modules such as Tickets should be an audited ATM endpoint, not broad processor access.
Protocol privacy leaks
Public AT Protocol records should contain portable commerce facts and proof refs only. Keep buyer contact details, addresses, phone numbers, messages, attendee data, checkout session metadata, and processor ids private.