Cara Uji Endpoint API Tanpa Login: 6 Pemeriksaan Otorisasi

Setiap endpoint API yang menangani data sensitif wajib memiliki kontrol otorisasi yang ketat. Namun banyak pengembang menguji endpoint hanya dengan akun yang sudah login, lalu menganggap akses tanpa login atau dengan peran berbeda sudah diblokir. Kenyataannya, celah otorisasi sering muncul justru ketika pengujian dilakukan dari sudut pandang penyerang: tanpa token, dengan token pengguna lain, atau dengan parameter yang dimanipulasi.

Artikel ini menjelaskan cara uji endpoint API tanpa login menggunakan alat sederhana seperti curl atau DevTools browser. Anda akan mempelajari enam pemeriksaan praktis untuk mendeteksi akses tak sah, IDOR, dan kesalahan konfigurasi otorisasi. Ingat, hasil pemindaian manual ini adalah indikasi, bukan bukti eksploitasi. AISG menyediakan pemindaian URL gratis tanpa akun di /#free-scan yang dapat membantu menemukan indikasi awal secara otomatis.

Memahami Kode Status 401 dan 403

Sebelum menguji, pahami perbedaan mendasar antara kode status HTTP 401 dan 403. Kode 401 Unauthorized berarti permintaan tidak memiliki kredensial autentikasi yang valid; pengguna harus login terlebih dahulu. Kode 403 Forbidden berarti pengguna sudah terautentikasi, tetapi tidak memiliki izin untuk mengakses sumber daya tersebut. Dalam pengujian otorisasi, respons 401 atau 403 adalah normal untuk permintaan tanpa token atau dengan token yang tidak berwenang. Jika Anda menerima kode 2xx (seperti 200, 201, atau 204) pada endpoint yang seharusnya dilindungi, itu merupakan temuan yang perlu ditindaklanjuti.

Pemeriksaan Autentikasi dan Peran

Dua pemeriksaan pertama menguji apakah endpoint memerlukan autentikasi dan apakah peran pengguna dibatasi dengan benar.

1. Panggil endpoint tanpa token sama sekali. Gunakan curl atau mode penyamaran browser. Contoh perintah: curl -i https://api.contoh.com/users/123. Jika server mengembalikan data pengguna dengan status 200, endpoint tersebut tidak memeriksa autentikasi. Respons yang benar adalah 401 atau 403.
2. Gunakan token dari pengguna dengan peran berbeda. Misalnya, akses endpoint admin menggunakan token pengguna biasa. Contoh: curl -i -H "Authorization: Bearer [token_user_biasa]" https://api.contoh.com/admin/users. Respons yang diharapkan adalah 403 Forbidden. Jika Anda menerima 200 dengan daftar pengguna, kontrol peran tidak diterapkan.

Pemeriksaan IDOR dan Manipulasi Parameter

IDOR (Insecure Direct Object Reference) terjadi ketika aplikasi menggunakan referensi objek langsung—seperti ID numerik—tanpa memeriksa kepemilikan. Untuk menguji, ubah nilai ID pada URL atau body permintaan.

Contoh: curl -i -H "Authorization: Bearer [token_pengguna_A]" https://api.contoh.com/users/124. Jika pengguna A (ID 123) menerima data pengguna 124 dengan status 200, itu IDOR. Respons yang benar seharusnya 403 atau 404; mengembalikan 404 lebih aman agar tidak membocorkan keberadaan sumber daya.

Selanjutnya, ubah metode HTTP atau Content-Type. Beberapa backend hanya memvalidasi otorisasi pada metode tertentu. Coba kirim POST atau PUT ke endpoint yang sama. Contoh: curl -i -X PUT -H "Authorization: Bearer [token]" https://api.contoh.com/users/123. Selain itu, ubah header Content-Type dari application/json ke application/x-www-form-urlencoded atau multipart/form-data. Perubahan ini bisa membuat middleware otorisasi terlewat.

Pemeriksaan Payload Tak Terduga dan Endpoint Tersembunyi

Kirim data massal atau parameter tak terduga untuk menguji validasi otorisasi yang lemah. Coba tambahkan field seperti is_admin=true, role=admin, atau access_level=999 pada body JSON. Contoh: curl -i -X PUT -H "Content-Type: application/json" -H "Authorization: Bearer [token_user_biasa]" -d '{"is_admin": true}' https://api.contoh.com/users/123. Jika server menerima dan memproses field tersebut, akun biasa bisa mendapatkan hak istimewa.

Periksa juga endpoint tersembunyi atau versi lama. Versi /api/v1/ mungkin masih aktif sementara perbaikan hanya diterapkan pada /api/v2/. Coba panggil endpoint versi lama. Endpoint tidak terdokumentasi seperti /debug, /internal, atau /backup sering tidak terlindungi. Temukan dengan memeriksa file JavaScript di DevTools atau mencoba pola URL umum.

Menginterpretasikan Temuan dan Langkah Selanjutnya

Jika Anda menemukan respons 2xx pada endpoint yang seharusnya memerlukan otorisasi lebih tinggi, segera dokumentasikan dan perbaiki. Terapkan kontrol otorisasi di setiap endpoint, bukan hanya di lapisan antarmuka. Gunakan prinsip least privilege dan validasi kepemilikan objek untuk mencegah IDOR.

Kesimpulan

Cara uji endpoint API tanpa login membutuhkan pendekatan sistematis: mulai tanpa token, lalu uji peran berbeda, manipulasi ID dan parameter, metode HTTP, payload tak terduga, dan endpoint tersembunyi. Kode status 401 dan 403 adalah respons yang benar; kode 2xx pada akses tak sah adalah temuan. Pengujian manual ini adalah langkah awal yang penting sebelum mengandalkan pemindaian otomatis.

Untuk pendalaman lebih lanjut, baca artikel kami tentang keamanan API untuk aplikasi AI dengan RAG dan .env dan .git ter-deploy: cara cek dan menutupnya. Keduanya membahas aspek keamanan yang sering terkait dengan pengujian otorisasi endpoint.