API Security Best Practices untuk Bisnis

Seorang pengembang junior di sebuah perusahaan logistik mendapat tugas sederhana: menampilkan detail pesanan di aplikasi internal. Ia menulis endpoint GET /api/orders/12345, menguji dengan nomor pesanannya sendiri, dan semuanya berjalan lancar. Aplikasi rilis. Dua bulan kemudian, auditor menemukan hal yang mencekam: endpoint itu bisa dipanggil dengan nomor berapa pun — 12344, 12346, 99999 — dan server dengan patuh mengembalikan data pesanan milik orang lain, lengkap dengan alamat, nomor ponsel, dan nilai barang. Tidak ada satu baris pun kode yang memeriksa: "apakah pemanggil ini berhak atas pesanan ini?"

Itulah API security dalam satu kalimat: keamanan yang terletak di antara sistem-sistem Anda. API (Application Programming Interface) adalah pipa yang menghubungkan website, aplikasi mobile, aplikasi kasir, ERP, dan sistem pembayaran. Setiap kali dua sistem berbicara, ada API di antaranya. Dan setiap pipa yang tidak dijaga adalah pintu masuk yang tidak terkunci.

Artikel ini adalah panduan API security untuk bisnis: mengapa API menjadi sasaran utama, sepuluh risiko terbesar menurut OWASP, praktik terbaik yang bisa diterapkan tim Anda, dan perkiraan biayanya di pasar Indonesia.

Kenapa API Menjadi Sasaran Utama

Dulu, penyerang menargetkan website atau server. Kini, sebagian besar data bisnis mengalir lewat API: aplikasi mobile berbicara ke server lewat API, toko online memanggil payment gateway lewat API, sistem akuntansi menarik data dari ERP lewat API. Laporan keamanan dari berbagai vendor konsisten menunjukkan pertumbuhan serangan API yang tajam dari tahun ke tahun — karena API adalah jalan tol data, dan banyak jalan tol yang gerbangnya tidak dijaga.

Beberapa alasan API menjadi target favorit:

• API adalah akses langsung ke data. Berbeda dengan halaman website yang menampilkan data yang sudah diatur, API sering membeberkan data mentah. Satu celah otorisasi bisa membocorkan jutaan baris sekaligus.
• API mudah ditemukan dan dipetakan. Nama endpoint sering bisa ditebak (/api/users, /api/orders), dan pola JSON-nya terbaca. Penyerang tidak perlu membobol apa pun untuk mulai menguji.
• API sering dilupakan dalam pengamanan. Website punya WAF dan pemindaian malware; API internal sering berjalan bertahun-tahun tanpa audit, termasuk endpoint lama yang tidak dipakai siapa pun — yang disebut zombie API.
• Eksposur tidak sengaja. API yang dibangun untuk sistem internal kadang terpublikasi tanpa disadari, atau dokumentasi teknisnya bocor ke repositori publik.

Risiko ini membesar seiring integrasi: semakin banyak sistem yang Anda hubungkan — dan kami membahas pertimbangannya di artikel software custom vs paket — semakin banyak API yang harus dijaga.

OWASP API Security Top 10

OWASP menerbitkan daftar sepuluh risiko keamanan API yang paling umum dan paling berbahaya. Inilah daftarnya versi 2023, disusun dari insiden nyata:

1. API1: Broken Object Level Authorization (BOLA) — pemanggil bisa mengakses objek milik orang lain dengan mengubah ID. Ini celah "ganti angka 12345 jadi 12344" dari cerita di awal.
2. API2: Broken Authentication — mekanisme login yang bisa dibypass, token yang tidak kedaluwarsa, atau kredensial yang bisa ditebak.
3. API3: Broken Object Property Level Authorization — pemanggil bisa membaca atau mengubah kolom data yang seharusnya tidak boleh (misalnya mengubah role pengguna).
4. API4: Unrestricted Resource Consumption — API tanpa batas kecepatan dan kuota, sehingga bisa dibanjiri permintaan sampai server kolaps atau biaya cloud membengkak.
5. API5: Broken Function Level Authorization — fungsi admin bisa dipanggil pengguna biasa karena otorisasi hanya disembunyikan di menu, bukan diperiksa di server.
6. API6: Unrestricted Access to Sensitive Business Flows — alur bisnis sensitif (misalnya reservasi atau klaim promo) dipakai berlebihan oleh bot.
7. API7: Server Side Request Forgery (SSRF) — API dipaksa mengirim permintaan ke alamat internal yang seharusnya tertutup.
8. API8: Security Misconfiguration — CORS terlalu longgar, pesan error terlalu detail, header keamanan hilang, atau metode HTTP yang tidak perlu masih aktif.
9. API9: Improper Inventory Management — endpoint yang tidak terdokumentasi, versi lama yang masih hidup, atau lingkungan staging yang terpublikasi.
10. API10: Unsafe Consumption of APIs — sistem Anda memakai API pihak ketiga tanpa memvalidasi datanya, sehingga data jahat ikut masuk.

Dari sepuluh ini, tiga yang paling sering ditemukan pada sistem bisnis Indonesia: BOLA, otentikasi lemah, dan misconfiguration. Ketiganya bisa dicegah tanpa teknologi mahal — hanya disiplin teknis.

Otentikasi dan Otorisasi: Dua Hal yang Berbeda

Banyak tim menggabungkan otentikasi dan otorisasi, padahal keduanya berbeda. Otentikasi menjawab "siapa Anda?"; otorisasi menjawab "apa yang boleh Anda lakukan?". API yang aman wajib memiliki keduanya, dan keduanya diperiksa di setiap permintaan.

Otentikasi yang Benar

• Gunakan standar yang mapan (OAuth 2.0, OpenID Connect) daripada membuat skema login sendiri.
• Jika memakai JWT (JSON Web Token): tanda tangani dengan algoritma kuat, periksa tanda tangan di setiap permintaan, tetapkan masa berlaku pendek (15-60 menit), dan gunakan refresh token yang bisa dicabut.
• Jangan pernah menaruh kunci rahasia di aplikasi mobile atau kode frontend — apa pun yang terunduh ke perangkat pengguna bisa dibongkar.
• Rotasi kredensial secara berkala: API key diganti, secret tidak dipakai selamanya.

Otorisasi di Setiap Endpoint

Inilah jantung API security. Setiap endpoint harus memeriksa dua lapis:

• Level fungsi: apakah pemanggil punya peran yang diizinkan memanggil endpoint ini? (misalnya hanya admin yang bisa menghapus pengguna)
• Level objek: apakah objek yang diminta benar-benar milik pemanggil? (misalnya hanya pemilik pesanan yang bisa melihat detail pesanan)

Pemeriksaan ini dilakukan di server, bukan di frontend. Menu yang disembunyikan bukan pengaman; penyerang tidak peduli menu.

Praktik Terbaik Lainnya yang Wajib Diterapkan

Validasi Input di Semua Lapisan

Anggap semua input dari API sebagai tidak tepercaya. Validasi tipe data, panjang, dan format di sisi server; jangan percaya validasi frontend. Input yang tidak divalidasi adalah sumber SQL injection, command injection, dan XSS. Gunakan allowlist (daftar nilai yang diizinkan) alih-alih denylist.

Rate Limiting dan Kuota

Batasi jumlah permintaan per pengguna, per kunci API, dan per alamat IP. Ini melindungi dari brute force, penyalahgunaan bot, dan biaya cloud yang membengkak. Terapkan juga batas ukuran payload — API yang menerima file raksasa adalah pintu masuk serangan resource exhaustion.

HTTPS di Segala Tempat

Tidak ada alasan API berjalan tanpa TLS di era sekarang. Sertifikat SSL gratis tersedia, dan semua komunikasi — termasuk antar sistem internal — harus dienkripsi. API yang menerima HTTP polos harus menolak dengan tegas.

Kelola Inventaris API

Buat daftar semua endpoint: yang dipakai, siapa pemakainya, dan versi mana yang masih aktif. Matikan endpoint yang tidak terpakai. Terapkan versi (/api/v1/, /api/v2/) sehingga perubahan tidak memutus sistem lama secara diam-diam. Endpoint yang tidak Anda ketahui tidak bisa Anda amankan.

API Gateway dan WAF

API gateway duduk di depan API Anda: mengelola otentikasi terpusat, rate limiting, logging, dan pembatasan akses. Ada opsi open source (gratis untuk dijalankan sendiri) hingga layanan terkelola. WAF untuk API menyaring pola serangan umum sebelum sampai ke aplikasi.

Logging dan Monitoring

Catat setiap permintaan API: siapa, kapan, dari mana, dan hasilnya. Tanpa log, Anda buta. Pantau anomali — lonjakan permintaan, pola akses aneh, banyaknya 401 (gagal otentikasi) — dan pasang peringatan otomatis. Log juga wajib saat investigasi insiden.

Amankan Webhook

Jika sistem Anda menerima webhook (panggilan API dari sistem lain, misalnya notifikasi pembayaran): verifikasi tanda tangan setiap payload, validasi sumbernya, dan tangani pengiriman ulang dengan idempotensi — jangan sampai satu notifikasi memproses pembayaran dua kali.

Konfigurasi CORS yang Tepat

CORS mengatur situs mana yang boleh memanggil API dari browser. Konfigurasi * (semua situs) adalah kebiasaan yang harus dihentikan; daftarkan hanya domain yang memang Anda kendalikan.

Kesalahan Umum yang Membuat API Rentan

• Menaruh kredensial di kode klien. API key di aplikasi mobile atau JavaScript frontend bisa diekstrak siapa pun.
• Token tanpa masa berlaku. Token yang berlaku selamanya adalah bom waktu.
• Pesan error yang terlalu jujur. "Password salah" vs "user tidak ditemukan" membantu penyerang memetakan akun; tampilkan pesan generik.
• Dokumentasi API yang bocor. Jangan pernah mengunggah koleksi Postman, file Swagger, atau dokumentasi internal ke repositori publik.
• Staging yang terpublikasi. Lingkungan pengembangan yang bisa diakses internet sering memuat data uji yang menyerupai data asli.
• Mempercayai API pihak ketiga. Data dari API luar harus divalidasi seperti input lainnya — API lain bisa diretas juga.

Siklus Pengembangan yang Aman

API security paling murah saat diterapkan sejak awal, bukan ditambal setelah insiden:

1. Desain: tentukan model otentikasi, daftar endpoint, dan siapa yang berhak atas apa — sebelum menulis kode.
2. Pengembangan: terapkan otorisasi di setiap endpoint, validasi input, dan gunakan pustaka yang terawat.
3. Pengujian: selain unit test, jalankan pemindaian keamanan otomatis dan penetration testing yang menyasar API secara khusus — termasuk mencoba akses dengan ID yang dimanipulasi.
4. Rilis dan operasi: gateway, monitoring, dan rencana tanggap insiden.
5. Perawatan: audit berkala, rotasi kredensial, dan pembersihan endpoint lama.

Pola ini sejalan dengan proses yang kami jalankan di Kartech. — Frame, Shape, Build, Operate — di mana keamanan bukan tahap terpisah, melainkan bagian dari setiap tahap. Kalau Anda sedang merancang sistem baru atau memodernisasi yang lama, panduan migrasi cloud dan panduan keamanan website bisa melengkapi gambaran besarnya.

Memilih Pendekatan Otentikasi API

"Gunakan token" terdengar sederhana, tetapi ada beberapa pendekatan dengan kekuatan berbeda:

Aturan praktis: API yang melayani aplikasi mobile memakai OAuth 2.0 dengan token berumur pendek; API internal antar sistem bisa memakai API key atau client credentials; API yang menangani pembayaran layak dipertimbangkan mTLS. Apa pun pilihannya, jangan pernah membangun skema otentikasi sendiri — kriptografi dan protokol yang dibuat sendiri adalah sumber celah klasik.

API untuk Mitra dan Pihak Ketiga

API yang Anda buka untuk mitra — marketplace, penyedia pembayaran, distributor — memperluas permukaan serangan. Kelola dengan disiplin:

• Kredensial terpisah per mitra. Setiap mitra mendapat kunci sendiri, dengan lingkup akses yang dibatasi. Jika satu mitra bermasalah, Anda mencabut satu kunci tanpa mengganggu yang lain.
• Rate limit per mitra. Batasi volume permintaan per kunci, sehingga satu mitra yang dikompromikan tidak bisa membanjiri sistem Anda.
• Kontrak dan persetujuan tertulis. Sebutkan batas penggunaan data, kewajiban keamanan mitra, dan tanggung jawab jika terjadi kebocoran di sisi mereka.
• Audit log per mitra. Catat siapa memanggil apa — log ini menjadi alat investigasi saat terjadi penyalahgunaan.
• Cabut akses saat kerja sama berakhir. Kedengarannya jelas, tetapi banyak akses mitra yang terus hidup bertahun-tahun setelah kontrak berakhir.

API dan UU Perlindungan Data Pribadi

API sering menjadi titik di mana data pribadi bergerak — dan UU Perlindungan Data Pribadi mengatur pergerakan itu:

• Prinsip minimalisasi. API sebaiknya mengembalikan hanya data yang dibutuhkan pemanggil. Endpoint yang mengirim seluruh profil pengguna "untuk berjaga-jaga" adalah kebiasaan buruk sekaligus risiko hukum.
• Persetujuan dan tujuan. Data yang dikirim lewat API ke mitra harus sesuai dengan tujuan yang diinformasikan kepada pemilik data. Mengirim data ke pihak ketiga tanpa dasar hukum adalah pelanggaran.
• Hak pemilik data. Pengguna berhak meminta salinan dan penghapusan data mereka. API internal Anda harus bisa memenuhi permintaan ini — bukan hanya dari database, tetapi dari semua sistem yang menerima data lewat API.
• Pencatatan dan audit. Alur data antar sistem yang terdokumentasi memudahkan Anda menjawab pertanyaan "data ini pergi ke mana?" — pertanyaan yang pasti muncul saat insiden.

API untuk Aplikasi Mobile

API adalah tulang punggung aplikasi mobile: hampir semua data yang tampil di layar ponsel datang dari API. Karena perangkat pengguna tidak bisa dipercaya sepenuhnya, keamanan API menjadi penentu keamanan aplikasi itu sendiri. Beberapa hal yang perlu diperhatikan: token disimpan di penyimpanan aman perangkat (Keychain di iOS, Keystore di Android), bukan di file teks biasa; aplikasi memverifikasi sertifikat server — certificate pinning layak dipertimbangkan untuk API kritis; dan semua keputusan otorisasi tetap di server, bukan di kode aplikasi. Aplikasi yang tampak aman di layar bisa bocor di API-nya, dan sebaliknya. Dua sisi ini tidak bisa dipisahkan: keamanan aplikasi mobile pada akhirnya ditentukan oleh seberapa aman API di belakangnya.

Checklist Keamanan API Sebelum Rilis

Sebelum API diumumkan ke publik atau dipakai sistem produksi, pastikan tim Anda bisa menjawab sepuluh pertanyaan ini:

1. Apakah semua endpoint memeriksa otorisasi, termasuk level objek?
2. Apakah otentikasi memakai standar yang mapan, bukan skema buatan sendiri?
3. Apakah token punya masa berlaku pendek dan bisa dicabut?
4. Apakah tidak ada kredensial di kode klien, dokumentasi publik, atau repositori?
5. Apakah semua komunikasi memakai HTTPS?
6. Apakah ada rate limiting dan batas ukuran payload?
7. Apakah input divalidasi di sisi server untuk semua parameter?
8. Apakah daftar endpoint (inventaris) lengkap dan versi dikelola?
9. Apakah logging aktif, tanpa mencatat data sensitif?
10. Apakah pemindaian keamanan dan pentest sudah dijalankan, dan temuan kritis diperbaiki?

Checklist ini bisa menjadi bagian dari definisi "selesai" setiap rilis API baru. API yang lulus kesepuluh pertanyaan ini jauh lebih sulit dibobol — dan jauh lebih mudah dipertanggungjawabkan saat audit. Jadikan checklist ini kebiasaan, bukan formalitas: penyerang tidak pernah menunggu checklist Anda selesai diisi.

Berapa Biaya Mengamankan API

Sebagai pembanding: satu endpoint yang bocor — seperti cerita di awal — bisa membocorkan data ribuan pelanggan dalam hitungan jam, dengan biaya pemulihan dan reputasi yang tidak terukur dalam tabel mana pun.

Pertanyaan Audit untuk Sistem Anda Sendiri

Jawab dengan jujur:

1. Apakah setiap endpoint memeriksa otorisasi level objek, bukan hanya level fungsi?
2. Apakah token punya masa berlaku dan bisa dicabut?
3. Apakah ada kredensial di kode aplikasi mobile atau frontend?
4. Apakah semua API berjalan di HTTPS?
5. Apakah ada rate limiting di API publik?
6. Apakah Anda punya daftar lengkap endpoint yang aktif — termasuk yang tidak dipakai?
7. Kapan terakhir kali API Anda diuji keamanannya?

Jika sebagian besar jawabannya "tidak" atau "tidak tahu", Anda tidak sendirian — tetapi Anda juga sedang duduk di atas risiko yang bisa diukur. Menutup celah-celah ini adalah pekerjaan teknis yang jelas dan bisa dijalankan bertahap, dan jika tim internal Anda belum pernah melakukannya, konsultan IT bisa memandu dari audit hingga perbaikannya.

Tim Kartech. di Bandar Lampung membangun dan mengamankan API untuk website, aplikasi mobile, dan sistem internal klien — dari desain otentikasi hingga pengujian sebelum rilis. Jika sistem Anda sudah berjalan dan belum pernah diaudit, kami bisa mulai dengan penilaian singkat untuk memetakan risiko yang paling mendesak. Hubungi kami lewat halaman kontak atau pelajari layanan kami.

API adalah sistem saraf digital bisnis Anda. Setiap data yang bergerak — pesanan, pembayaran, data pelanggan — melewatinya. Menjaga API berarti menjaga kepercayaan yang Anda bangun, satu endpoint pada satu waktu.