VoriTools

Webhook-Signaturen generieren und verifizieren

Fügen Sie den unveränderten Body und das Secret ein, um eine HMAC-Signatur zu erzeugen oder zu prüfen. GitHub- und Stripe-Vorlagen sind enthalten; Zeitstempelgültigkeit und Replay-Schutz werden nicht geprüft.

Läuft lokal in deinem Browser
Kategorie ansehen: Sicherheit & Kryptografie (30)
Signature inputs
Eingefügte Zeilenumbrüche werden in diesem Feld zu LF. Aktivieren Sie dies, um einen mit CRLF-Bytes signierten Body nachzubilden.
Generated signature
Enter a secret and payload to generate a signature.
Verify a received signature
Erzeugen Sie eine Signatur oder fügen Sie eine empfangene Signatur zur lokalen Prüfung ein.
Header-Vorschau
Generate a signature to see the corresponding request header.
Server-side verification patterns
Generate a signature to see Node.js and PHP verification patterns.

Exakt die empfangenen Bytes signieren

Webhook-Prüfungen schlagen fehl, wenn Middleware den Body vor der Verifikation analysiert oder neu formatiert. Bewahren Sie den Roh-Body auf, verwenden Sie die dokumentierte Signaturgrundlage des Anbieters und vergleichen Sie im Servercode in konstanter Zeit. Diese Seite sendet weder Payload noch Geheimnis.

So erzeugen oder prüfen Sie eine Webhook-Signatur

Signiert den exakt eingefügten Body mit HMAC-SHA-256, SHA-384 oder SHA-512, bildet GitHubs X-Hub-Signature-256 und Stripes v1-Header nach und vergleicht eine empfangene Signatur Byte für Byte mit demselben Secret.

Die Berechnung läuft in diesem Tab über Web Crypto. Body, Secret und Signaturen bleiben im Browser; eine Übereinstimmung bestätigt die Bytes, nicht das Alter des Ereignisses.

  1. Wählen Sie das Format: generisches HMAC, GitHub X-Hub-Signature-256 oder Stripe v1. Die Provider-Formate nutzen immer SHA-256.
  2. Fügen Sie den exakten rohen Body und das Secret ein. Bei Stripe den gesendeten Zeitstempel eintragen oder Aktuelle Zeit verwenden klicken; Mit CRLF-Zeilenenden signieren aktivieren, wenn der Absender CRLF-Bytes signiert hat.
  3. Erzeugen Sie die Signatur, um die passende Header-Zeile und Node.js-/PHP-Beispiele zu sehen. Jede spätere Eingabeänderung dimmt den Wert, bis Sie neu erzeugen.
  4. Zum Prüfen eines empfangenen Werts diesen in das Prüffeld einfügen und Prüfen klicken. Hex funktioniert überall, Base64 bei generischen Webhooks, und ein vollständiger Stripe-Signature-Header wird samt t= gelesen.
  5. Signatur kopieren übernimmt den Header-Wert, Löschen leert alle Felder und stellt generisches HMAC wieder her.

Was das erzeugte Ergebnis enthält

Signierte Eingabe je Format

Generisches HMAC signiert den rohen Body. GitHub signiert denselben Body und sendet sha256=<hex> in X-Hub-Signature-256. Stripe signiert <Zeitstempel>.<Body> und sendet t=<Zeitstempel>,v1=<hex> in Stripe-Signature.

Bei einem eingefügten Stripe-Header bildet dessen t die signierte Eingabe; das Zeitstempel-Feld zählt nur, wenn der Header kein t= enthält. Bei rotierten Secrets können mehrere v1-Werte vorkommen; die Prüfung besteht, wenn einer passt.

Warum ein identischer Body trotzdem scheitern kann

Das Textfeld wandelt eingefügte CR- und CRLF-Zeichen in LF um. Wurde mit CRLF-Bytes signiert, aktivieren Sie Mit CRLF-Zeilenenden signieren: jedes LF wird vor der Berechnung zu CRLF.

Jede Textabweichung zählt: neu serialisiertes JSON, entfernte Schlusszeile, geändertes Leerzeichen, dekodierter URL-Bestandteil oder der bereits geparste Body ergeben einen anderen Digest. Nur der Hex-Teil eines Provider-Headers lässt das erwartete Präfix sha256= oder v1= weg, beide Formen werden akzeptiert.

Was diese Seite nicht prüft

Die Prüfung vergleicht nur HMAC-Bytes. Sie lehnt weder alte Zeitstempel noch wiederholte Ereignisse ab, kennt kein Toleranzfenster des Anbieters und kontaktiert den Absender nicht.

Base64 wird bei generischen Webhooks akzeptiert; GitHub und Stripe übertragen Hex, daher gibt es dafür keine Base64-Prüfung. Das Rotieren oder Sperren eines geleakten Secrets bleibt Serverarbeit.

Zuletzt verwendet: