Di episode #25 kita baru saja keliling menangkap trafik sendiri lewat Burp Suite, dan di episode #11 sudah membahas JWT vs session cookie. Kali ini saya mau mencatat satu hal yang sering saya remehkan sebagai programmer web: API dan aplikasi mobile punya “daftar penyakit” sendiri yang berbeda dari web biasa. OWASP punya dua daftar khusus — API Security Top 10 (edisi 2023) dan Mobile Top 10 (edisi 2024 final) — dan isinya ternyata bukan hal eksotis.
Kenapa API butuh daftar risiko sendiri
Saat saya membangun web biasa, “pintu masuk” aplikasi cuma satu: form login dan halaman yang dirender. API membalik keadaan: hampir semua endpoint bisa dipanggil langsung dengan request mentah, tanpa browser yang menegakkan aturan. Tidak ada tombol yang disembunyikan di UI berarti tidak ada pengaman — kalau endpoint-nya masih bisa di-curl, ia tetap terbuka. Ini yang saya catat sebagai analogi: web itu toko dengan pintu terlihat, sedangkan API itu gudang belakang dengan banyak pintu pengiriman yang kebanyakan tidak dikunci.
OWASP API Security Top 10 edisi 2023 memuat sepuluh risiko: API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Object Property Level Authorization, API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization, API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery, API8 Security Misconfiguration, API9 Improper Inventory Management, dan API10 Unsafe Consumption of APIs. Namanya saya salin persis dari situs resmi supaya bisa dicocokkan — tautannya ada di section Sumber.
Yang paling sering saya temukan di kode sendiri
API1 dan API5 adalah dua yang paling memalukan, karena keduanya soal otorisasi — dan sebagai programmer saya terbiasa menaruh kepercayaan penuh pada anggapan “user sudah login, pasti aman”. Contoh nyata polanya: endpoint GET /api/orders/{id} mengembalikan order apa pun selama ID-nya valid, tanpa memeriksa apakah order itu memang milik user yang sedang login. Cukup menebak atau mengenumerasi ID, siapa pun bisa membaca data orang lain. Pola serupa sudah kita sentuh di episode #8 soal SQL Injection; bedanya, di sini celahnya bukan di query melainkan di lapisan izin.
API4 soal resource consumption: tidak ada rate limit berarti endpoint pencarian bisa dipakai membanjiri database, atau endpoint kirim OTP bisa dipakai membuat tagihan SMS membengkak. Ini yang membuat rate limiting bukan sekadar kenyamanan server, tapi juga pengaman dompet. API9 (Improper Inventory Management) jarang dibahas tapi nyata: endpoint versi lama /api/v1/ yang sudah ditinggalkan ternyata masih hidup di server produksi tanpa patch keamanan terbaru.
Mobile: ancamannya berbeda karena perangkatnya milik penyerang
Ada satu prinsip yang mengubah cara saya melihat aplikasi mobile: aplikasi yang saya bangun berjalan di hardware yang bukan milik saya. Karena itu saya tidak bisa mengandalkan validasi yang dilakukan di sisi klien — aplikasinya bisa di-decompile, di-hook, atau dijalankan di emulator yang sudah dimodifikasi. OWASP Mobile Top 10 edisi 2024 (final release) mencatat: M1 Improper Credential Usage, M2 Inadequate Supply Chain Security, M3 Insecure Authentication/Authorization, M4 Insufficient Input/Output Validation, M5 Insecure Communication, M6 Inadequate Privacy Controls, M7 Insufficient Binary Protections, M8 Security Misconfiguration, M9 Insecure Data Storage, dan M10 Insufficient Cryptography.
M1 menempati posisi teratas, dan menurut saya ini cerminan kenyataan lapangan: API key ditempel hard-coded di source code, token tertulis di log, atau kredensial disimpan polos di penyimpanan lokal aplikasi. M9 (Insecure Data Storage) juga dekat dengan keseharian developer: menyimpan token atau data sensitif tanpa enkripsi berarti siapa pun yang mendapatkan akses fisik atau file backup perangkat bisa membacanya. Saya sendiri pernah menemukan kebiasaan lama saya menaruh secret di file config yang ikut ter-commit — persis kebersihan yang kita jauhi di episode #18 soal secrets management.
Mitigasi yang saya terapkan
- Otorisasi di setiap akses data. Prinsipnya sederhana: setiap kali kode membaca atau mengubah objek berdasarkan ID dari user, ada pemeriksaan “apakah user ini berhak atas objek ini”. Bukan sekali di middleware login, tapi di fungsi yang menyentuh data.
- Rate limiting per endpoint dan per user. Batasi jumlah request dalam jendela waktu, khususnya endpoint yang memicu efek berbayar seperti SMS, email, atau kalkulasi berat.
- Daftarkan semua endpoint. Dokumentasi OpenAPI/Swagger yang selalu diperbarui, ditambah pembersihan endpoint versi lama — kalau tidak terdokumentasi, ia tidak teraudit.
- Jangan percaya data dari pihak ketiga. API10 mengingatkan: validasi respons API mitra dengan standar yang sama seperti input user.
- Di mobile: keychain/keystore untuk secret, komunikasi selalu TLS, dan asumsikan binary akan di-reverse engineer. MFA tetap penyelamat, konsisten dengan catatan di episode #24.
Catatan legal seperti biasa: seluruh pengujian di atas hanya boleh dilakukan terhadap sistem milik sendiri atau yang izin tertulisnya sudah dipegang — bahasan lengkapnya ada di episode #22.
Sumber
Daftar resmi OWASP, diakses 2 November 2026:
Komentar Terbaru