# Keamanan website sebelum peluncuran: apa yang perlu diperiksa?
Sumber diperiksa. Metode: https://kompli.id/metodologi/.
Website siap diluncurkan ketika tim mengetahui bagian yang sudah diperiksa, risiko yang masih terbuka, dan siapa yang menanganinya. HTTPS atau WAF saja belum cukup.
URL kanonis: https://kompli.id/panduan/keamanan/keamanan-website-sebelum-peluncuran/
Sumber diakses: 2026-09-29
Diperbarui: 2026-09-30
Penulis: Kompli
Sumber diperiksa: 2026-09-30
## 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](/panduan/keamanan/kewajiban-keamanan-website-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.
**HTTPS melindungi koneksi, izin data diperiksa aplikasi**
Contoh sederhana tanpa perantara: browser pelanggan terhubung ke server website.
**Saat data dikirim**
TLS membantu menjaga kerahasiaan dan keutuhan komunikasi.
- **Browser pelanggan (Pengirim):** Mengirim permintaan melalui koneksi terenkripsi ke server yang diverifikasi.
- **Server website (Penerima):** Menerima permintaan, lalu aplikasi memeriksa izin sebelum memberikan data.
Alur: Browser pelanggan → Server website. Koneksi HTTPS.
**Tindak lanjut**
- **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](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html); [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html).
## 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](/template/checklist-keamanan-website-aplikasi/) untuk rapat kesiapan dan [checklist serah terima aplikasi](/template/checklist-serah-terima-aplikasi/) untuk pembagian pekerjaan setelah proyek selesai.
Jika website berjalan di cloud, lengkapi keputusan peluncuran dengan [matriks tanggung jawab infrastruktur](/panduan/keamanan/keamanan-cloud-dan-infrastruktur/). Untuk perubahan berikutnya, gunakan [proses pengembangan yang aman](/panduan/keamanan/pengembangan-aplikasi-yang-aman/).
Lengkapi pemeriksaan peluncuran dengan [aksesibilitas alur pengguna](/panduan/operasional-digital/aksesibilitas-website-aplikasi/), termasuk formulir, login, dan dokumen.
Jika website yang sudah berjalan diduga disusupi, gunakan [langkah penanganan website diretas](/panduan/keamanan/website-diretas/) untuk pembatasan, pemeriksaan, dan pemulihan.
## Pahami risiko di balik pemeriksaan
Baca [Security Misconfiguration](/panduan/owasp/security-misconfiguration/) untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.
## Pemeriksaan fitur terkait
Periksa [security headers dan CSP](/panduan/owasp/security-headers-dan-csp/) sesuai kebutuhan halaman, termasuk alur formulir dan widget. Bila website menerima lampiran, tambahkan [pemeriksaan upload, penyimpanan, dan izin unduh](/panduan/owasp/keamanan-upload-file/).
## Sumber rujukan
- [OWASP — Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) — Introduction; pemeriksaan izin tetap diperlukan meskipun koneksi terenkripsi
- [OWASP — Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) — Introduction; gunakan TLS dengan memahami batas perlindungannya
- [OWASP — Denial of Service Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) — Fundamentals, Application attacks, Network attacks; perlindungan berlapis terhadap gangguan layanan
- [NIST SP 800-40 Rev. 4 — Enterprise Patch Management Planning](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf) — Bagian 2–3; inventaris, pembaruan, verifikasi, serta perangkat lunak yang tidak dapat diperbarui
## Jalur belajar: Website dan aplikasi
Materi berikutnya: [Pahami batas akses data melalui API](https://kompli.id/panduan/keamanan/keamanan-api-akses-data/)
[Lihat urutan belajar](https://kompli.id/belajar/#website-dan-aplikasi)
## Perlu membahas kebutuhan tim Anda?
Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.
[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=keamanan)
## Bacaan terkait
- [Checklist keamanan website dan aplikasi](https://kompli.id/template/checklist-keamanan-website-aplikasi/)
- [Keamanan API: akses pengguna, tenant, token, dan batas penggunaan](https://kompli.id/panduan/keamanan/keamanan-api-akses-data/)
- [Mengelola kerentanan dan patch: prioritas, penanggung jawab, dan bukti](https://kompli.id/panduan/keamanan/mengelola-kerentanan-dan-patch/)