Bayangkan Anda menginap di sebuah hotel. Resepsionis tidak hanya menanyakan nama Anda, tetapi juga memastikan Anda memang berhak menerima kunci kamar 305 dan tagihan atas nama Anda. Kalau ia asal memberikan kunci kepada siapa pun yang menyebut nomor kamar, hotel itu bermasalah, meski antrean tertib dan semua orang tersenyum.

API (Application Programming Interface) adalah resepsionis itu untuk aplikasi. Saat Anda membuka riwayat transaksi di aplikasi mobile, aplikasi tidak mengambil data sendiri. Ia menitipkan permintaan ke API, dan API yang memutuskan apa yang boleh dijawab. Jadi, keamanan API bertumpu pada keputusan yang tampak sederhana tetapi krusial: apakah orang yang bertanya memang berhak menerima jawabannya?

Justru di titik inilah banyak API tersandung. Sebuah API dapat menerima token yang valid, mengembalikan data berformat rapi, dan menjawab dengan kode HTTP 200 (tanda "berhasil"), padahal data yang diberikan milik orang lain. Semuanya tampak normal, kecuali bagi orang yang tahu apa yang seharusnya terjadi. Tulisan ini membahas bagaimana pengujian keamanan API berbeda dari Vulnerability Assessment and Penetration Testing (VAPT) pada umumnya, yaitu pengujian keamanan terkontrol dan berizin yang meniru langkah penyerang untuk menemukan kelemahan sebelum ditemukan pihak jahat.

Apa yang Membedakan VAPT API dari VAPT Biasa

Table 1: Perbandingan fokus VAPT web dan VAPT API.

Baris ketiga adalah inti perbedaannya. Karena fungsi API bisa dipanggil langsung, aturan yang hanya ditegakkan di tampilan tidak ikut melindungi server. Aplikasi yang tidak menyediakan tombol "hapus" untuk pelanggan, misalnya, belum tentu menolak permintaan hapus yang dikirim langsung ke API.

Bukan berarti pengujian web tidak bisa memeriksa otorisasi atau logika bisnis. Bila aplikasi memakai API di belakang antarmukanya, kedua pendekatan saling melengkapi, dan API VAPT memperdalam pemeriksaan pada lapisan komunikasi antarsistem. Perbedaan itu paling terasa pada tiga hal yang kita bahas berikut: siapa berhak atas objek mana, bagaimana rangkaian permintaan yang sah bisa menyalahgunakan proses bisnis, dan endpoint mana yang sebenarnya masih hidup.

Pembeda Pertama: Siapa Berhak atas Objek Mana

Mari mulai dari kelemahan yang paling sering dibahas. Misalkan sebuah aplikasi memiliki alamat GET /api/invoices/501 untuk menampilkan tagihan nomor 501. Pemilik tagihan membukanya dan semuanya wajar. Namun, bagaimana jika pengguna lain yang hanya mengetahui nomor itu juga bisa membukanya?

Kelemahan ini disebut Broken Object Level Authorization (BOLA): server gagal memeriksa apakah pengguna berhak atas objek tertentu. OWASP menempatkannya di urutan pertama dalam daftar risiko API tahun 2023.

Mengganti nomor berurutan dengan kode acak seperti UUID memang menyulitkan tebakan, tetapi tidak menggantikan pemeriksaan izin di server, sebab kode itu masih bisa bocor lewat log, tautan, atau respons endpoint lain.

Mengapa pengujian biasa mudah melewatkannya? Karena dari luar, respons yang benar dan yang salah tampak sama: keduanya berstatus 200 dengan data yang rapi. Pemindai mencari ciri yang dapat dikenali, seperti pesan galat yang bocor atau konfigurasi yang keliru, sedangkan pembeda di sini hanyalah siapa yang meminta dan milik siapa datanya. Informasi itu hanya dipahami oleh orang yang tahu bagaimana aplikasi membagi kepemilikan data.

Karena itu, tugas penguji bukan sekadar mengubah angka di alamat lalu melihat apa yang keluar. Ia menyiapkan dua akun uji dengan kepemilikan yang jelas, misalnya akun A sebagai pemilik tagihan dan akun B yang tidak berhak. Respons saat A mengakses dijadikan pembanding bagi respons saat B mencoba objek yang sama. Respons 403 (dilarang) atau 404 (tidak ditemukan) menandakan kontrol bekerja, sedangkan respons 200 berisi data milik A kepada B menandakan kontrol gagal. Respons 200 yang kosong perlu dicermati lebih jauh: apakah datanya benar-benar tersaring, atau hanya tampak kosong?

Tidak semua yang tampak seperti BOLA adalah kerentanan. Objek yang memang dibagikan secara sengaja, pengguna yang mengakses objek lain miliknya sendiri, atau administrator yang sah melihat banyak data adalah perilaku yang wajar. Sebuah temuan baru layak dinyatakan valid bila melanggar aturan akses yang dimaksudkan, dapat direproduksi, dan dampaknya dapat dijelaskan, misalnya terbukanya data pribadi atau finansial pelanggan lain. Bukti pun dikumpulkan seminimal mungkin: cukup menunjukkan bahwa akses terjadi, tanpa mengunduh data orang lain.

Pola yang sama berlaku pada dua lapisan lain. Pada tingkat fungsi, akun pelanggan mungkin hanya boleh melihat profilnya sendiri, tetapi tetap bisa memanggil fungsi administratif seperti menonaktifkan akun lain, karena server hanya memeriksa "sudah login" tanpa memeriksa peran. Pada tingkat properti, API yang menerima semua isian dari pengguna tanpa disaring dapat membiarkan atribut sensitif seperti peran (role) atau batas kredit berubah, yang dikenal sebagai mass assignment. Kedua kasus ini diuji dengan cara serupa: membandingkan apa yang seharusnya boleh dilakukan tiap peran dengan apa yang benar-benar diizinkan server.

Pembeda Kedua: Ketika Semua Permintaan Sah, tetapi Rangkaiannya Tidak

Kelemahan otorisasi masih melanggar aturan akses yang jelas. Ada jenis lain yang lebih licin: setiap permintaan sah secara teknis, tetapi rangkaiannya menyalahgunakan proses bisnis. Kode diskon yang seharusnya sekali pakai per akun ternyata bisa dipakai berulang, atau proses pemesanan bisa diotomatisasi tanpa batas yang wajar. Tidak ada pesan galat dan tidak ada token palsu; yang keliru hanyalah asumsi bisnisnya.

Untuk menemukannya, penguji harus lebih dulu memahami alur normal: urutan langkah, batas transaksi, dan konsekuensi finansial atau operasional bila batas itu dilewati. Tanpa gambaran itu, tidak ada yang bisa disebut menyimpang. Inilah sebabnya pemindai otomatis sulit menggantikan analisis manual pada kategori ini. OWASP pun mencatat penyalahgunaan alur bisnis yang sensitif dan konsumsi sumber daya tanpa batas sebagai risiko tersendiri pada API.

Pembeda Ketiga: Endpoint Lama yang Terlupakan

Dua pembeda tadi mengandaikan penguji sudah tahu pintu mana saja yang ada. Kenyataannya, daftar pintu itu sendiri sering tidak lengkap.

Satu kelemahan yang sering diremehkan adalah endpoint yang tidak lagi diawasi. Bayangkan pengembang menambal pemeriksaan kepemilikan pada /api/v2/invoices, tetapi /api/v1/invoices masih aktif dan belum ditambal. Penguji yang hanya menguji versi terbaru akan menyimpulkan API aman. Karena itu pemetaan endpoint, versi, dan endpoint debug menjadi langkah awal yang menentukan. Menurut OWASP, masalah ini termasuk Improper Inventory Management.

Dari Temuan ke Perbaikan

Mengetahui celahnya baru separuh jalan; perbaikannya perlu mengikuti jenis masalah yang ditemukan.

Untuk kelemahan otorisasi, pemeriksaan kepemilikan dan peran sebaiknya dilakukan di server pada setiap permintaan, idealnya lewat mekanisme terpusat agar tidak bergantung pada ingatan pengembang di tiap endpoint. Matriks yang disusun penguji (akun, objek, tindakan, hasil yang seharusnya) bisa sekaligus dijadikan skenario uji otomatis, sehingga perbaikan tidak hilang pada rilis berikutnya.

Untuk penyalahgunaan proses bisnis, batas pemakaian seperti rate limit (batas jumlah permintaan dalam waktu tertentu) perlu ditetapkan menurut dampak bisnisnya, bukan angka standar. Hal serupa berlaku pada integrasi dengan layanan pihak ketiga: respons dari layanan eksternal tidak otomatis tepercaya, sehingga perlu divalidasi dan aksesnya dibatasi sesuai kebutuhan. Panduan OWASP untuk pengembang merangkum risiko-risiko ini sebagai bahan pelatihan.

Terakhir, setiap temuan sebaiknya memiliki pemilik, prioritas, tenggat, dan bukti pengujian ulang setelah diperbaiki, supaya tidak berhenti sebagai catatan di laporan.

Kesimpulan

Jadi, pembeda VAPT API bukan pada tahapan atau alat yang dipakai, melainkan pada apa yang dibuktikan. Pengujian web berfokus pada apa yang tampil dan bisa diisi di antarmuka, sedangkan pengujian API menanyakan hal yang lebih mendasar pada setiap permintaan: siapa boleh melihat apa, siapa boleh menjalankan apa, dan apa yang terjadi bila prosesnya diulang atau dibalik. API yang menjawab dengan benar belum tentu menjawab dengan berhak.

Langkah praktis bagi organisasi adalah memetakan endpoint beserta versinya, menyusun matriks peran dan hak akses, lalu menguji skenario lintas akun dan lintas fungsi secara terkontrol. Hasilnya adalah API yang tidak hanya berfungsi, tetapi juga hanya melayani pihak yang berhak.

Daftar Referensi

• OWASP API Security Top 10 (2023). https://owasp.org/API-Security/

• OWASP API1:2023, Broken Object Level Authorization. https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/

• OWASP API9:2023, Improper Inventory Management. https://api-security.owasp.org/editions/2023/en/0xa9-improper-inventory-management/

• OWASP Web Security Testing Guide, Business Logic Testing. https://wstg.owasp.org/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/

• OWASP Developer Guide, API Top Ten. https://devguide.owasp.org/en/07-training-education/07-api-top-ten/