Keamanan website sebelum peluncuran: apa yang perlu diperiksa?

Apa yang diperiksa sebelum website dibuka untuk umum?

Mulai dari akses, data, komponen yang dipakai, dan kemampuan memulihkan layanan. Jangan hanya menyerahkan alamat website beserta akun admin. Pemilik bisnis perlu mengetahui pekerjaan pengamanan yang selesai, bagian yang belum diuji, dan biaya pemeliharaan setelah serah terima.

Panduan ini berisi praktik teknis untuk dibahas bersama pengembang. Untuk ketentuan yang berlaku pada sistem Anda, baca kewajiban keamanan website dan aplikasi.

Apakah HTTPS berarti website sudah aman?

HTTPS memakai TLS untuk melindungi lalu lintas antara pihak yang terhubung. Perlindungan ini membantu mencegah isi komunikasi dibaca atau diubah di perjalanan. Namun, HTTPS tidak menentukan apakah akun pelanggan boleh melihat pesanan orang lain, apakah plugin rentan, atau apakah admin telah kehilangan akunnya.

Minta tim memeriksa seluruh alur penting, termasuk formulir, API, dan hubungan ke layanan lain. Sertifikat perlu diperpanjang; tentukan siapa yang menerima peringatan kedaluwarsa. Jangan menjadikan ikon koneksi aman sebagai bukti bahwa seluruh aplikasi lolos pemeriksaan.

Contoh sederhana tanpa perantara: browser pelanggan terhubung ke server website.

Saat data dikirim

TLS membantu menjaga kerahasiaan dan keutuhan komunikasi.

PengirimBrowser pelanggan

Mengirim permintaan melalui koneksi terenkripsi ke server yang diverifikasi.

Koneksi HTTPS→

PenerimaServer website

Menerima permintaan, lalu aplikasi memeriksa izin sebelum memberikan data.

Tetap periksa di aplikasi

Akun ini boleh membaca pesanan siapa? HTTPS tidak menentukan jawabannya.

Diagram disederhanakan. Jika memakai perantara seperti CDN, periksa juga perlindungan koneksi dari perantara ke server. Enkripsi saat pengiriman tidak sama dengan pengamanan data tersimpan.

Rujukan: OWASP Transport Layer Security Cheat Sheet · OWASP Authorization Cheat Sheet.

Bagaimana memeriksa CMS dan plugin?

CMS adalah perangkat lunak untuk mengelola isi website. Catat nama dan versi CMS, tema, plugin, serta komponen server yang menjadi tanggung jawab tim. Untuk setiap komponen, tulis sumber pembaruan, status dukungan, dan pemilik pekerjaannya.

Hapus komponen yang tidak diperlukan. Uji pembaruan pada lingkungan yang sesuai, siapkan pemulihan jika perubahan gagal, lalu periksa versi yang benar-benar berjalan. Menekan tombol pembaruan belum membuktikan semua server atau salinan aplikasi telah diperbarui.

Jika komponen sudah tidak didukung, putuskan penggantian atau penghentiannya. Penundaan memerlukan alasan, pembatasan sementara, penanggung jawab, dan tanggal peninjauan; jangan dibiarkan menjadi pengecualian tanpa akhir.

Apa peran WAF dan perlindungan DDoS?

WAF, atau web application firewall, menyaring permintaan ke aplikasi berdasarkan aturan. Ia dapat menjadi lapisan tambahan, tetapi tidak menggantikan perbaikan kode dan pembatasan akses data.

DDoS adalah gangguan layanan yang berasal dari banyak sumber. Beban berlebihan dapat mengenai jaringan maupun fungsi aplikasi yang mahal dijalankan. Karena itu, tanyakan bagian mana yang dilindungi, batas kapasitas atau biaya, siapa yang menerima peringatan, serta bagaimana layanan dipulihkan. Satu label “anti-DDoS” belum menjawab semuanya.

Perubahan aturan perlu diperiksa terhadap transaksi yang sah. Contohnya, aturan yang terlalu ketat bisa menolak unggahan pelanggan. Pengujian beban atau gangguan harus disepakati dengan pemilik sistem dan pihak penyedia yang terlibat.

Contoh catatan keputusan peluncuran

Berikut contoh fiktif untuk website pemesanan “Katalog Tim”, bukan hasil audit nyata.

Pemeriksaan	Bukti dan keputusan contoh
Akun admin	Bawa daftar pengguna, MFA, dan jalur pemulihan. Cabut akses akun pengembang sementara setelah serah terima.
Data pesanan	Bawa hasil pemeriksaan hak akses dua akun uji. Tunda peluncuran bila pesanan akun lain masih dapat dibuka.
Komponen	Bawa daftar versi dan hasil pembaruan. Plugin tanpa pemilik tidak dimasukkan ke produksi.
Pemulihan	Bawa catatan restore dan hasil pemeriksaan pesanan uji. Catat kekurangan sebelum menentukan kesiapan.
Operasional	Bawa kontak gangguan dan jadwal pemeliharaan. Pemilik layanan menyetujui pembagian tanggung jawab.

Lengkapi catatan dengan tanggal, versi yang diperiksa, nama pemeriksa, dan tautan bukti internal. Hasil yang belum diketahui harus tetap ditulis “belum diperiksa”.

Latihan: website sudah HTTPS, boleh langsung diluncurkan?

Gunakan situasi fiktif berikut dalam rapat dengan pengembang. Coba jawab sebelum membuka penjelasan.

HTTPS aktif, tetapi akun uji bisa melihat pesanan orang lain. Apa keputusannya?

Tunda pembukaan fitur yang terdampak sampai akses diperbaiki dan diuji ulang. Enkripsi koneksi tidak memperbaiki izin data. Minta bukti bahwa akun hanya mendapat pesanan yang boleh dibacanya.

Halaman depan memakai HTTPS. Apakah pemeriksaan koneksi sudah selesai?

Belum. Periksa juga login, formulir, API, dan koneksi ke layanan lain. Bila ada perantara seperti CDN, periksa pula koneksi dari perantara ke server aplikasi. Hasil pemeriksaan satu halaman tidak mewakili seluruh jalur.

Vendor menyerahkan akun admin, tetapi belum ada petugas pembaruan. Apa yang kurang?

Pembagian pekerjaan setelah peluncuran. Tentukan siapa memperbarui komponen, menerima peringatan sertifikat, dan menangani gangguan. Catat pekerjaan yang belum diperiksa beserta penanggung jawabnya sebelum menyetujui serah terima.

Apa yang dibawa saat serah terima?

Minta daftar aset dan kepemilikannya, prosedur pembaruan, cara mencabut akses vendor, serta catatan temuan yang masih terbuka. Simpan rahasia akses di sarana yang dibatasi, bukan di dokumen serah terima umum.

Gunakan checklist keamanan untuk rapat kesiapan dan checklist serah terima aplikasi untuk pembagian pekerjaan setelah proyek selesai.

Jika website berjalan di cloud, lengkapi keputusan peluncuran dengan matriks tanggung jawab infrastruktur. Untuk perubahan berikutnya, gunakan proses pengembangan yang aman.

Lengkapi pemeriksaan peluncuran dengan aksesibilitas alur pengguna, termasuk formulir, login, dan dokumen.

Jika website yang sudah berjalan diduga disusupi, gunakan langkah penanganan website diretas untuk pembatasan, pemeriksaan, dan pemulihan.

Pahami risiko di balik pemeriksaan

Baca Security Misconfiguration untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.

Pemeriksaan fitur terkait

Periksa security headers dan CSP sesuai kebutuhan halaman, termasuk alur formulir dan widget. Bila website menerima lampiran, tambahkan pemeriksaan upload, penyimpanan, dan izin unduh.