Panduan

Cara Audit Keamanan Website Sendiri, dengan Urutan yang Benar

Audit keamanan bukan soal menjalankan pemindai lalu mengirim PDF. Urutannya salah, hasilnya cuma daftar alarm palsu. Ini urutan yang kami pakai saat memeriksa aplikasi klien.

← Semua artikel

1. Kunci dulu cakupannya

Tanpa cakupan tertulis, audit berubah jadi pengujian tanpa ujung. Tuliskan empat hal: daftar domain dan subdomain, aplikasi yang diuji, apakah source code boleh dibaca, dan jam pengujian. Tentukan juga apa yang tidak boleh disentuh, misalnya data pelanggan asli atau integrasi pembayaran produksi.

Kalau ada staging, uji di sana. Kalau hanya ada produksi, batasi diri ke tindakan non-destruktif: tidak menghapus data, tidak mengunci akun orang lain, tidak menjalankan uji beban.

2. Petakan permukaan serangan sebelum menyerang apa pun

Sebagian besar kebocoran datang dari aset yang lupa didaftarkan, bukan dari halaman utama. Yang perlu dipetakan:

• Subdomain, termasuk yang lama dan yang mengarah ke layanan pihak ketiga.
• Endpoint API: cari di bundle JavaScript, dokumentasi, dan riwayat git.
• Alamat email di halaman kontak, arsip publik, atau kebocoran data yang pernah terjadi.
• File dan direktori yang tidak pernah ditautkan: /.env, /backup.sql, /.git/, panel admin, halaman debug.
• Layanan pihak ketiga yang menyimpan data: form, CRM, penyimpanan berkas.

Untuk tahu subdomain apa saja yang publik, sertifikat TLS yang diterbitkan untuk domain kamu bisa dibaca siapa saja. Kalau ada subdomain lama yang masih hidup, itu masuk cakupan.

3. Periksa kontrol akses lebih dulu

Kalau hanya ada waktu untuk satu kategori pengujian, pilih yang ini. Kesalahan otorisasi adalah penyebab paling sering kebocoran data pelanggan. Caranya sederhana dan tidak butuh alat mahal:

1. Buat dua akun dengan hak berbeda, misalnya akun biasa dan akun admin.
2. Catat setiap ID yang muncul di URL atau isi request: nomor pesanan, ID pengguna, nomor dokumen.
3. Ganti ID itu dengan milik akun lain, lalu lihat apakah data tetap terbuka.
4. Ulangi untuk setiap metode: baca, ubah, hapus. Banyak sistem memblokir pembacaan tapi lupa menutup penghapusan.

Kesalahan yang sama sering muncul di level API, bukan di tampilan. Jadi uji langsung ke API-nya, bukan hanya lewat tombol di layar.

4. Login, sesi, dan pemulihan akun

Yang diperiksa: umur token, apakah logout benar-benar mematikan sesi di sisi server, batas percobaan login, dan alur lupa password. Alur pemulihan sering jadi pintu belakang: token reset yang tidak kedaluwarsa, tautan yang bisa dipakai berkali-kali, atau jawaban pertanyaan keamanan yang bisa ditebak.

5. Penanganan input

Uji injeksi secara sistematis: SQL, perintah sistem, template, dan pemuatan berkas berbahaya. Untuk setiap parameter, kirim tiga hal: nilai normal, nilai yang memaksa error, dan nilai yang keluar dari batas yang diharapkan. Baca pesan error yang muncul, karena sering membocorkan struktur sistem.

6. Logika bisnis

Bagian ini tidak bisa ditemukan pemindai otomatis, dan justru paling sering merugikan. Contoh yang nyata terjadi: kupon dipakai berkali-kali, jumlah pesanan diubah jadi negatif, stok dikunci lalu dilepas, atau langkah verifikasi pembayaran dilewati dengan memanggil endpoint langsung.

Cara mengujinya: tulis alur normal sebagai daftar langkah, lalu coba setiap langkahnya dalam urutan yang salah, dua kali, atau dilewati.

7. Konfigurasi dan kebersihan server

Pemeriksaan cepat yang sering terlewat: header keamanan, sertifikat TLS dan versi protokolnya, direktori yang bisa didaftar isinya, panel admin yang terbuka ke internet, akun bawaan dengan password default, dan versi komponen yang sudah usang.

8. Pisahkan temuan nyata dari alarm palsu

Sebelum menulis laporan, setiap temuan harus punya tiga hal: bukti reproduksi langkah demi langkah, dampak nyata (data apa yang bisa diambil, atau tindakan apa yang bisa dilakukan penyerang), dan skor keparahan yang bisa dipertanggungjawabkan. Temuan tanpa bukti reproduksi sebaiknya tidak masuk laporan akhir; masukkan ke lampiran sebagai dugaan yang belum terbukti.

Yang perlu kamu siapkan sebelum mulai

• Perjanjian tertulis soal cakupan dan jam pengujian.
• Email dan nomor kontak yang bisa dihubungi bila pengujian memicu alarm.
• Hak akses ke staging atau akun uji. Tanpa ini, separuh pengujian tidak mungkin dilakukan.
• Tempat menyimpan bukti yang tidak bercampur dengan dokumen lain.
• Tenggat laporan dan kesepakatan siapa yang memutuskan prioritas perbaikan.

Semua ini bisa dikerjakan sendiri kalau kamu punya waktu dan akses penuh ke sistem. Yang tidak bisa digantikan hanyalah sudut pandang penyerang: orang yang tidak tahu cara sistem itu seharusnya bekerja, sehingga ia mencoba hal-hal yang tidak terpikirkan oleh pembuatnya.

Pertanyaan yang sering muncul

Baca juga