Abonnieren der Mindestanzahl von Ereignissen
Abonniere nur die Webhookereignisse, die deine App benötigt. Dadurch wird die Belastung deines Servers reduziert. Weitere Informationen zum Abonnieren von Ereignissen findest du unter Erstellen von Webhooks und Bearbeiten von Webhooks.
Verwenden eines Webhookgeheimnisses
Warning
Um eine versehentliche Offenlegung vertraulicher Informationen zu vermeiden, gib keine vertraulichen Informationen in der URL der Nutzlast an. Dazu gehören deine eigenen API-Schlüssel und andere Authentifizierungsanmeldeinformationen. Verwende ein Webhookgeheimnis, um zu überprüfen, ob Webhookübermittlungen von GitHub gesendet und dabei nicht manipuliert wurden. Weitere Informationen finden Sie unter Validierung von Webhook-Zustellung.
Das Webhook-Geheimnis sollte aus einer zufälligen Textzeichenfolge mit hoher Entropie bestehen. Du solltest dein Webhook-Geheimnis sicher und so speichern, dass dein Server darauf zugreifen kann.
Verwenden der HTTPS- und SSL-Überprüfung
Du solltest sicherstellen, dass dein Server eine HTTPS-Verbindung verwendet. Standardmäßig überprüft GitHub SSL-Zertifikate beim Bereitstellen von Webhooks. GitHub empfiehlt, die SSL-Überprüfung aktiviert zu lassen.
Zulassen von IP-Adressen von GitHub
Du kannst eine Liste zugelassener IP-Adressen für deinen Server einrichten und die IP-Adressen hinzufügen, die GitHub für Webhook-Übermittlungen verwendet. Dadurch blockierst du gespoofte Anforderungen an deinen Server.
Du kannst den GET /meta Endpunkt verwenden, um die aktuelle Liste der IP-Adressen von GitHub zu finden. Weitere Informationen finden Sie unter REST-API-Endpunkte für Metadaten. GitHub ändert gelegentlich seine IP-Adressen, sodass du deine IP-Zulassungsliste regelmäßig aktualisieren solltest.
Weitere Informationen finden Sie unter Informationen zu den IP-Adressen von GitHub.
Antworte innerhalb von 30 Sekunden
Dein Server sollte mit einer 2XX-Antwort innerhalb von 10 Sekunden nach Erhalt einer Webhook-Übermittlung antworten. Wenn die Serverantwort länger dauert, beendet GitHub die Verbindung und kategorisiert die Zustellung als Fehler.
Um zeitnah zu antworten, solltest du eine Warteschlange einrichten, um Webhook-Nutzlasten asynchron zu verarbeiten. Dein Server kann antworten, wenn er den Webhook empfängt, und dann die Nutzlast im Hintergrund verarbeiten, ohne zukünftige Webhook-Zustellungen zu blockieren. Beispielsweise kannst du Dienste wie Hookdeck oder Bibliotheken wie Resque (Ruby), RQ (Python) oder RabbitMQ (Java) verwenden.
Überprüfen von Ereignistyp und Aktion vor der Verarbeitung des Ereignisses
Es gibt mehrere Webhook-Ereignistypen, von denen viele mehrere Aktionsarten haben können. GitHub fügt kontinuierlich neue Ereignistypen und neue Aktionen zu vorhandenen Ereignistypen hinzu. Deine Anwendung sollte den Ereignistyp und die Aktion von Webhook-Nutzdaten überprüfen, bevor die Nutzdaten verarbeitet werden. Zur Ermittlung des Ereignistyps kannst du den Anforderungsheader X-GitHub-Event verwenden. Um den Aktionstyp zu ermitteln, kannst du den Schlüssel der obersten Ebene action in den Ereignisnutzdaten verwenden.
Erneute Zustellung bei Fehlschlagen der vorherigen Zustellung
Wenn dein Server ausfällt, solltest du verpasste Webhooks erneut senden, sobald der Server gesichert ist. Weitere Informationen finden Sie unter Erneutes Zustellen von Webhooks.
Verwenden Sie den X-GitHub-Delivery-Header.
Bei einem Replay-Angriff fängt ein schlechter Angreifer eine Webhook-Zustellung ab und sendet die Zustellung erneut. Zum Schutz vor Replay-Angriffen können Sie den X-GitHub-Delivery-Header verwenden, um sicherzustellen, dass jede Zustellung für einen Event eindeutig ist.
Note
Wenn du eine Neuzustellung anforderst, ist der X-GitHub-Delivery-Header mit dem der ursprünglichen Zustellung identisch.