HTTP Message Signatures: Memverifikasi Integritas Permintaan API

HTTPS melindungi komunikasi antara klien dan server, tetapi dalam sistem API yang melewati gateway, proxy, antrean, atau beberapa layanan, terkadang dibutuhkan bukti tambahan bahwa bagian tertentu dari pesan HTTP tidak berubah dan benar-benar ditandatangani oleh pihak yang memegang kunci yang diharapkan. HTTP Message Signatures, yang distandardisasi dalam RFC 9421, menyediakan format interoperabel untuk menandatangani komponen terpilih dari pesan HTTP.

Mekanisme ini berguna untuk integrasi antarlayanan, API berisiko tinggi, dan arsitektur yang melibatkan perantara. Namun, tanda tangan bukan pengganti TLS, autentikasi, atau pemeriksaan izin. Manfaatnya muncul ketika aplikasi menentukan dengan jelas apa yang ditandatangani, siapa yang boleh menandatangani, dan bagaimana tanda tangan diverifikasi.

Apa yang ditandatangani?

Berbeda dari skema khusus yang setiap penyedia rancang sendiri, RFC 9421 mendefinisikan cara menyatakan komponen HTTP yang masuk ke perhitungan tanda tangan. Komponen itu dapat mencakup metode, otoritas tujuan, path, query, status respons, atau field seperti content-type. Pilihan komponen ditulis dalam Signature-Input, sedangkan hasil kriptografinya dibawa dalam Signature.

Misalnya, layanan yang menerima permintaan perubahan akun mungkin perlu memastikan bahwa metode, path, tujuan, dan digest isi permintaan tetap sesuai. Jika hanya menandatangani satu field yang tidak penting, penyerang mungkin masih dapat mengubah bagian lain yang memengaruhi arti permintaan. Karena itu, cakupan tanda tangan harus mengikuti keputusan keamanan aplikasi, bukan sekadar menyalin contoh konfigurasi.

Bagaimana alur kerjanya?

1. Pilih komponen. Pengirim menentukan bagian pesan yang wajib dilindungi, termasuk metadata waktu atau identitas kunci bila diperlukan.
2. Bentuk signature base. Komponen terpilih dinormalisasi menjadi representasi yang ditentukan standar. Urutan dan aturan pembentukannya penting; jangan membuat format sendiri.
3. Tandatangani. Pengirim memakai algoritma dan kunci yang disepakati. RFC 9421 mendukung penggunaan tanda tangan digital maupun message authentication code sesuai kebutuhan implementasi.
4. Kirim bersama parameter. Pesan memuat informasi signature dan parameter yang diperlukan untuk memverifikasi bagaimana signature dibuat.
5. Verifikasi di penerima. Penerima membentuk ulang signature base, mengambil kunci yang tepat, memeriksa kriptografi, lalu memastikan identitas penandatangan memang diizinkan.

Verifikasi kriptografi yang berhasil belum otomatis berarti permintaan aman. Server tetap perlu memeriksa autentikasi, otorisasi, format data, batas ukuran, dan aturan bisnis sebelum melakukan tindakan.

Melindungi isi pesan dengan Content-Digest

HTTP Message Signatures tidak otomatis menandatangani seluruh byte isi pesan. Untuk melindungi isi, RFC 9530 mendefinisikan field seperti Content-Digest. Pengirim menghitung digest dari konten, lalu memasukkan field digest itu ke dalam komponen yang ditandatangani. Penerima harus menghitung ulang digest dari konten yang benar-benar diterima dan membandingkannya dengan nilai yang dikirim.

Langkah terakhir ini krusial. Jika server hanya memverifikasi signature atas teks Content-Digest tanpa mencocokkan digest itu dengan body aktual, isi pesan berpotensi diganti sementara field digest lama tetap ada. Perhatikan juga bahwa perubahan content encoding oleh perantara dapat memengaruhi digest; setiap komponen sistem harus memiliki aturan yang konsisten tentang representasi mana yang dilindungi.

Perbedaan dengan TLS dan signature webhook

TLS melindungi koneksi dan membantu memastikan klien terhubung ke server yang benar. Namun, perlindungan koneksi tidak selalu menyediakan bukti yang tetap melekat pada pesan setelah pesan melewati perantara atau disimpan untuk diproses oleh layanan lain. HTTP Message Signatures dapat melengkapi TLS dengan melindungi komponen pesan tertentu di tingkat aplikasi, tetapi tidak mengenkripsi isi pesan dan tidak menyembunyikan metadata.

Signature webhook sering menggunakan format dan aturan khusus milik penyedia, misalnya HMAC atas body mentah. RFC 9421 menawarkan kerangka standar yang lebih umum untuk memilih komponen HTTP. Jangan menganggap keduanya bisa dipertukarkan begitu saja: implementasi harus mengikuti protokol yang disepakati dengan mitra. Untuk dasar pengamanan webhook, lihat panduan verifikasi signature webhook dan pencegahan replay.

Checklist penerapan yang aman

• Tentukan identitas penandatangan. Petakan keyid ke kunci yang tepercaya dan identitas layanan yang jelas. Jangan menerima signature valid dari kunci sembarang.
• Batasi masa berlaku. Gunakan parameter waktu seperti created dan, jika sesuai, expires. Terapkan toleransi jam yang realistis dan pantau sinkronisasi waktu.
• Cegah replay. Untuk operasi sensitif, pertimbangkan nonce atau identifier unik dan simpan status pemakaian secara aman. Timestamp saja tidak selalu mencegah pengulangan di dalam jendela valid.
• Periksa cakupan. Pastikan metode, tujuan, path, parameter penting, dan digest body ikut dilindungi sesuai risiko. Tolak permintaan jika komponen wajib tidak tercakup.
• Kelola rotasi kunci. Siapkan masa transisi yang terkontrol, pencabutan kunci yang bocor, dan pemantauan kegagalan verifikasi.
• Uji perantara. Uji gateway, proxy, dan middleware yang mungkin mengubah header, path, encoding, atau urutan pemrosesan. Jangan membiarkan perubahan yang tidak dipahami diam-diam melewati verifikasi.
• Hindari log sensitif. Catat alasan verifikasi gagal dan identitas kunci yang relevan, tetapi jangan menyimpan secret atau data pribadi lengkap tanpa kebutuhan.

Keterbatasan yang perlu dipahami

Signature membuktikan bahwa komponen yang tercakup cocok dengan proses penandatanganan dan kunci yang digunakan; signature tidak membuktikan bahwa isi permintaan benar, pengguna berhak melakukan tindakan, atau layanan penandatangan tidak disusupi. Kesalahan konfigurasi kunci, cakupan yang terlalu sempit, implementasi normalisasi yang berbeda, dan kebijakan replay yang lemah tetap dapat membuka celah.

Kesimpulan

HTTP Message Signatures (RFC 9421) menyediakan cara standar untuk melindungi komponen terpilih dari pesan HTTP, sementara Content-Digest (RFC 9530) membantu mengikat isi pesan ke signature. Terapkan keduanya dengan cakupan yang sesuai, validasi identitas penandatangan, perlindungan replay, dan pengujian pada seluruh jalur jaringan. Gunakan spesifikasi resmi sebagai acuan implementasi: RFC 9421 — HTTP Message Signatures dan RFC 9530 — Digest Fields.