Spectra
Docs durchsuchen

webhooks

Replay-Schutz

Wie Spectra verhindert, dass ein erfasster Webhook gegen dein Konto wiederabgespielt wird.

Replay-Schutz auf einem signierten Webhook stoppt zwei Angriffe:

  1. Ein Angreifer, der eine gültige Request erfasst hat, kann sie nicht erneut senden, um dieselbe Order zu feuern.
  2. Ein fehlerhafter Sender kann nach Netzwerk-Aussetzern keine veralteten Nachrichten versehentlich erneut senden.

Der Mechanismus

Jede Request trägt X-Spectra-Timestamp. Der Worker erzwingt:

  • Frische-Fenster — Default 5 Minuten. Requests mit Timestamps älter als jetzt − 5 min werden mit 401 abgelehnt.
  • Nonce-Cache — der Worker cached (secret_id, timestamp, body_hash) für das Frische-Fenster. Eine zweite Request mit allen drei gleich wird mit 409 Conflict abgelehnt. Der Cache ist nur In-Memory (kein Postgres-Schreiben pro Request), also günstig.

Zusammen: eine erfasste Request ist höchstens 5 Minuten replayable, und nur, wenn der Angreifer ein Race gegen deine Original-Lieferung gewinnt.

Fenster tunen

Profil → Webhooks → Secret → Advanced → Freshness window.

1 Min   →  streng; empfohlen für Niedriglatenz-Netze
5 Min   →  Default
15 Min  →  locker; nur wenn dein Sender unvorhersehbares Lag hat

Unter 1 Minute zu gehen ist riskant — Uhren-Drift zwischen Sender und Worker kann legitime Requests an Frische-Checks scheitern lassen.

Was ist mit Idempotency?

Idempotency (client_id) und Replay-Schutz lösen unterschiedliche Probleme. Idempotency lässt denselben Sender sicher wiederholen. Replay-Schutz stoppt einen anderen Sender davon, eine erfasste Request wiederzuverwenden. Beides nutzen.

Symptome von Uhren-Drift

Wenn legitime Requests mit timestamp out of range abgelehnt werden, driftet die Uhr deines Senders. NTP prüfen. Der Fehler enthält die Now-Zeit des Workers, damit du das Delta berechnen kannst.