OWASP Top 10 adalah daftar risiko keamanan paling penting di aplikasi web, disusun dari data celah keamanan nyata dan survei praktisi keamanan. Klien, auditor, dan penetration tester sering memakainya sebagai checklist, sehingga tim development sering ditanya apakah aplikasinya sudah "sesuai OWASP". Daftar ini lebih berguna sebagai peta tempat aplikasi biasanya bermasalah. Panduan ini membahas edisi 2025 beserta contoh bagaimana setiap risiko muncul di aplikasi bisnis yang kami bangun dan kami review.
Daftar Edisi 2025 Secara Ringkas
| Kategori | Contoh kejadiannya | Pencegahan utama |
|---|---|---|
| A01 Broken Access Control | Mengganti ID di URL langsung menampilkan invoice pelanggan lain, atau user biasa bisa memanggil endpoint admin | Cek kepemilikan dan role di server untuk setiap request, tolak kalau tidak ada izin |
| A02 Security Misconfiguration | Mode debug menyala di production, password default, bucket storage terbuka, atau port database bisa diakses dari internet | Konfigurasi aman yang disimpan di kode dan direview, dengan pengaturan terpisah per environment |
| A03 Software Supply Chain Failures | Library usang yang punya celah keamanan, atau package yang sudah disusupi ikut masuk ke build | Lock file, scan dependency, dan jadwal update rutin |
| A04 Cryptographic Failures | Password disimpan dengan MD5, data sensitif dikirim lewat HTTP, atau key enkripsi ter-commit ke Git | Hashing password bawaan framework, HTTPS di semua tempat, key disimpan di secrets manager |
| A05 Injection | Query SQL disusun dengan menggabungkan string dari input user, atau teks user ditampilkan sebagai HTML | Parameterized query dan ORM, escaping output oleh template engine |
| A06 Insecure Design | Voucher yang bisa dipakai berkali-kali, atau OTP tanpa batas percobaan | Threat modelling untuk alur bisnis dan batasan yang dirancang sejak awal |
| A07 Authentication Failures | Login tanpa batas percobaan, reset password yang lemah, atau session yang tidak pernah kedaluwarsa | Rate limit, autentikasi multi-faktor untuk admin, pengelolaan session yang aman |
| A08 Software or Data Integrity Failures | Menerima webhook pembayaran tanpa mengecek signature, atau deploy build yang tidak ditandatangani | Verifikasi signature, amankan pipeline CI/CD, hindari deserialization yang tidak aman |
| A09 Security Logging and Alerting Failures | Pembobolan baru ketahuan berbulan-bulan kemudian karena login gagal dan error hak akses tidak pernah dicatat | Catat event keamanan di satu tempat dan pasang alert untuk pola yang tidak biasa |
| A10 Mishandling of Exceptional Conditions | Error yang membocorkan stack trace, atau kegagalan yang membuat transaksi setengah jadi dan user tetap punya akses | Tolak akses saat terjadi error, pakai transaksi database, tampilkan pesan error yang umum |
Dibandingkan edisi 2021, server-side request forgery (SSRF) sekarang masuk ke broken access control, risiko supply chain punya kategori sendiri, dan penanganan error jadi kategori baru di A10. Kategori pertama sudah bertahun-tahun ada di posisi teratas, dan justru kategori ini yang paling sulit ditemukan oleh scanner otomatis.
Broken Access Control Paling Butuh Perhatian
Framework sudah melindungi dari injection dan cross-site scripting secara default, asalkan dipakai sesuai caranya. Hak akses lain cerita, karena hanya kode Anda yang tahu bahwa invoice 1042 milik perusahaan A dan bahwa kepala cabang hanya boleh menyetujui refund sampai nominal tertentu. Setiap endpoint yang membaca atau mengubah data butuh pengecekan di server. Menyembunyikan tombol di tampilan tidak termasuk pengecekan. Di Laravel caranya dengan Policy, di Django dengan object-level permission di Django REST Framework, dan di Node.js dengan lapisan otorisasi bersama yang dilewati semua route.
- Ambil data lewat user atau tenant yang sedang login, misalnya $request->user()->orders()->findOrFail($id), sehingga ID milik tenant lain otomatis menghasilkan 404.
- Tulis test otomatis yang login sebagai user A lalu meminta data user B di setiap endpoint penting.
- Cek juga fitur download file dan export. Fitur ini sering ditambahkan belakangan dan terlewat dari pengecekan yang biasa.
- Blokir request dari server ke alamat internal dan endpoint metadata cloud kalau aplikasi mengambil URL yang dimasukkan user.
Konfigurasi dan Dependency
Salah konfigurasi dan komponen usang jadi penyebab banyak insiden yang kami temui di server yang sebenarnya tidak diserang dengan cara canggih. Simpan pengaturan production di kode atau di template yang direview, matikan output debug, hapus akun default, dan jadikan bucket storage private sebagai default. Jalankan composer audit, npm audit, atau pip-audit di CI, aktifkan Dependabot atau Renovate, dan sediakan jadwal rutin untuk update supaya tidak menumpuk sampai upgrade versi mayor terasa menakutkan.
Celah Desain yang Tidak Bisa Ditemukan Scanner
Insecure design berkaitan dengan aturan bisnis. Contohnya promo yang bisa dipakai dua kali dengan mengirim dua request di waktu yang sama, transfer yang tidak mengecek saldo di dalam transaksi database yang sama, atau OTP yang bisa ditebak karena tidak ada batas percobaan. Masalah seperti ini butuh sesi threat modelling singkat saat fitur dirancang. Tanyakan bagaimana user yang tidak jujur akan menyalahgunakan alur ini, lalu tambahkan batasan, lock, dan pengecekan sebelum kodenya ditulis.
Memasukkan Keamanan ke Proses Development
- 1Tambahkan checklist keamanan singkat berdasarkan Top 10 ke template pull request dan definition of done.
- 2Jalankan static analysis seperti SonarQube atau Semgrep dan scan dependency di setiap pull request.
- 3Tulis test hak akses untuk setiap endpoint yang menyentuh data pelanggan atau data keuangan.
- 4Scan aplikasi yang sedang berjalan dengan scanner dinamis seperti OWASP ZAP atau Qualys sebelum rilis besar.
- 5Catat login, kegagalan hak akses, dan aksi admin di satu tempat, lalu pasang alert untuk lonjakan yang tidak biasa.
- 6Lakukan penetration test oleh pihak luar minimal setahun sekali, atau sebelum meluncurkan sistem yang menangani pembayaran atau data pribadi.
Untuk aplikasi yang memproses data pribadi pengguna di Indonesia, praktik-praktik ini juga membantu memenuhi kewajiban keamanan di UU Pelindungan Data Pribadi (UU PDP). Catatan hasil scan, perbaikan, dan testing jadi bukti yang berguna ketika klien atau auditor bertanya bagaimana aplikasi Anda dilindungi.
Poin penting
- Pakai OWASP Top 10 sebagai peta tempat aplikasi biasanya bermasalah.
- Curahkan usaha terbesar untuk hak akses, dan uji dengan user dan ID yang nyata.
- Simpan konfigurasi di kode yang direview dan update dependency secara terjadwal.
- Cari celah penyalahgunaan aturan bisnis saat tahap desain, karena scanner tidak bisa menemukannya.
- Otomatiskan scan statis, dependency, dan dinamis, lalu catat event keamanan di satu tempat.
