JSON-Formatierer
JSON formatieren, prüfen und minifizieren, mit genauer Fehlerstelle.
Entwicklung
HMAC-Signaturen für Webhooks erzeugen.
Der häufigste Anwendungsfall im Alltag sind Webhooks.
Wenn ein externer Dienst eine Anfrage an deinen Server schickt — eine Zahlungsbestätigung, eine Statusmeldung — kannst du zunächst nicht wissen, ob sie wirklich von diesem Dienst kommt. Deine URL könnte jeder kennen.
HMAC löst das: Der Absender berechnet aus dem Nachrichteninhalt und einem gemeinsamen Geheimnis eine Signatur und schickt sie mit. Du berechnest dieselbe Signatur mit demselben Geheimnis und vergleichst.
Stimmen beide überein, stammt die Nachricht von jemandem, der das Geheimnis kennt, und sie wurde nicht verändert.
Der zweite Anwendungsfall sind signierte API-Anfragen, bei denen Methode, Pfad, Zeitstempel und Rumpf gemeinsam signiert werden.
Ein wichtiger Punkt zur Einordnung: HMAC ist keine Verschlüsselung. Die Nachricht bleibt lesbar — HMAC sichert nur Herkunft und Unversehrtheit.
Und es ist auch keine digitale Signatur im rechtlichen Sinn: Beide Seiten kennen dasselbe Geheimnis, also kann jede Seite die Signatur erzeugen. Für Rechtsverbindlichkeit brauchst du asymmetrische Verfahren — im deutschen Kontext etwa die qualifizierte elektronische Signatur nach eIDAS.
Bei der Prüfung werden regelmäßig dieselben Fehler gemacht.
Vergleiche die Signaturen zeitkonstant. Ein gewöhnlicher Stringvergleich bricht beim ersten abweichenden Zeichen ab, und aus dieser Laufzeit lässt sich die korrekte Signatur schrittweise erraten. Fast jede Sprache bietet dafür eine eigene Funktion.
Signiere den rohen Rumpf der Anfrage, nicht das geparste und wieder serialisierte Objekt. Schon ein anderer Umgang mit Leerzeichen oder die Reihenfolge von JSON-Schlüsseln ändert die Signatur.
Prüf den Zeitstempel, wenn der Anbieter einen mitliefert, und lehn zu alte Anfragen ab. Sonst kann ein Angreifer eine gültige Nachricht später erneut senden.
Beachte die genaue Kodierung: hexadezimal oder Base64, Groß- oder Kleinschreibung, mit oder ohne Präfix. Anbieter machen das unterschiedlich, und das ist die häufigste Ursache für eine Signatur, die "fast" stimmt.
Und behandle das Geheimnis wie ein Passwort: nicht im Quelltext, nicht im Repository, sondern in der Umgebungskonfiguration.
Die Wahl des Hashverfahrens ist einfacher, als sie wirkt.
| Verfahren | Einschätzung |
|---|---|
| HMAC-SHA256 | Standardwahl |
| HMAC-SHA512 | ebenfalls gut |
| HMAC-SHA1 | veraltet, nur für Altsysteme |
| HMAC-MD5 | nicht verwenden |
SHA-256 ist die sinnvolle Voreinstellung und die von den meisten Anbietern verwendete.
Bemerkenswert ist, dass HMAC selbst gegen Schwächen der zugrundeliegenden Hashfunktion vergleichsweise robust ist — HMAC-SHA1 gilt deshalb nicht als sofort gebrochen. Trotzdem gibt es keinen Grund, es für etwas Neues zu wählen.
Die Schlüssellänge sollte mindestens der Ausgabelänge des Hashverfahrens entsprechen, bei SHA-256 also 32 zufällige Bytes.
Und der Schlüssel muss zufällig sein. Ein selbst ausgedachtes Geheimnis ist der schwächste Punkt der ganzen Kette.
Dieses Werkzeug rechnet vollständig in deinem Browser. Der Schlüssel verlässt dein Gerät nicht — trotzdem gilt: Nutz für produktive Geheimnisse keine Weboberfläche, sondern deine eigene Umgebung.
Um zu prüfen, ob eine Nachricht — typischerweise ein Webhook — echt und unverändert ist.
Nein. Die Nachricht bleibt lesbar; HMAC sichert nur Herkunft und Unversehrtheit.
Weil aus der Laufzeit eines normalen Vergleichs die korrekte Signatur erraten werden kann.
Meist weil der Rumpf neu serialisiert wurde oder die Kodierung abweicht — hex statt Base64.
HMAC-SHA256 als Standard. MD5 nicht mehr verwenden.
Nein, die Berechnung läuft im Browser. Für produktive Geheimnisse nutz trotzdem deine eigene Umgebung.