Cara menyiapkan HSTS tanpa mengunci akses Anda sendiri

HSTS sederhana sampai ternyata tidak

HTTP Strict Transport Security, biasanya disingkat HSTS, memberi tahu browser: “untuk situs ini, selalu gunakan HTTPS.” Setelah browser menerima header melalui koneksi HTTPS yang valid, browser akan mengingat aturan tersebut selama durasi yang Anda tentukan.

Itu berguna. Ini mencegah serangan penurunan protokol, mengurangi permintaan tidak aman yang tidak disengaja, dan menghindari momen canggung ketika pengguna mengetik example.com lalu sempat menyentuh HTTP biasa sebelum dialihkan.

Ini juga melekat. Jika Anda menerbitkan kebijakan HSTS yang salah, browser dapat terus menerapkannya lama setelah Anda menghapus header dari server. Begitulah tim mengunci akses mereka sendiri: bukan persis dari panel admin mereka, melainkan dari browser pengguna, subdomain, sistem staging, endpoint lama, dan layanan terlupakan yang belum siap dipaksa menggunakan HTTPS.

Tujuannya bukan menghindari HSTS. Tujuannya adalah menerapkannya seperti migrasi, bukan seperti sakelar.

Apa yang sebenarnya dilakukan header HSTS

Header HSTS yang umum terlihat seperti ini:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Header ini memiliki tiga bagian penting:

• max-age: berapa lama, dalam detik, browser harus memaksakan HTTPS untuk host ini.
• includeSubDomains: apakah aturan tersebut juga berlaku untuk setiap subdomain.
• preload: sinyal bahwa Anda ingin domain dimasukkan ke daftar preload browser.

Browser hanya memercayai header ini saat menerimanya melalui HTTPS yang valid. Jika sertifikat tidak valid, kedaluwarsa, atau tidak cocok, browser seharusnya tidak menerima kebijakan HSTS baru dari respons tersebut.

Setelah kebijakan tersimpan, upaya berikutnya untuk mengunjungi http://example.com akan ditingkatkan oleh browser menjadi https://example.com sebelum permintaan dikirim. Itulah manfaat privasinya: permintaan tidak aman tidak pernah keluar dari perangkat.

Skenario lockout yang perlu dihindari

Sebagian besar kegagalan HSTS tidak disebabkan oleh situs web utama. Masalahnya terjadi di bagian tepi.

1. Subdomain yang terlupakan belum siap HTTPS

includeSubDomains terdengar rapi, tetapi sifatnya mutlak. Jika Anda mengaturnya pada example.com, aturan itu berlaku untuk:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• apa pun yang lain di bawah domain tersebut

Jika salah satu host tersebut tidak dapat menyajikan HTTPS yang valid, pengguna dengan kebijakan HSTS yang sudah tersimpan tidak akan dapat menjangkaunya melalui HTTP.

2. Sertifikat kedaluwarsa

Tanpa HSTS, pengguna terkadang mengklik melewati peringatan sertifikat. Itu bukan praktik keamanan yang baik, tetapi memang terjadi.

Dengan HSTS, browser modern tidak mengizinkan bypass mudah atas kesalahan sertifikat untuk host tersebut. Inilah intinya. Ini juga berarti pembaruan sertifikat harus menjadi hal yang membosankan, dipantau, dan diuji.

3. Staging atau alat internal berada di bawah domain produksi

Menempatkan alat internal di bawah *.example.com dapat menjadi menyakitkan setelah domain induk menggunakan includeSubDomains. Jika alat tersebut menggunakan sertifikat self-signed, certificate authority privat, konfigurasi TLS lama, atau sama sekali tanpa HTTPS, HSTS akan mengekspos jalan pintas itu.

Ini salah satu alasan banyak tim menyimpan sistem internal dan eksperimental di bawah domain terpisah yang memiliki kebijakan keamanannya sendiri.

4. Preload diperlakukan seperti checkbox rutin

HSTS preload bukan sekadar direktif lain. Artinya domain Anda dapat dikirimkan di dalam browser sebagai HTTPS-only sebelum pengguna mana pun pernah mengunjungi situs Anda.

Itu menutup celah “kunjungan pertama”, tetapi jauh lebih sulit dibatalkan. Penghapusan dari daftar preload dapat membutuhkan waktu berminggu-minggu atau berbulan-bulan hingga sampai ke pengguna, bergantung pada siklus rilis browser. Preload cocok untuk domain yang stabil dan matang. Ini tidak cocok untuk situs yang masih menemukan inventaris subdomainnya.

Rencana peluncuran yang aman

Step 1: Audit setiap hostname yang Anda kendalikan

Sebelum mengatur includeSubDomains, daftarkan setiap hostname di bawah domain. Catatan DNS adalah awal yang baik, tetapi bukan keseluruhan cerita. Periksa konfigurasi CDN, dashboard hosting, hostname terkait email, alat pemasaran lama, storage bucket, dan dokumentasi internal.

Untuk setiap hostname, jawab:

• Apakah ia menyajikan HTTP, HTTPS, atau keduanya?
• Apakah sertifikat HTTPS valid dan diperbarui otomatis?
• Apakah HTTP dialihkan ke HTTPS dengan bersih?
• Apakah memang dimaksudkan untuk publik?
• Apakah masih diperlukan?

Jika tim Anda sudah memiliki kebiasaan debugging header produksi, ini cocok ditempatkan berdampingan dengan pemeriksaan redirect dan header. Kami membahas alur kerja tersebut dalam toolkit kecil untuk debugging redirect dan header HTTP di produksi.

Step 2: Perbaiki HTTPS sebelum menambahkan HSTS

HSTS tidak membuat setup HTTPS yang rusak menjadi aman. HSTS hanya membuat HTTPS wajib.

Sebelum mengaktifkannya, verifikasi:

• Sertifikat TLS mencakup hostname yang benar.
• Sertifikat diperbarui secara otomatis.
• HTTP dialihkan ke HTTPS dengan satu lompatan bersih bila memungkinkan.
• Redirect host kanonis konsisten, misalnya non-www ke www, atau sebaliknya.
• Aset aplikasi tidak bergantung pada URL http:// yang tidak aman.

Mixed content tidak sesering dulu, tetapi masih muncul di tema CMS lama, snippet analytics, media tersemat, dan path gambar yang di-hard-code.

Step 3: Mulai dengan max-age yang sangat pendek

Jangan mulai dengan satu tahun. Mulailah dengan lima menit:

Strict-Transport-Security: max-age=300

Terapkan hanya pada hostname yang sedang Anda uji, biasanya situs web produksi kanonis. Untuk saat ini, jangan sertakan includeSubDomains.

Lalu uji di browser nyata dan dengan permintaan command-line:

curl -I https://example.com

Anda seharusnya melihat tepat satu header Strict-Transport-Security. Header HSTS duplikat dari app server dan CDN adalah sumber kebingungan yang umum. Browser umumnya menerapkan kebijakan efektif, tetapi manusia yang sedang men-debug insiden tidak membutuhkan ambiguitas.

Step 4: Tingkatkan secara bertahap

Jika tidak ada yang rusak, tingkatkan durasinya secara bertahap:

Strict-Transport-Security: max-age=86400

Lalu:

Strict-Transport-Security: max-age=604800

Lalu mungkin:

Strict-Transport-Security: max-age=2592000

Jadwal praktisnya adalah:

• 5 menit
• 1 hari
• 1 minggu
• 1 bulan
• 6 bulan atau 1 tahun

Tidak ada hadiah untuk terburu-buru. Inti peluncuran bertahap adalah memberi monitoring, inbox dukungan, dan edge case waktu untuk memberi tahu Anda apa yang terlewat dari checklist.

Step 5: Tambahkan includeSubDomains hanya setelah audit benar-benar nyata

Setelah setiap subdomain publik siap HTTPS, Anda dapat mempertimbangkan:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Ini adalah momen untuk konservatif. Jika satu layanan legacy masih membutuhkan HTTP, jangan tambahkan includeSubDomains ke domain induk. Migrasikan layanan tersebut, pindahkan ke domain lain, atau terima bahwa kebijakan HSTS Anda harus tetap lebih sempit untuk saat ini.

Header keamanan harus mencerminkan kenyataan. Header tidak seharusnya digunakan sebagai poster motivasi untuk infrastruktur yang Anda harap akan Anda miliki nanti.

Step 6: Perlakukan preload sebagai proyek terpisah

Pertimbangkan preload hanya ketika semua hal berikut benar:

• Domain dan semua subdomain mendukung HTTPS yang valid.
• HTTP dialihkan ke HTTPS.
• Header HSTS menggunakan max-age setidaknya 31536000 detik.
• Header menyertakan includeSubDomains.
• Header menyertakan preload.
• Anda yakin tidak akan membutuhkan HTTP biasa di mana pun di bawah domain tersebut.

Header yang siap preload terlihat seperti ini:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Mengirimkan ke daftar preload adalah komitmen jangka panjang. Jika situs tersebut adalah microsite kampanye, domain produk sementara, atau domain dengan batas kepemilikan yang tidak jelas, lewati saja.

Contoh konfigurasi

Nginx

Gunakan always agar header juga dikirim pada respons error:

add_header Strict-Transport-Security "max-age=300" always;

Setelah peluncuran stabil:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

Dengan mod_headers aktif:

Header always set Strict-Transport-Security "max-age=300"

Nanti:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN atau platform edge

Jika CDN Anda mengatur header respons, sebaiknya kelola HSTS di satu tempat. Jangan tetapkan satu kebijakan di origin dan kebijakan lain di edge kecuali Anda memiliki alasan yang sangat jelas.

Periksa juga apakah CDN menerapkan header pada redirect, error yang di-cache, dan halaman error kustom. Situs produksi bukan hanya respons 200 OK-nya.

Cara membatalkan HSTS dengan aman

Jika Anda perlu menonaktifkan HSTS, kirim:

Strict-Transport-Security: max-age=0

Namun ada catatan: browser harus berhasil menjangkau situs melalui HTTPS yang valid untuk menerima header tersebut. Jika HTTPS itu sendiri rusak, pengguna dengan kebijakan HSTS yang tersimpan tidak dapat mengambil instruksi yang akan menghapusnya.

Jadi urutan pemulihan yang biasa adalah:

1. Pulihkan HTTPS yang valid.
2. Sajikan Strict-Transport-Security: max-age=0.
3. Pertahankan cukup lama agar pengguna yang kembali menerimanya.
4. Hapus atau ganti header setelah insiden terselesaikan.

Jika domain masuk preload, menyajikan max-age=0 tidak cukup untuk profil browser baru. Anda juga perlu meminta penghapusan dari daftar preload dan menunggu perubahan itu dikirim melalui pembaruan browser.

Checklist pengujian sebelum Anda ship

Gunakan checklist ini sebelum meningkatkan max-age atau menambahkan includeSubDomains:

• URL HTTPS kanonis mengembalikan sertifikat yang valid.
• HTTP dialihkan ke HTTPS.
• Hanya ada satu header HSTS.
• Header muncul pada redirect dan respons error jika sesuai.
• Semua subdomain publik memiliki HTTPS yang valid.
• Pembaruan sertifikat dipantau.
• Tidak ada sistem internal kritis yang bergantung pada HTTP di bawah domain induk yang sama.
• Preload telah dibahas secara eksplisit, bukan ditambahkan karena kebiasaan.

Lighthouse juga dapat menandai header keamanan yang hilang atau lemah dalam beberapa konteks, tetapi itu tidak boleh menjadi satu-satunya metode verifikasi Anda. Jika Anda menggunakannya sebagai bagian dari tinjauan yang lebih luas, baca temuannya sebagai sinyal, bukan vonis; pola pikir yang sama berlaku saat Anda membaca laporan Lighthouse tanpa panik.

<!-- tool-cta:start -->

💡 Coba ini: Sebelum dan sesudah setiap perubahan HSTS, periksa respons Strict-Transport-Security dengan Get Headers untuk memastikan max-age, includeSubDomains, dan preload sesuai dengan yang Anda harapkan.

<!-- tool-cta:end -->

Argumen privasi untuk HSTS

HSTS sering dibingkai sebagai header keamanan, dan memang begitu. HSTS juga memiliki manfaat privasi: mengurangi kemungkinan permintaan pertama pengguna bocor melalui HTTP biasa di jaringan yang tidak tepercaya.

Itu penting di Wi-Fi bandara, jaringan hotel, jaringan tamu perusahaan, dan di mana pun traffic pengguna mungkin diamati atau dimodifikasi. Permintaan HTTP biasa dapat mengekspos hostname, path, cookie tanpa flag Secure, dan detail permintaan lainnya. HTTPS bukan sihir, tetapi memaksakannya secara konsisten menghapus satu kelas kebocoran yang sebenarnya dapat dihindari.

Penerapan HSTS terbaik adalah yang tidak menarik perhatian. Diluncurkan perlahan, didukung sertifikat yang andal, dan cukup membosankan sehingga tidak ada yang menyadarinya. Itulah tepatnya yang Anda inginkan dari header dengan mode kegagalan yang bisa dramatis.