Audit keamanan aplikasi dengan standard pentest: apa saja yang wajib dicek

Banyak aplikasi kelihatan normal dari luar. Login jalan. Dashboard kebuka. Checkout bisa dipakai. API responsif. Tapi itu belum berarti aman.

Masalah keamanan biasanya muncul di tempat yang jarang dites oleh QA biasa: user bisa melihat data tenant lain, reset password bisa ditebak, endpoint admin masih hidup, object storage terlalu public, webhook bisa dipalsukan, atau proses pembayaran bisa diputar lewat request API.

Audit keamanan aplikasi yang benar bukan sekadar menjalankan scanner lalu mengirim PDF. Scanner membantu, tapi standard pentest yang serius harus mengecek cara aplikasi berpikir: siapa boleh melakukan apa, data apa yang keluar, endpoint mana yang terlalu percaya input, dan proses bisnis mana yang bisa disalahgunakan.

Artikel ini saya susun sebagai peta utama. Kalau Anda butuh bagian yang lebih spesifik, baca juga:

• Pentest API aplikasi modern
• Audit login, session, dan access control
• Business logic vulnerability
• Cara membaca laporan pentest aplikasi

Audit, vulnerability scan, dan pentest itu beda

Vulnerability scan adalah pemeriksaan otomatis. Tool mencari signature, CVE, header yang kurang, dependency rentan, port terbuka, atau konfigurasi yang sudah punya pola jelas. Ini berguna untuk baseline, tapi tidak cukup.

Security audit lebih luas. Audit melihat kontrol keamanan, konfigurasi, arsitektur, flow data, code path tertentu, deployment, logging, dan bukti bahwa kontrol tersebut benar-benar bekerja.

Pentest adalah simulasi serangan dalam scope yang disepakati. Tujuannya bukan sekadar menulis daftar kelemahan, tetapi membuktikan apakah kelemahan itu bisa dieksploitasi dan apa dampaknya ke bisnis.

Banyak bisnis minta "pentest", padahal yang mereka butuhkan pertama kali adalah audit readiness. Kalau fondasinya masih berantakan, pentest akan penuh temuan basic: debug mode aktif, endpoint admin tanpa proteksi cukup, CORS terlalu longgar, password reset lemah, dan bucket file kebuka.

Standard yang layak dipakai

Rujukan paling sehat untuk audit aplikasi adalah kombinasi beberapa standar, bukan satu checklist tunggal.

OWASP Web Security Testing Guide cocok dipakai sebagai peta cara menguji aplikasi web dan web service. Area yang dibahas mencakup information gathering, configuration, identity, authentication, authorization, session management, input validation, error handling, cryptography, business logic, client-side testing, dan API.

OWASP ASVS cocok dipakai sebagai baseline requirement. ASVS menjawab pertanyaan: kontrol keamanan apa yang seharusnya ada di aplikasi? Versi stabil terbaru yang dirilis OWASP adalah ASVS 5.0.0. Untuk audit serius, rujuk requirement dengan versi, bukan hanya menyebut "sesuai OWASP".

OWASP Top 10 berguna untuk prioritas risiko umum. Ini bagus untuk awareness, tapi jangan dipakai sebagai satu-satunya checklist pentest.

Kalau aplikasi punya API, mobile backend, headless frontend, payment callback, webhook, atau integrasi partner, pakai juga OWASP API Security Top 10 2023. Kalau ada mobile app, gunakan OWASP MASVS. Kalau aplikasi punya AI assistant, RAG, agent, atau tool-calling, masukkan risiko dari OWASP Top 10 for LLM/GenAI.

Untuk alur kerja auditnya sendiri, NIST SP 800-115 masih relevan sebagai kerangka: planning, execution, analysis, dan mitigation.

Scope audit harus jelas dulu

Audit yang kacau biasanya dimulai dari scope yang kabur.

Sebelum test teknis, petakan dulu:

• domain utama, subdomain, staging, dev, admin panel, dan legacy host;
• API endpoint, termasuk endpoint lama yang masih hidup;
• role user: guest, customer, staff, admin, superadmin, partner, vendor;
• data sensitif: PII, invoice, payment record, token, file upload, dokumen internal;
• integrasi pihak ketiga: payment gateway, email, WhatsApp, SSO, object storage, analytics, CRM;
• exposure infrastruktur: source map, backup file, debug route, health check, metrics, bucket/CDN path.

Asset inventory bukan formalitas. Kalau endpoint tidak terdaftar, biasanya endpoint itu juga tidak punya kontrol yang konsisten.

Authentication: jangan cuma cek bisa login

Login aman bukan cuma password benar atau salah.

Audit authentication harus mengecek apakah credential hanya dikirim lewat HTTPS, apakah ada default admin yang belum diganti, apakah login punya rate limit, apakah pesan error membocorkan account enumeration, dan apakah reset password dirancang dengan benar.

Reset password sering lebih berbahaya daripada form login. Token reset harus cukup random, punya expiry pendek, single-use, tidak bocor ke log, dan tidak bisa dipakai untuk user lain. Kalau ada MFA, audit juga proses enrollment, reset MFA, backup code, dan kemungkinan downgrade attack.

Jika aplikasi memakai OAuth atau SSO, audit redirect URI, state parameter, token audience, issuer, account linking, dan cara aplikasi menangani email yang sama dari provider berbeda.

Bagian ini saya pecah lebih detail di audit login, session, dan access control.

Authorization: bagian yang paling sering mahal

Authorization menjawab pertanyaan: user ini boleh melakukan aksi ini terhadap object ini atau tidak?

Di banyak aplikasi, bug mahal muncul karena authorization hanya dicek di UI. Tombol admin disembunyikan, tapi endpoint tetap menerima request. Menu billing tidak terlihat, tapi API invoice masih bisa dipanggil dengan ID yang ditebak.

Audit access control harus mengecek:

• IDOR atau BOLA: user A bisa membaca atau mengubah data user B hanya dengan mengganti ID;
• horizontal privilege escalation: customer bisa akses data customer lain;
• vertical privilege escalation: user biasa bisa menjalankan fungsi admin;
• RBAC dan permission matrix: role jelas atau hanya if/else tersebar;
• multi-tenant isolation: data antar client/org benar-benar terpisah;
• object property authorization: field sensitif tidak bisa dibaca/diubah sembarangan;
• workflow permission: user tidak bisa approve dirinya sendiri atau lompat status.

Authorization tidak boleh dipercaya dari frontend. Endpoint harus menolak request yang tidak berhak walaupun request itu dibuat manual dari API client.

Session dan token lifecycle

Token yang panjang bukan otomatis aman. Yang penting adalah lifecycle.

Audit session harus melihat cookie flags seperti HttpOnly, Secure, dan SameSite; risiko session fixation; apakah logout benar-benar mencabut session; bagaimana refresh token diputar; dan apakah session bisa dikelola per device.

Jika memakai JWT, cek expiry, issuer, audience, signature validation, algorithm, dan key rotation. JWT yang tidak bisa dicabut butuh desain expiry dan refresh yang disiplin. Kalau token disimpan di localStorage, risiko XSS harus diperlakukan lebih serius.

Untuk flow cookie-based auth, CSRF masih relevan. Jangan hilangkan CSRF protection hanya karena API terasa modern.

Input validation, injection, dan output handling

Area klasik tetap penting karena dampaknya bisa langsung fatal.

Yang layak diaudit:

• SQL injection, NoSQL injection, dan ORM query injection;
• command injection;
• SSRF;
• XSS reflected, stored, dan DOM-based;
• server-side template injection;
• path traversal dan file inclusion;
• unsafe XML parsing;
• insecure deserialization;
• mass assignment;
• prototype pollution untuk JavaScript stack;
• host header injection atau request smuggling jika arsitektur proxy relevan.

Jangan bahas injection sebagai daftar nama serangan saja. Auditor harus mengikuti alur input: data masuk dari mana, diproses oleh apa, disimpan di mana, keluar ke response apa, dan impact bisnisnya apa.

API security

API sering lebih jujur daripada UI. Kalau UI terlihat aman tapi API terlalu percaya client, celahnya tetap terbuka.

Audit API harus dimulai dari inventory. Endpoint mana yang terdokumentasi? Endpoint mana yang muncul dari traffic mobile app atau frontend bundle? Endpoint lama masih hidup atau sudah ditutup? Versi API mana yang masih menerima request?

Setelah itu baru masuk ke kontrol utama: BOLA, broken authentication, broken object property authorization, unrestricted resource consumption, broken function level authorization, sensitive business flow abuse, SSRF, misconfiguration, inventory management, dan cara aplikasi mengonsumsi API eksternal.

Webhook juga wajib diuji. Payment callback atau integration callback harus punya signature verification, timestamp tolerance, replay protection, dan idempotency.

Saya bahas checklist API lebih dalam di pentest API aplikasi modern.

Business logic

Business logic bug jarang ditemukan scanner, karena scanner tidak tahu aturan bisnis.

Contohnya:

• harga checkout bisa dimanipulasi dari client;
• coupon bisa dipakai berkali-kali atau ditumpuk sampai harga negatif;
• subscription bisa di-downgrade tapi akses premium tetap aktif;
• wallet bisa double spend karena race condition;
• booking bisa double booking;
• quota bisa direset lewat endpoint lain;
• payment callback bisa memalsukan invoice paid;
• invite role bisa membuat user biasa menjadi admin.

Bug seperti ini sering lebih mahal daripada header security yang kurang. Bukan karena header tidak penting, tetapi karena business logic langsung menyentuh uang, akses, stok, approval, dan data customer.

Artikel khususnya ada di Business logic vulnerability.

File upload, storage, dan CDN

Upload file terlihat sederhana, tapi permukaannya lebar.

Audit harus mengecek validasi extension dan MIME type, content sniffing, upload script/executable, path traversal pada nama file, file overwrite, public bucket, signed URL expiry, malware scanning, metadata leak, dan kemungkinan enumerate file sensitif lewat path CDN.

Kalau aplikasi menerima dokumen user, audit juga apakah file bisa dibuka publik tanpa auth. Banyak data leak bukan dari database, tetapi dari storage yang permission-nya terlalu longgar.

Data protection dan privacy

Data sensitif tidak boleh bocor lewat response API, log, cache, analytics, export, atau dashboard internal.

Cek apakah password, token, OTP, session ID, payment detail, dan dokumen pribadi pernah masuk log. Cek juga apakah export CSV/Excel menghormati tenant boundary. Untuk admin panel, data sensitif sebaiknya dimasking sesuai kebutuhan kerja, bukan dibuka penuh ke semua staff.

Encryption at rest penting untuk data tertentu, tapi jangan jadikan kata "encrypted" sebagai obat semua masalah. Kalau aplikasi tetap mengirim data sensitif ke user yang salah, encryption tidak menolong.

Cryptography dan transport security

Audit bagian ini mencakup TLS, HSTS, password hashing, random number generation, key management, secret rotation, dan hardcoded secret.

Password harus memakai algoritma password hashing seperti Argon2, bcrypt, atau scrypt, bukan hash cepat seperti SHA-256 biasa. Token reset, OTP, invite code, dan API key harus dibuat dari random source yang aman.

Base64 bukan encryption. Encoding hanya mengubah bentuk data, bukan melindunginya.

Configuration dan deployment

Temuan basic di production masih sering terjadi:

• debug mode aktif;
• stack trace bocor;
• CORS terlalu longgar;
• security header tidak ada;
• source map publik berisi source path atau informasi internal;
• file .env, .git, backup zip, atau SQL dump bisa diakses;
• admin panel terbuka tanpa allowlist atau MFA;
• subdomain takeover;
• dependency dan runtime terlalu tua.

Bagian ini terlihat membosankan, tapi sering menjadi pintu masuk untuk serangan yang lebih besar.

Logging, monitoring, dan incident readiness

Audit tidak selesai hanya karena celah ditemukan. Aplikasi juga harus bisa mendeteksi kejadian buruk.

Log harus mencatat event penting: login gagal, access denied, role change, payment callback, export data, reset password, MFA reset, dan perubahan permission. Tapi log tidak boleh menyimpan password, token, OTP, atau detail pembayaran sensitif.

Alert perlu dibuat untuk brute force, privilege escalation attempt, export tidak biasa, webhook failure, dan perubahan admin yang mencurigakan.

Tanpa log yang benar, incident response cuma tebak-tebakan.

Dependency, supply chain, dan CI/CD

Audit modern harus menyentuh supply chain.

Cek package outdated, dependency vulnerable, lockfile, package abandoned, typosquatting, secret scanning, CI/CD token permission, build artifact yang membawa file sensitif, container base image, dan permission deployment.

Untuk level enterprise, SBOM bisa dimasukkan. Tapi untuk banyak tim, langkah pertama yang lebih realistis adalah dependency update rutin, secret scanning, dan pembatasan token CI/CD.

Mobile dan AI jika relevan

Kalau aplikasi punya mobile app, audit jangan berhenti di backend. Mobile punya risiko penyimpanan data sensitif di device, deep link, WebView, certificate validation, reverse engineering, tampering, dan permission privacy. OWASP MASVS adalah rujukan yang tepat untuk area ini.

Kalau aplikasi punya AI assistant, RAG, agent, atau tool-calling, audit juga prompt injection, data leakage, tool abuse, output handling, system prompt leakage, excessive agency, dan cost abuse. Fitur AI yang bisa menjalankan aksi bisnis harus punya batas dan human approval untuk aksi sensitif.

Risk rating harus operasional

Saya tidak menyarankan owner bisnis membaca laporan pentest hanya dari skor CVSS. CVSS berguna, tapi keputusan perbaikan harus melihat impact bisnis.

Gunakan matrix sederhana:

• Critical: account takeover, akses data sensitif lintas tenant, payment bypass, RCE, secret production leak.
• High: akses fungsi admin tertentu, data exposure terbatas tapi nyata, auth bypass sebagian, SSRF internal terbatas.
• Medium: misconfiguration yang butuh kondisi tambahan, weak rate limit, error leak yang membantu chaining.
• Low: hardening issue, header kurang, disclosure minor.

Severity bukan ditentukan dari nama bug yang terdengar keren. Severity ditentukan oleh impact, exploitability, data yang terkena, dan apakah bug bisa dirangkai dengan bug lain.

Untuk membaca laporan dan menentukan prioritas fix, lihat cara membaca laporan pentest aplikasi.

Output audit yang profesional

Laporan audit yang benar harus berisi:

• scope dan batasan testing;
• executive summary;
• methodology dan standard rujukan;
• finding teknis per temuan;
• evidence: request/response, screenshot, timestamp, affected endpoint;
• steps to reproduce;
• impact bisnis;
• risk rating;
• rekomendasi fix;
• owner perbaikan;
• retest status.

Laporan yang hanya berisi daftar CVE tanpa konteks perbaikan tidak membantu tim bergerak.

Batas etika dan legal

Pentest harus punya izin tertulis. Scope harus jelas. Jangan menjalankan test destructive di production tanpa agreement. Jangan copy atau exfiltrate data nyata kecuali disepakati dan diminimalkan. Jangan mengejar exploit yang bisa merusak availability hanya untuk membuktikan poin.

Audit keamanan yang bagus bukan yang paling agresif. Audit yang bagus adalah yang menemukan risiko nyata, memberi bukti cukup, dan membantu tim memperbaikinya tanpa merusak operasi.

Kesimpulan

Audit keamanan aplikasi dengan standard pentest harus melihat aplikasi sebagai sistem bisnis, bukan sekadar kumpulan endpoint.

Scanner bisa menemukan sebagian masalah. Checklist OWASP bisa memberi struktur. Tapi auditor tetap harus memahami flow aplikasi: user, role, data, payment, approval, file, integrasi, dan log.

Kalau Anda baru mulai, jangan langsung mengejar semua area sekaligus. Mulai dari scope, authentication, authorization, API, business logic, dan data protection. Setelah itu baru masuk ke mobile, AI, supply chain, dan maturity proses.

Keamanan aplikasi bukan satu kali PDF. Yang benar adalah siklus: audit, fix, retest, monitor, lalu ulangi saat aplikasi berubah.