Ada satu sifat yang bikin pengerasan situs beda dari kerjaan lain. Gagalnya diam.
Header keamanan yang salah nggak nampilin pesan error ke pengunjung. Tombol berhenti jalan, gambar nggak muncul, pembayaran gagal. Dan satu-satunya jejaknya ada di konsol browser yang nggak pernah dibuka siapa pun.
Makanya urutannya penting, dari yang paling aman ke yang paling berisiko.
1. TLS dulu, dan pilih berdasarkan siapa yang keputus
Pertanyaannya bukan "seberapa aman", tapi siapa yang keputus.
| Profil | Yang keputus |
|---|---|
| TLS 1.3 doang | Windows 7 dan 8, Android 9 ke bawah, sebagian mesin EDC |
| TLS 1.2 + 1.3 | Windows XP dan Vista, Android 4.3 ke bawah |
| Termasuk TLS 1.0 | Hampir nggak ada, tapi harganya gede |
Buat situs publik di Indonesia, TLS 1.2 + 1.3 itu pilihan yang bener kalau ragu.
Soal profil kompatibilitas lama: TLS 1.0 sama 1.1 udah ditarik semua pembuat browser sejak 2020. Nyalain lagi nggak nolong browser modern sama sekali, soalnya mereka nolak, bukan turun versi. Yang didapat cuma nilai C di SSL Labs sama gagal memenuhi PCI DSS.
Pemilih Konfigurasi TLS nyusunnya buat Nginx, Apache, atau HAProxy.
2. Header dasar, hampir nggak ada risikonya
Tiga baris yang jarang ngerusak apa pun:
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-originPasang, reload, cek situs sekilas. Hampir selalu aman.
3. CSP, dan ini yang wajib mulai dari mode laporan
Content-Security-Policy itu header paling berguna sekaligus paling gampang ngerusak.
Pasang dulu sebagai laporan:
Content-Security-Policy-Report-Only: ...Mode ini ngasih daftar lengkap apa yang bakal diblokir, tanpa ngeblokir apa pun. Biarin jalan beberapa hari, baca laporannya, tambahin sumber sah yang muncul, baru ganti nama headernya jadi yang negakin.
Di situs yang udah jalan, CSP yang langsung ditegakin hampir selalu matiin sesuatu. Analitik, iklan, peta, tombol pembayaran.
Satu hal yang perlu disiapin: kalau alamat laporan diisi, siapin penampungnya dulu. Situs yang rame bisa ngirim ribuan laporan per jam di hari pertama, sebagian besar dari ekstensi browser pengunjung.
Generator Content-Security-Policy nyusunnya dengan tiga tingkat ketat.
Soal unsafe-inline
Kalau CSP Anda ada 'unsafe-inline' di script-src, perlu dibilang terus terang: itu matiin justru bagian CSP yang nyetop XSS. Kebijakan kayak gitu masih nolong buat hal lain, batesin ke mana data boleh dikirim, ngelarang pembingkaian. Tapi jangan nganggep situsnya udah aman dari penyisipan script.
Jalan keluarnya bukan ngetatin header, tapi mindahin script inline ke file .js sendiri.
4. HSTS, terakhir dan bertahap
HSTS ngasih tahu browser buat nggak pernah pakai HTTP di domain ini.
Yang wajib dipahami: ingatan itu ada di browser pengunjung, dan nggak bisa dibatalin dari sisi server. Kalau sertifikatnya nanti bermasalah, situsnya jadi nggak bisa dibuka, dan matiin HSTS di server nggak nolong sedikit pun sampai masa berlakunya habis di tiap browser.
Naikin bertahap: 5 menit, sehari, seminggu, baru setahun.
Preload jangan dipasang kecuali Anda yakin seluruh subdomain, sekarang dan yang belum dibikin, bakal selalu pakai HTTPS. Keluar dari daftar preload makan berbulan-bulan.
5. security.txt, kecil dan sering diabaikan
File di /.well-known/security.txt ngasih tahu orang yang nemu lubang ke mana harus lapor.
Tanpa itu, sebagian orang nyerah setelah lima menit nyari. Lubangnya nggak ilang, Anda cuma nggak bakal pernah tahu, sampai orang lain nemuin lewat jalur yang beda.
Generator security.txt nyusunnya sesuai RFC 9116.
Yang nggak diselesaiin header
Header keamanan itu lapisan kedua, yang nahan akibat waktu lapisan pertama bocor. Sanitasi input, escape output, update library, sama password yang bener tetap wajib.
Situs dengan CSP sempurna dan WordPress yang tiga tahun nggak diupdate tetap bakal kebobol.