OWASP Top 10 Dijelaskan untuk Pemilik Website

OWASP Top 10 adalah daftar sepuluh kategori risiko keamanan aplikasi web yang dianggap paling penting oleh OWASP (Open Worldwide Application Security Project), komunitas nirlaba di bidang keamanan aplikasi. Daftar ini diperbarui berkala berdasarkan data temuan dan survei praktisi. Per 6 November 2026, versi terbarunya adalah OWASP Top 10:2025.

Kenapa pemilik website perlu tahu? Karena kamu tidak harus bisa menulis kode untuk bertanya hal yang benar. Daftar ini memberi bahasa yang sama antara kamu, developer, dan penguji keamanan, sehingga pertanyaan "website kita aman tidak?" bisa diganti dengan pertanyaan yang lebih tajam.

Apa saja isi OWASP Top 10:2025?

Dua kategori terasa baru dibanding versi 2021. A03 memperluas kategori komponen usang menjadi seluruh rantai pasok perangkat lunak, dan A10 menyorot penanganan error. Urutan lain juga bergeser, misalnya salah konfigurasi naik ke posisi kedua.

Penjelasan tiap risiko dengan contoh

A01, kontrol akses rusak. Contoh klasik: pelanggan membuka /pesanan/1052, lalu mengganti angkanya menjadi 1053 dan bisa melihat pesanan orang lain. Aplikasi harus memeriksa hak akses di sisi server untuk setiap permintaan, bukan hanya menyembunyikan tombol.

A02, salah konfigurasi. Halaman error yang menampilkan detail server, folder backup yang bisa diunduh, panel admin yang terbuka ke publik, atau akun bawaan yang belum diganti. Masalah ini sering muncul bukan karena kode, tetapi karena pengaturan yang terlupakan.

A03, rantai pasok perangkat lunak. Website modern dibangun dari banyak komponen: plugin, tema, pustaka JavaScript, paket dari npm atau Composer. Satu komponen yang usang atau disusupi bisa membuka seluruh website. Pada WordPress, ini berarti plugin dan tema yang jarang di-update.

A04, kegagalan kriptografi. Kata sandi disimpan tanpa hashing yang kuat, data kartu atau KTP disimpan tanpa enkripsi, atau halaman login tanpa HTTPS.

A05, injeksi. Input dari formulir langsung dimasukkan ke query database atau perintah sistem. Termasuk di sini SQL injection dan cross-site scripting (XSS). Penjelasan lengkapnya ada di apa itu SQL injection dan cara menutup celahnya.

A06, desain tidak aman. Misalnya fitur reset kata sandi yang hanya bertanya "nama ibu kandung", atau kupon diskon yang bisa dipakai berulang tanpa batas. Kode yang rapi tidak menyelamatkan rancangan yang keliru.

A07, kegagalan autentikasi. Tidak ada batas percobaan login, kata sandi lemah diizinkan, tidak ada opsi verifikasi dua langkah, atau sesi tidak kedaluwarsa setelah logout.

A08, integritas perangkat lunak dan data. Aplikasi mengunduh pembaruan atau memuat skrip dari sumber luar tanpa memeriksa keasliannya, sehingga penyerang yang menguasai sumber itu bisa menyisipkan kode.

A09, pencatatan dan peringatan. Login gagal ratusan kali dan tidak ada yang tahu. Tanpa log dan peringatan, pembobolan bisa berlangsung lama sebelum disadari.

A10, penanganan kondisi luar biasa. Aplikasi yang, saat error, malah membuka akses, membocorkan informasi, atau meninggalkan transaksi setengah jadi. Prinsipnya: saat gagal, aplikasi harus gagal dengan aman.

Bagaimana memakai daftar ini tanpa jadi developer?

Jadikan OWASP Top 10 sebagai daftar pertanyaan. Beberapa contoh yang bisa kamu ajukan ke developer atau vendor website:

• Bagaimana aplikasi memastikan pengguna hanya bisa mengakses datanya sendiri?
• Kapan terakhir semua plugin, tema, dan pustaka diperbarui, dan siapa yang memantaunya?
• Apakah kata sandi pengguna disimpan dengan hashing modern seperti bcrypt atau Argon2?
• Apakah ada batas percobaan login dan opsi 2FA untuk admin?
• Apakah percobaan login gagal dan perubahan data penting tercatat di log?
• Apakah pernah dilakukan pengujian keamanan, dan apa hasilnya?

Jawaban yang mengambang adalah sinyal untuk menggali lebih dalam. Kamu juga bisa meminta pertanyaan-pertanyaan ini dimasukkan ke kontrak pengembangan, sehingga vendor sejak awal tahu standar keamanan yang kamu harapkan dan bagaimana hasilnya akan diuji sebelum serah terima. Untuk pemilik WordPress, langkah dasarnya dirangkum di keamanan WordPress dasar.

Apakah WAF bisa menutup semua risiko ini?

Tidak semuanya. Web Application Firewall bagus untuk menahan pola serangan yang dikenal, terutama injeksi dan pemindaian otomatis. Aturan seperti OWASP Core Rule Set dirancang untuk itu, dan cara memasangnya ada di ModSecurity dengan OWASP CRS.

Tetapi WAF tidak tahu logika bisnismu. Ia tidak bisa membedakan apakah pengguna A berhak membuka pesanan nomor 1053 (A01) atau apakah alur kupon dirancang dengan benar (A06). Risiko seperti itu harus diperbaiki di aplikasi. Untuk mulai menguji sendiri, alat gratis seperti OWASP ZAP bisa dipakai, dengan catatan hanya pada website milikmu.