HTTP Strict Transport Security Mengunci HTTPS untuk Kunjungan Berikutnya

TLS melindungi koneksi HTTP setelah klien memakai HTTPS. Pengguna yang mengetik hostname tanpa skema, mengikuti tautan lama http://, atau membuka endpoint HTTP yang melakukan redirect masih dapat memulai sesi dengan request tanpa enkripsi.

HTTP Strict Transport Security (HSTS) memberi browser yang mendukungnya aturan persisten untuk host tersebut. Setelah menerima header Strict-Transport-Security yang valid melalui HTTPS, browser menyimpan kebijakan itu dan mengubah navigasi HTTP berikutnya menjadi HTTPS selama kebijakan masih aktif.

Kontrol ini memiliki ruang lingkup yang spesifik. HSTS tidak mengonfigurasi TLS pada server, memperbaiki error sertifikat, atau mengautentikasi pengguna aplikasi. HSTS mengubah perilaku transport browser agar host dengan kebijakan tersimpan tidak kembali memakai HTTP biasa.

Kebijakan hanya diterima melalui HTTPS

Header response dasar dapat berbentuk:

Strict-Transport-Security: max-age=31536000

max-age dihitung dalam detik. Nilai tersebut menentukan berapa lama browser mempertahankan host sebagai host HSTS sejak kebijakan diterima.

Browser mengabaikan header HSTS yang dikirim melalui HTTP biasa. Jika kebijakan transport dapat diterima dari response HTTP yang tidak terautentikasi, penyerang di jaringan dapat mengubah atau menyisipkan kebijakan sebelum TLS melindungi pertukaran data.

Sifat ini juga menimbulkan batas bootstrap utama. Pada browser yang belum memiliki state HSTS, request HTTP pertama masih dapat melewati jaringan sebelum redirect HTTP-ke-HTTPS diproses. HSTS melindungi request berikutnya setelah response HTTPS yang valid membentuk state tersebut.

State HSTS mengubah penanganan request

Setelah sebuah host dikenal sebagai host HSTS, browser yang mendukung HSTS memperlakukan URL http:// untuk host itu sebagai request HTTPS sebelum mengirim request yang tidak aman. Upgrade berlangsung di user agent, bukan melalui redirect di server.

Perbedaan ini menghapus satu round trip HTTP dan, yang lebih penting, mencegah request tersebut terpapar manipulasi pada jalur cleartext. Penyerang di jaringan tidak dapat mengandalkan penghapusan atau perubahan redirect HTTP ketika browser sudah memiliki state HSTS aktif.

HSTS juga mengubah penanganan error sertifikat. Untuk host HSTS, user agent tidak menyediakan opsi normal untuk melewati error sertifikat TLS dan tetap membuka situs. Sertifikat yang rusak atau tidak dipercaya menjadi kegagalan availability sampai konfigurasi TLS diperbaiki atau state HSTS tidak lagi berlaku.

includeSubDomains memperluas batas kebijakan

Sebuah host dapat memperluas kebijakannya ke subdomain:

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

Dengan includeSubDomains, kebijakan berlaku untuk host tersebut dan nama di bawahnya. Kebijakan pada example.com dapat memengaruhi api.example.com, static.example.com, serta turunan yang lebih dalam.

Konfigurasi ini aman diterapkan ketika seluruh namespace yang tercakup siap memakai HTTPS. Host lama yang terlupakan, endpoint development, atau layanan pihak ketiga di bawah domain dapat menjadi tidak dapat diakses browser jika kebijakan parent mencakupnya sementara endpoint tersebut tidak dapat menyelesaikan TLS yang valid.

Flag ini sebaiknya diperlakukan sebagai komitmen namespace, bukan sekadar opsi hardening. Inventaris delegated zone, alias layanan, hostname lama, dan subdomain yang dikelola pihak lain menjadi bagian dari rollout yang aman.

Nilai max-age panjang menciptakan state klien yang bertahan

State HSTS bertahan di browser selama masa yang diumumkan. Setiap response HTTPS valid yang membawa header dapat memperbarui masa tersebut.

Nilai awal yang pendek berguna saat deployment karena kesalahan dapat kedaluwarsa lebih cepat. Operator dapat menaikkan nilainya setelah memastikan redirect, sertifikat, otomasi renewal, subdomain, dan prosedur recovery bekerja sesuai rancangan.

Menghapus header tidak langsung menghapus kebijakan yang sudah tersimpan pada klien. Situs dapat mengirim:

Strict-Transport-Security: max-age=0

melalui HTTPS untuk meminta browser yang mendukung HSTS menghapus kebijakan host. Response tersebut tetap harus berhasil mencapai klien, dan kebijakan turunan dari parent yang memakai includeSubDomains masih dapat mencakup hostname itu.

Konsekuensi operasionalnya jelas: durasi HSTS perlu mengikuti tingkat kesiapan operasi HTTPS berkelanjutan. Nilai satu tahun bukan sekadar konfigurasi header; nilai itu menjadi state klien yang dapat bertahan lebih lama daripada rollback deployment.

Preload menutup celah kunjungan pertama dengan komitmen lebih besar

Browser utama dapat membawa daftar HSTS preload yang berisi domain tertentu. Browser yang memuat domain dalam daftar bawaannya dapat menerapkan perilaku HTTPS-only sebelum browser tersebut pernah mengunjungi situs.

Preload menutup celah kunjungan pertama biasa pada browser yang membawa daftar terkait, tetapi menambah komitmen operasional. Penambahan dan penghapusan mengikuti aturan program preload serta siklus rilis browser; menghapus header dari server tidak langsung menghapus domain dari binary browser yang sudah beredar.

Domain yang dipertimbangkan untuk preload perlu lebih dahulu memiliki HTTPS stabil pada namespace yang diwajibkan dan memenuhi persyaratan program preload saat itu. Status preload bukan pengganti renewal sertifikat, monitoring TLS, atau inventaris layanan.

HSTS dan redirect menangani bagian transisi yang berbeda

Redirect HTTP tetap berguna untuk klien tanpa state HSTS dan klien non-browser yang tidak menerapkan HSTS. Redirect memberi instruksi kepada klien yang mencapai layanan HTTP agar meminta URL HTTPS.

HSTS bekerja lebih awal pada browser yang mendukungnya dan sudah memiliki state tersimpan. Browser melakukan upgrade URL sebelum request tidak aman dikirim.

Deployment biasanya mempertahankan listener HTTP yang hanya melakukan redirect sambil mengirim HSTS pada response HTTPS. Redirect menangani bootstrap dan kasus kompatibilitas; HSTS memperkuat navigasi browser berikutnya.

Header Strict-Transport-Security ditempatkan pada response HTTPS. Menambahkannya hanya pada redirect HTTP tidak membentuk state HSTS karena browser harus mengabaikan header tersebut pada transport yang tidak aman.

HSTS tidak menggantikan deployment TLS yang valid

Host HSTS tetap memerlukan sertifikat yang diterima browser, konfigurasi TLS yang dapat dipakai, dan layanan HTTPS yang dapat dijangkau. Kebijakan membuat kegagalan pada komponen tersebut lebih sulit dilewati; kebijakan tidak mengurangi kemungkinan kegagalan itu sendiri.

Renewal sertifikat memerlukan perhatian khusus. Jika renewal gagal dan sertifikat kedaluwarsa, pengguna host HSTS tidak dapat melewati peringatan sertifikat. Perilaku tersebut memang merupakan tujuan keamanan HSTS, tetapi sekaligus membuat operasi sertifikat menjadi dependency langsung bagi availability.

Hal yang sama berlaku saat migrasi. Pemindahan hostname antar-provider, perubahan certificate authority, atau perubahan DNS perlu mempertahankan HTTPS valid sepanjang transisi. Fallback HTTP sementara tidak kompatibel dengan state HSTS aktif.

Ruang lingkup HSTS berbasis host, bukan path

HSTS tidak dapat dibatasi hanya untuk /login, /account, atau path URL lain. Browser menyimpan kebijakan untuk hostname, dengan cakupan subdomain sebagai opsi.

Hal ini penting pada situs yang masih mencampur aplikasi aman dan tidak aman dalam satu host. HSTS bukan mekanisme untuk melindungi route sensitif saja sambil membiarkan path lain memakai HTTP. Host perlu mendukung HTTPS secara konsisten.

Port juga bukan jalur keluar umum dari kebijakan. Pemrosesan HSTS di browser melakukan upgrade pada URL HTTP yang berlaku sesuai aturan user agent; arsitektur layanan tidak sebaiknya bergantung pada port HTTP alternatif sebagai fallback untuk hostname HSTS.

Rollout perlu mempertahankan jalur recovery

Deployment yang hati-hati dimulai dari HTTPS yang sudah berfungsi pada seluruh cakupan kebijakan yang dituju. Penerbitan dan renewal sertifikat sebaiknya diotomasi atau dioperasikan dengan margin waktu yang cukup untuk mencegah kedaluwarsa. Monitoring perlu menguji endpoint HTTPS itu sendiri, bukan hanya memastikan redirect HTTP mengembalikan response.

Header HSTS kemudian dapat dimulai dengan max-age moderat. Setelah traffic normal, renewal sertifikat, dan perilaku subdomain terpantau baik, durasinya dapat dinaikkan. includeSubDomains memerlukan review terpisah karena memperluas failure domain.

Pengajuan preload merupakan keputusan berikutnya. Langkah tersebut sebaiknya dilakukan setelah postur HTTPS jangka panjang stabil.

HSTS efektif karena browser menyimpan keputusan transport. State tersebut menutup peluang downgrade tidak aman setelah kebijakan terbentuk, sekaligus menjadikan availability HTTPS dan validitas sertifikat sebagai persyaratan operasi yang tegas bagi hostname yang tercakup.