Mengapa Ujian Penembusan API Penting untuk Organisasi Anda

Mengapa pentest API memerlukan tumpuan berasingan

Dahulu, pengujian aplikasi web meliputi 'segala-galanya' kerana logik tertumpu di pelayan dan output adalah HTML. Hari ini, aplikasi moden membahagikan logik antara klien (React, mobile) dan API backend yang berkomunikasi dalam JSON. Permukaan serangan API kini boleh menjadi 5–10 kali lebih besar daripada UI yang menggunakannya.

Lebih kompleks, API kerap dipanggil oleh lebih daripada satu klien — aplikasi web, aplikasi mobile, integrasi rakan kongsi, sistem dalaman. Setiap klien mungkin mempunyai keperluan authentication yang berbeza, dan kawalan yang munasabah untuk satu klien mungkin tidak cukup untuk yang lain.

Pentest API yang baik mendekati API sebagai produk berasingan dengan model ancaman tersendiri. Ia menguji setiap endpoint dengan setiap peranan, mencuba senario unauthorized, terutamanya cuba untuk membaca atau mengubah data yang tidak sepatutnya boleh diakses oleh pemanggil.

OWASP API Top 10: panduan ringkas

OWASP API Security Top 10 adalah standard rujukan untuk pentest API. Berbeza daripada OWASP Web Top 10 yang menekankan injection dan XSS, versi API menekankan authorization dan pendedahan data.

• API1 Broken Object Level Authorization (BOLA) — yang paling biasa; pengguna A baca data pengguna B.
• API2 Broken Authentication — token boleh diteka, JWT tanpa pengesahan signature.
• API3 Broken Object Property Level Authorization — medan sensitif boleh diubah melalui mass assignment.
• API4 Unrestricted Resource Consumption — tiada rate limit, kos cloud meledak.
• API5 Broken Function Level Authorization — endpoint admin boleh dipanggil pengguna biasa.
• API6 Unrestricted Access to Sensitive Business Flows — automation abuse pada checkout atau pendaftaran.
• API7 Server Side Request Forgery (SSRF) — endpoint menerima URL daripada pengguna.
• API8 Security Misconfiguration — CORS terlalu longgar, debug routes terdedah.
• API9 Improper Inventory Management — endpoint v1 lama masih hidup dan rentan.
• API10 Unsafe Consumption of APIs — backend memanggil API pihak ketiga tanpa validasi.

REST vs GraphQL: perbezaan pentest

API REST tradisional mempunyai endpoint diskret seperti GET /users/123 atau POST /orders. Pentest REST melibatkan enumerasi setiap endpoint, mencuba kaedah HTTP berbeza, dan menguji authorization pada setiap satu. Alat seperti Postman, Burp Suite dan ffuf adalah kawan baik.

GraphQL, sebaliknya, mempunyai satu endpoint (biasanya /graphql) yang menerima query yang menentukan apa yang pengguna inginkan. Ini mengubah model ancaman secara mendasar. Penguji perlu menyemak introspection (sama ada skema didedahkan), kedalaman query (untuk DoS), batching (untuk memintas rate limit), dan resolver-level authorization.

Banyak organisasi mengaktifkan GraphQL introspection dalam produksi 'untuk kemudahan pembangun'. Ini setara dengan mendedahkan peta lengkap API kepada penyerang. Pentest GraphQL hampir selalu mendapati ini sebagai penemuan medium-high.

Peranan Swagger dan Postman dalam scoping

Pentest API tanpa dokumentasi adalah seperti memetakan bandar tanpa peta — boleh dilakukan, tetapi sangat tidak cekap. Penguji akan menghabiskan separuh masa engagement hanya mencari endpoint. Sediakan OpenAPI/Swagger spec atau Postman collection sebagai sebahagian daripada onboarding pentest.

Dokumentasi yang lengkap merangkumi: senarai semua endpoint, kaedah HTTP yang disokong, parameter (path, query, body), authentication yang diperlukan, dan contoh permintaan/respons. Bagi GraphQL, sediakan skema lengkap atau benarkan introspection dalam persekitaran ujian.

Penguji juga akan mengesahkan dokumentasi terhadap realiti — biasanya menjumpai endpoint 'tidak didokumentasikan' yang masih hidup. Inilah salah satu nilai pentest: bukan sekadar menguji yang anda tahu wujud, tetapi menemui yang anda lupa wujud.

Konteks open banking dan BNM

Bank Negara Malaysia telah mempromosikan rangka kerja open API untuk perbankan, dengan piawaian seperti BNM Open API specification untuk perkongsian data dan inisiasi pembayaran. Bagi institusi kewangan, ini bermaksud beratus endpoint API baharu yang menghadap rakan kongsi luaran (fintech, agregator).

Setiap endpoint dalam ekosistem ini perlu diuji dengan teliti. RMiT secara eksplisit menjangkakan pengujian keselamatan API sebagai sebahagian daripada lifecycle pembangunan. Penemuan API yang tidak diuruskan boleh menjadi vektor pelanggaran data atau penipuan pembayaran berskala.

Bagi fintech yang membina di atas API bank, ujian keselamatan dua hala adalah penting: API anda sendiri (yang didedahkan kepada pelanggan) dan integrasi anda dengan API bank (yang anda mengkonsumi). Pentest yang berkualiti meliputi kedua-dua arah.

Penemuan kritikal yang berulang

Berdasarkan engagement API yang kami jalankan, BOLA terus mendominasi senarai penemuan. Sebab utama: pembangun mengandaikan bahawa jika UI mencegah pengguna A daripada melihat data pengguna B, API juga selamat. Sebaliknya, API dipanggil terus melalui Burp atau Postman tanpa UI sebagai pengantara.

Penemuan biasa kedua adalah JWT yang tidak disahkan dengan betul: algoritma 'none' diterima, kunci secret lemah, atau header alg dipercayai daripada token (klasik). Penemuan ketiga ialah rate limit yang dilaksanakan di reverse proxy tetapi boleh dilangkau dengan menukar header X-Forwarded-For.

Akhir sekali, kebocoran data dalam respons error. Banyak API mengembalikan stack trace lengkap, query SQL, atau metadata struktur pangkalan data apabila ralat berlaku. Ini memberi peta dalaman aplikasi kepada penyerang.