Pentest API aplikasi modern: titik audit yang paling sering bikin data bocor

API adalah bagian aplikasi yang paling sering terlalu dipercaya.

Frontend bisa terlihat rapi. Tombol bisa disembunyikan. Menu admin bisa tidak muncul untuk user biasa. Tapi kalau API tetap menerima request yang dibuat manual, kontrol di UI tidak ada artinya.

Di aplikasi modern, API bukan fitur sampingan. API dipakai oleh web frontend, mobile app, dashboard admin, payment gateway, webhook, partner, automation, dan kadang AI agent. Karena itu pentest API harus berdiri sendiri, bukan cuma bonus dari pentest web.

Artikel ini bagian dari seri audit keamanan aplikasi. Untuk peta besar, baca audit keamanan aplikasi dengan standard pentest. Untuk bagian login dan permission, baca audit login, session, dan access control. Untuk celah proses bisnis, baca business logic vulnerability.

Standard yang dipakai

Rujukan utama untuk API adalah OWASP API Security Top 10 2023. Daftarnya berbeda dari OWASP Top 10 web biasa karena API punya pola risiko sendiri: object authorization, property exposure, resource consumption, function authorization, dan inventory.

Untuk requirement kontrol, API juga bisa dirujuk ke OWASP ASVS, terutama area authentication, session/token, authorization, input validation, web service, data protection, dan logging.

Kalau API dipakai mobile app, rujukan mobile-nya adalah OWASP MASVS. Kalau API dipakai agent atau AI workflow, masukkan risiko tool abuse dan prompt injection dari OWASP Top 10 for LLM/GenAI.

Mulai dari API inventory

Pentest API yang baik dimulai dari pertanyaan sederhana: endpoint apa saja yang sebenarnya hidup?

Jangan hanya percaya dokumentasi. Dokumentasi sering ketinggalan. Auditor perlu melihat:

• OpenAPI/Swagger jika ada;
• traffic dari web app;
• traffic dari mobile app;
• route di frontend bundle;
• endpoint lama seperti /v1, /legacy, /internal;
• admin API;
• webhook receiver;
• integration callback;
• staging atau dev API yang masih public;
• GraphQL schema jika aplikasi memakai GraphQL.

Inventory penting karena endpoint yang tidak terdaftar sering tidak punya kontrol yang sama. Endpoint lama bisa lupa rate limit. Endpoint internal bisa tidak cek role. Endpoint admin bisa cuma disembunyikan dari UI.

BOLA: user ganti ID, data orang lain kebuka

Broken Object Level Authorization atau BOLA adalah bug API yang paling sering mahal.

Contoh sederhana:

User A punya invoice /api/invoices/1001. User B mengganti ID menjadi /api/invoices/1001 dan API tetap memberi data. Ini bukan bug tampilan. Ini bug authorization.

Yang harus diuji:

• object milik user lain;
• object milik tenant lain;
• invoice, order, booking, ticket, file, report, lead, project;
• endpoint read, update, delete, export;
• ID berurutan, UUID, slug, public token;
• nested object seperti /organizations/{orgId}/users/{userId}.

UUID tidak menyelesaikan BOLA. UUID hanya membuat ID lebih sulit ditebak. Kalau object URL bocor dari log, email, referer, atau shared link, authorization tetap harus menolak user yang tidak berhak.

Broken authentication

API auth sering rusak bukan karena token pendek, tapi karena lifecycle token buruk.

Audit perlu mengecek:

• token expiry;
• refresh token rotation;
• revoke saat logout;
• revoke saat password berubah;
• revoke saat role berubah;
• issuer dan audience JWT;
• signature validation;
• algorithm confusion;
• API key yang tidak punya scope;
• token yang diterima dari environment salah;
• auth bypass di endpoint tertentu.

Untuk API internal, jangan pakai alasan "ini hanya dipanggil dari frontend kita". Frontend bukan boundary keamanan. Semua request frontend bisa ditiru.

Object property authorization

Kadang user memang boleh mengakses object, tapi tidak semua field.

Contoh:

Customer boleh melihat order miliknya, tapi tidak boleh melihat internal margin, fraud note, payment gateway raw response, atau nomor rekening penuh. Staff support boleh melihat email customer, tapi mungkin tidak boleh melihat token, dokumen KYC, atau field internal finance.

Audit harus mengecek dua arah:

• response terlalu banyak field;
• request bisa mengubah field yang tidak boleh diubah.

Mass assignment masuk di sini. Jika API menerima JSON lalu langsung map ke model, user bisa menambahkan field seperti role: "admin", isPaid: true, price: 0, atau tenantId milik tenant lain.

Solusinya bukan blocklist field berbahaya. Gunakan allowlist field yang memang boleh diterima per endpoint dan per role.

Function level authorization

Broken Function Level Authorization terjadi saat user bisa memanggil fungsi yang seharusnya hanya untuk role tertentu.

Contoh:

• user biasa memanggil endpoint admin;
• staff support menjalankan refund;
• vendor mengubah status order final;
• customer mengakses export laporan;
• partner memanggil endpoint delete;
• role viewer bisa menjalankan update.

Audit jangan hanya cek halaman. Cek endpoint langsung. Kalau role tidak boleh melakukan aksi, API harus menolak dengan status yang tepat, bukan hanya frontend tidak menampilkan tombol.

Resource consumption dan rate limit

API yang aman juga harus tahan abuse.

Unrestricted resource consumption bisa muncul dari endpoint yang berat:

• export CSV besar;
• generate PDF;
• upload file besar;
• query search tanpa limit;
• report agregasi mahal;
• AI inference;
• image/video generation;
• endpoint yang trigger email/WhatsApp/SMS.

Audit harus mengecek rate limit per IP, per user, per token, per tenant, dan per resource. Untuk endpoint mahal, rate limit global saja tidak cukup.

Jangan lupa idempotency. Endpoint payment, booking, dan order creation harus aman dari request berulang.

Sensitive business flow abuse

OWASP API Top 10 2023 memasukkan unrestricted access to sensitive business flows karena banyak API bisa disalahgunakan secara bisnis walaupun tidak terlihat seperti bug teknis.

Contoh:

• endpoint apply coupon dipanggil ribuan kali;
• endpoint register dipakai untuk spam account;
• endpoint checkout dipakai untuk scrape harga;
• endpoint booking dipakai untuk menahan slot;
• endpoint resend OTP dipakai untuk spam SMS;
• endpoint trial dipakai untuk abuse kuota.

Di sini auditor harus paham proses bisnis. Scanner tidak tahu bahwa satu endpoint bisa merugikan margin, inventory, reputasi, atau biaya operasional.

Detail pola seperti ini saya bahas di business logic vulnerability.

Webhook dan callback

Webhook sering menjadi titik paling rawan karena datang dari luar dan biasanya langsung mengubah status bisnis.

Audit webhook harus mengecek:

• signature verification;
• timestamp tolerance;
• replay protection;
• idempotency key;
• validasi source event;
• mapping invoice/order yang benar;
• status transition;
• raw payload logging yang aman;
• retry handling.

Payment callback tidak boleh otomatis membuat invoice paid hanya karena payload berisi status: paid. Aplikasi harus memverifikasi signature, mengambil status dari payment provider jika perlu, dan memastikan amount, currency, invoice ID, serta merchant account cocok.

SSRF lewat API

API yang menerima URL dari user perlu diuji untuk SSRF.

Contoh fitur berisiko:

• import from URL;
• fetch preview link;
• upload via remote URL;
• webhook test;
• screenshot website;
• PDF generator;
• crawler;
• integration connector.

Audit perlu mengecek apakah API bisa dipakai untuk mengakses metadata cloud, service internal, localhost, private IP range, atau endpoint admin internal. Blocklist sering mudah dilewati. Gunakan allowlist domain atau proxy fetch yang dibatasi.

Security misconfiguration

API misconfiguration biasanya terlihat dari hal-hal basic:

• CORS terlalu longgar;
• debug response aktif;
• stack trace bocor;
• Swagger public tanpa auth;
• GraphQL introspection terbuka di production;
• error menampilkan query atau path internal;
• admin API public;
• default credential;
• staging API memakai data production;
• security header tidak konsisten.

Misconfiguration sering dianggap low, tapi bisa naik severity jika memberi informasi untuk exploit lain.

Inventory management

Endpoint lama adalah sumber masalah yang sering diremehkan.

Audit harus mencari:

• versi API lama yang masih aktif;
• endpoint deprecated yang tidak lagi dites;
• environment dev/staging yang masih public;
• route experimental;
• API untuk mobile versi lama;
• mock endpoint yang lupa dimatikan;
• API partner yang token-nya tidak pernah diputar.

Setiap endpoint yang hidup harus punya owner, purpose, auth model, rate limit, dan logging.

Unsafe consumption of external APIs

Aplikasi sering memercayai API eksternal terlalu besar.

Contoh:

• response payment gateway dianggap benar tanpa verifikasi signature;
• data CRM masuk tanpa validasi schema;
• webhook partner bisa mengubah status internal;
• AI provider output langsung dieksekusi;
• file dari external URL langsung disimpan dan disajikan ke user;
• callback URL partner bisa diarahkan ke domain berbahaya.

Audit harus mengecek input dari pihak ketiga seperti mengecek input dari user. External API tetap bisa salah, kompromi, berubah format, atau disalahgunakan.

GraphQL perlu perlakuan khusus

Jika aplikasi memakai GraphQL, audit API tidak cukup dengan daftar endpoint REST.

Cek:

• introspection di production;
• query depth;
• query complexity;
• batching abuse;
• authorization per resolver;
• field-level data exposure;
• error message;
• file upload;
• rate limit berdasarkan cost, bukan jumlah request saja.

GraphQL bisa membuat satu request menjadi sangat mahal. Limit biasa per request sering tidak cukup.

Evidence yang harus ada di laporan

Finding API yang bagus harus menyertakan:

• endpoint dan method;
• role/token yang dipakai;
• request asli;
• response asli;
• object ID yang diuji;
• bukti akses tidak sah;
• impact data atau proses bisnis;
• rekomendasi fix;
• cara retest.

Jangan hanya menulis "BOLA ditemukan". Tunjukkan request user A, request user B, response yang membuktikan data lintas user, dan kontrol apa yang harus dipasang.

Untuk membaca laporan seperti ini, lihat cara membaca laporan pentest aplikasi.

Prioritas fix API

Urutan fix yang sehat:

1. Fix authorization bug yang membuka data atau fungsi lintas user/tenant.
2. Fix authentication bypass dan token lifecycle.
3. Lock webhook/payment callback.
4. Batasi endpoint mahal dan flow yang bisa diabuse.
5. Bersihkan endpoint lama, Swagger public, staging public, dan debug leak.
6. Tambahkan logging dan alert untuk request mencurigakan.

Jangan habiskan minggu pertama hanya mengejar header kalau API masih bisa membaca invoice tenant lain.

Kesimpulan

Pentest API harus memperlakukan API sebagai produk utama, bukan lapisan teknis di belakang UI.

Yang perlu diuji bukan hanya apakah endpoint error atau tidak. Yang perlu diuji adalah apakah endpoint memahami user, role, tenant, object, field, limit, dan workflow bisnis.

Kalau API aman, frontend jauh lebih mudah diamankan. Kalau API terlalu percaya client, tampilan sebagus apa pun hanya dekorasi.