Keamanan API: akses pengguna, tenant, token, dan batas penggunaan

Apa yang perlu diamankan pada API?

API adalah antarmuka pertukaran data; pemeriksaan aksesnya perlu dilakukan pada layanan yang menerima permintaan. Berhasil masuk akun tidak berarti seseorang berhak membaca semua data. Autentikasi memeriksa identitas, sedangkan otorisasi menentukan izin atas tindakan dan data.

Pada aplikasi yang dipakai beberapa organisasi, tenant berarti kelompok pelanggan yang datanya perlu dipisahkan. Pemisahan tampilan saja tidak cukup. OWASP menganjurkan pemeriksaan izin pada setiap permintaan dan penolakan akses yang tidak diizinkan secara jelas.

Buat inventaris sebelum menguji

Catat API yang aktif: alamat, versi, fungsi, pemilik, pemakai, jenis data, dan lingkungan. Sertakan API lama, ekspor laporan, unggahan, webhook, serta fungsi admin yang masih dapat digunakan. Tandai integrasi milik pihak lain dan batas izin pengujiannya.

Untuk tiap fungsi, tulis pertanyaan yang hendak dibuktikan. “API sudah memakai token” terlalu umum. “Operator perusahaan A hanya boleh mengekspor pesanan A” dapat dijadikan kriteria pemeriksaan.

Contoh matriks akses dua perusahaan

Contoh fiktif: operator perusahaan A mendapat tugas mengekspor pesanan A, tanpa hak atas data perusahaan B.

Permintaan sesuai tugas

Operator A meminta ekspor pesanan perusahaan A.

PemintaOperator A

Login dengan akun yang memiliki izin ekspor pesanan A.

API memeriksa izin→

Hasil yang diharapkanEkspor A diizinkan

Hanya pesanan dalam cakupan izin yang dikirim.

Permintaan di luar hak akses

Operator A meminta ekspor pesanan perusahaan B.

Peminta yang samaOperator A

Tetap memakai akun A, meski mengetahui alamat permintaan untuk data B.

API memeriksa izin→

Hasil yang diharapkanPermintaan ditolak

Data B tidak dikirim. Login saja tidak memberi hak atas data perusahaan lain.

Ilustrasi ini menunjukkan aturan akses yang perlu diuji, bukan hasil pengujian sistem nyata. Pemeriksaan dilakukan di server untuk setiap permintaan, termasuk perusahaan, objek data, dan tindakan yang diminta.

Rujukan: OWASP Authorization Cheat Sheet · OWASP REST Security Cheat Sheet.

Contoh fiktif berikut dibuat untuk aplikasi pesanan. Siapkan akun A dan B serta pesanan buatan yang tidak mengandung data pelanggan. Jalankan pemeriksaan hanya pada sistem dan lingkungan yang telah diizinkan.

Akun uji	Tindakan	Hasil yang diharapkan
Pelanggan A	Membuka pesanannya sendiri	Diizinkan sesuai fitur
Pelanggan A	Membuka pesanan pelanggan A yang lain	Ditolak bila pesanan bersifat pribadi
Operator A	Mengekspor pesanan perusahaan A	Diizinkan bila termasuk tugasnya
Operator A	Mengekspor pesanan perusahaan B	Ditolak, tanpa data B dalam hasil atau berkas
Pelanggan A	Mengubah status persetujuan admin	Ditolak meskipun alamat fungsi diketahui
Akun yang dicabut	Memakai sesi atau token lama	Sesuai kebijakan pencabutan yang disepakati dan dibuktikan

Tambahkan kolom hasil nyata, versi aplikasi, tanggal, pemeriksa, dan lokasi bukti. Ulangi pemeriksaan untuk baca, ubah, hapus, dan ekspor sesuai fungsi. Hasil satu tindakan tidak otomatis mewakili yang lain. Periksa juga bahwa penolakan tidak mengubah data di belakang layar.

Matriks ini alat perencanaan, bukan kode pengujian atau bukti bahwa aplikasi tertentu aman. Bahas kasus tambahan dengan pengembang dan penguji.

Bagaimana mengelola token dan API key?

Token dan API key adalah kredensial; tentukan penerima, lingkup akses, masa berlaku, dan cara mencabutnya. Jangan meletakkannya dalam alamat URL yang mudah masuk ke log. API key saja tidak cukup sebagai satu-satunya pengaman sumber daya sensitif.

Jika menggunakan JWT, server perlu memeriksa keaslian token dan klaim yang relevan, seperti penerbit, penerima, serta waktu berlaku. JWT yang dapat dibaca atau berhasil diuraikan belum tentu sah. Pilihan pustaka dan konfigurasi rinci harus mengikuti teknologi yang dipakai.

Apakah rate limiting menyelesaikan penyalahgunaan?

Pembatasan jumlah permintaan membantu mengendalikan penggunaan, tetapi aturan bisnis tetap perlu diperiksa. Contoh fiktif: pengguna seharusnya menyelesaikan persetujuan sebelum laporan diterbitkan. Memperlambat permintaan tidak memperbaiki fungsi penerbitan yang bisa melewati persetujuan tersebut.

Tetapkan batas berdasarkan fungsi dan pengguna yang sah, lalu tentukan respons, pemantauan, serta jalur bantuan ketika pengguna terblokir. Jangan menguji kapasitas produksi tanpa persetujuan. Periksa pula batas biaya layanan eksternal yang dipanggil oleh API.

Latihan: login berhasil, akses apa yang boleh diberikan?

Contoh ini untuk diskusi dengan tim, bukan instruksi mencoba akun atau sistem milik orang lain.

Operator A sudah login. Bolehkah ia mengekspor pesanan perusahaan B?

Tidak, jika tugasnya hanya mencakup perusahaan A. API perlu memeriksa perusahaan, data, dan tindakan yang diizinkan. Token yang sah membuktikan bagian dari pemeriksaan identitas; token itu tidak otomatis memberi akses ke semua pelanggan.

Tombol hapus disembunyikan dari pelanggan. Apakah data sudah terlindungi?

Belum terbukti. Layanan di server harus menolak permintaan hapus dari akun yang tidak memiliki izin, meskipun tombolnya tidak terlihat. Minta hasil uji dengan akun dan data buatan pada lingkungan yang diizinkan, termasuk bukti bahwa data tidak berubah.

Halaman rincian sudah menolak akses lintas perusahaan. Apakah fitur ekspor ikut aman?

Belum tentu. Ekspor dapat memakai jalur pemeriksaan berbeda. Masukkan ekspor dan tautan unduhannya ke matriks uji; periksa isi berkas agar tidak membawa data di luar izin pengguna. Satu hasil lulus tidak berlaku untuk semua fungsi.

Apa yang perlu disimpan setelah pemeriksaan?

Simpan inventaris, matriks izin, hasil yang gagal, penanggung jawab perbaikan, dan hasil uji ulang. Hindari token aktif dan data pribadi dalam laporan yang dibagikan. Jika perlu pengujian lebih luas, gunakan panduan lingkup pentest.

Jika API dipakai aplikasi Android atau iOS, siapkan pula pemeriksaan aplikasi mobile. Pemeriksaan server dan aplikasi di perangkat memiliki lingkup yang berbeda.

Bagaimana memeriksa webhook?

Webhook mengirim pemberitahuan dari layanan lain ke aplikasi. Sebelum mengubah pesanan atau saldo, verifikasi keaslian pesan sesuai protokol pengirim. Periksa tanda tangan pada isi asli, lindungi kunci verifikasi, dan jangan menganggap alamat endpoint yang sulit ditebak sebagai autentikasi.

Siapkan penanganan pesan lama dan pengiriman berulang. Bila protokol mendukungnya, periksa waktu serta identitas kejadian yang terlindungi tanda tangan. Buat pemrosesan idempoten: pengulangan kejadian yang sama tidak menggandakan transaksi. Status dan izin bisnis tetap diperiksa di server.

Contoh uji fiktif: satu notifikasi pembayaran diterima dua kali. Hasil yang diharapkan adalah satu perubahan transaksi, dengan kedua penerimaan tercatat tanpa menyimpan kunci rahasia. Tambahkan kasus tanda tangan salah dan pesan terlambat ke matriks pengujian akses.

Saat ada dugaan penyalahgunaan yang sedang berlangsung, gunakan pemeriksaan ekspor mencurigakan atau penanganan API key bocor sesuai kejadian.

Pahami risiko di balik pemeriksaan

Baca batas akses objek, keutuhan data dari luar, kondisi gagal, daftar risiko API untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.

Pemeriksaan fitur terkait

Pada integrasi browser, bedakan CORS dari CSRF. Untuk pertukaran kejadian antarserver, periksa verifikasi webhook, duplikasi, dan urutan kejadian. Autentikasi dan izin setiap objek tetap diperlukan.