# Keamanan webhook: verifikasi, pengiriman ulang, dan akses

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Webhook mengirim pemberitahuan kejadian antar-sistem. Penerima perlu memastikan keaslian pesan dan mencegah dampak ganda; pengirim perlu membatasi tujuan serta pengiriman ulang.

URL kanonis: https://kompli.id/panduan/owasp/keamanan-webhook/
Sumber diakses: 2026-09-30
Diperbarui: 2026-09-30
Penulis: Kompli
Sumber diperiksa: 2026-09-30


## Apa yang berbeda dari permintaan biasa?

**Webhook adalah pemberitahuan yang dikirim satu sistem ke endpoint sistem lain saat suatu kejadian terjadi.** Endpoint yang dapat menerima `POST` belum otomatis mengetahui apakah pengirim sah atau isi pesannya benar.

HTTPS melindungi koneksi, tetapi penerima tetap perlu memverifikasi pengiriman sesuai protokol yang disepakati. Signature adalah nilai yang digunakan untuk memeriksa keaslian pesan; beberapa protokol memakai MAC, yaitu kode autentikasi pesan dengan kunci bersama. URL yang sulit ditebak atau alamat IP pengirim saja bukan bukti keaslian pesan yang memadai.

## Contoh: status pesanan tidak boleh diproses dua kali

Toko fiktif menerima kejadian perubahan status pesanan. Pengiriman pertama sudah disimpan untuk diproses, tetapi jawaban penerima tidak sampai ke pengirim. Pengirim mencoba lagi.

Tim memakai identitas kejadian yang terverifikasi dan catatan pemrosesan yang tersimpan. Pengiriman ulang yang sah dikenali tanpa mengulang pengurangan stok. Pekerjaan dibuat *idempotent*: pengulangan kejadian yang sama tidak menggandakan dampak bisnis.

## Periksa keaslian sebelum mengubah data

- Ikuti format verifikasi pengirim secara tepat; gunakan pustaka verifikasi yang dipelihara bila tersedia.
- Jika signature mencakup body asli, verifikasi byte tersebut sebelum parser mengubahnya. Menyusun ulang JSON dapat menghasilkan byte berbeda.
- Periksa signature menggunakan mekanisme yang sesuai, termasuk pembandingan waktu konstan untuk MAC.
- Validasi struktur data, jenis kejadian, dan hubungan objek dengan akun yang benar sebelum menjalankan tindakan.
- Lindungi secret; jangan mencatat secret atau header signature lengkap pada log umum.

Format protokol berbeda-beda. Jangan menganggap setiap timestamp atau ID pada header ikut ditandatangani. Gunakan timestamp terautentikasi untuk pemeriksaan kesegaran jika protokol mendukungnya, lalu tentukan toleransi sesuai dokumentasi dan kondisi sistem.

## Replay, duplikasi, dan urutan bukan hal yang sama

Signature valid saja tidak mencegah pesan lama dikirim ulang. Pemeriksaan kesegaran, deduplikasi, serta efek bisnis yang idempotent mempunyai fungsi berbeda dan perlu dirancang bersama.

Pengiriman ulang yang sah dapat berlangsung lebih lama daripada jendela kesegaran satu pesan. Simpan catatan pemrosesan sesuai kebutuhan retry protokol. Jangan menganggap kejadian selalu datang berurutan; periksa versi atau keadaan objek terkini bila protokol tidak menjamin urutan.

## Kasus uji sebelum integrasi diterima

| Kejadian uji | Hasil yang diperiksa |
| --- | --- |
| Signature tidak valid atau body berubah | Tidak mengubah status pesanan |
| Pesan sah dikirim ulang | Dampak bisnis hanya sekali |
| Pesan lama atau urutan terbalik | Ditangani sesuai aturan protokol dan keadaan objek |
| Penyimpanan/antrean gagal | Tidak mengaku berhasil menerima secara permanen; retry dapat ditangani |

Setujui kapan respons sukses diberikan, idealnya setelah pesan terverifikasi tersimpan secara andal untuk diproses. Batasi ukuran, laju, dan waktu pemrosesan.

## Bila aplikasi menjadi pengirim

Tujuan callback milik pengguna perlu [pencegahan SSRF](/panduan/owasp/ssrf/), verifikasi TLS, serta retry yang dibatasi. Rotasi secret terencana berbeda dari kebocoran: jangan mempertahankan secret yang diduga bocor hanya demi masa transisi. Gunakan [panduan kredensial bocor](/panduan/keamanan/api-key-bocor/) dan catat integrasi yang harus dipulihkan.
## Sumber rujukan

- [Webhook Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Webhook_Security_Cheat_Sheet.html) — Authenticating Deliveries; Replay, Duplicates, and Abuse; SSRF Prevention; Secret Rotation
- [Server Side Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) — Cases; outbound request protections

## Perlu membahas kebutuhan tim Anda?

Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=keamanan)

## Bacaan terkait

- [Apa itu SSRF? Membatasi permintaan keluar dari server](https://kompli.id/panduan/owasp/ssrf/)
- [Keamanan API: akses pengguna, tenant, token, dan batas penggunaan](https://kompli.id/panduan/keamanan/keamanan-api-akses-data/)
- [Langkah menangani API key atau token yang bocor](https://kompli.id/panduan/keamanan/api-key-bocor/)