Konteks dan cakupan
API terotentikasi Anda mendengarkan pada HTTP dan HTTPS, dan permintaan HTTP menerima respons 301 ke HTTPS. Jelaskan risikonya, perubahan pada server dan klien, serta rencana migrasi untuk klien lawas. Konteks ini didasarkan pada Internet-Draft kelompok kerja HTTPAPI bulan Mei 2026; dokumen ini masih berupa pekerjaan yang sedang berjalan dan bukan merupakan RFC final.
Apa yang sedang diuji oleh pewawancara
- Menyadari bahwa kredensial telah melintasi jaringan teks biasa sebelum pengalihan (redirect) terjadi.
- Menggabungkan HSTS, rekaman DNS HTTPS, pemblokiran koneksi, dan cookie Secure.
- Menangani host bersama (shared host), klien lawas, proksi, dan pencabutan kredensial.
- Membuktikan pengurangan risiko dengan sinyal yang terukur daripada hanya mengatakan "gunakan HTTPS."
Pertanyaan untuk diklarifikasi sebelum menjawab
- Apakah HTTP dan HTTPS menggunakan nama host dan listener yang sama?
- Apakah kredensial berupa token Bearer, cookie, kunci API, atau tanda tangan permintaan?
- Apakah ada klien lawas, proksi perusahaan, atau pemanggil internal yang tidak dapat langsung ditingkatkan versinya?
- Apakah titik masuk HTTP juga melayani sumber daya yang tidak terotentikasi?
- Apakah Anda sudah menggunakan HSTS, rekaman DNS HTTPS, rotasi kunci, dan log audit?
Kerangka jawaban 30 detik
Pengalihan tidak dapat memulihkan kredensial yang sudah dikirim dalam teks biasa; pengamat pasif dapat menyalin token Bearer atau cookie. Lebih baik membuat titik masuk HTTP gagal sebelum koneksi terotentikasi terjadi, menggunakan rekaman DNS HTTPS dan HSTS untuk mengurangi kesalahan konfigurasi pada penggunaan pertama dan berulang, menyetel Secure pada cookie, dan memastikan klien menolak URL tidak aman secara default. Jika pemblokiran langsung tidak memungkinkan, kembalikan respons 403 yang sama untuk setiap permintaan teks biasa yang memuat kredensial dan cabut kredensial yang mungkin telah bocor. Lakukan migrasi dengan metrik, masa transisi (gray period), dan kemampuan rollback.
Pembahasan mendalam langkah demi langkah
1. Jelaskan kapan kebocoran terjadi
Klien mengirimkan permintaan HTTP terlebih dahulu, yang berpotensi memuat Authorization, cookie, atau kunci API. Respons 301 berikutnya tidak dapat menghapus apa yang telah melintasi jaringan. Penyerang dapat memutar ulang (replay) token Bearer atau cookie. Percobaan ulang HTTPS yang berhasil juga dapat menyembunyikan kesalahan konfigurasi klien untuk waktu yang lama.
2. Rancang titik masuk server
Untuk endpoint terotentikasi, nonaktifkan terlebih dahulu listener teks biasa publik atau batasi port 80 ke jaringan yang secara eksplisit tepercaya. Jangan memperlakukan 301 sebagai kontrol keamanan. Jika host bersama harus mempertahankan HTTP, gateway harus mengenali permintaan yang memuat kredensial dan mengembalikan respons 403 yang sama tanpa mengungkapkan apakah kredensial tersebut valid.
HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Length: 0Respons tidak boleh berbeda untuk kredensial yang valid dan tidak valid, jika tidak penyerang akan mendapatkan oracle uji untuk nilai yang dicuri.
3. Kurangi kesalahan klien pada penggunaan pertama
Rekaman DNS HTTPS dapat menginstruksikan klien untuk menggunakan koneksi aman selama pembuatan koneksi. HSTS meningkatkan koneksi berikutnya setelah kunjungan HTTPS yang berhasil. Keduanya tidak sempurna: HSTS bergantung pada koneksi sebelumnya tersebut dan persistensi klien, sementara rekaman DNS dapat diblokir. SDK, CLI, dan validasi konfigurasi harus menolak http secara default dan memberikan pesan perbaikan yang dapat ditindaklanjuti.
4. Batasi penggunaan kredensial
Cookie harus membawa atribut Secure. Token harus dibatasi pada konteks aman, dengan tanda tangan terikat permintaan atau terikat koneksi jika sesuai. Pencabutan berbeda berdasarkan jenis kredensial: kunci API yang dapat diputar ulang, token Bearer, dan cookie umumnya memerlukan pencabutan segera, sementara tanda tangan turunan yang tidak dapat dipalsukan mungkin tidak memerlukannya.
5. Tangani kredensial yang terekspos
Perlakukan kredensial apa pun yang diterima melalui teks biasa sebagai berpotensi disusupi. Server dapat mengembalikan 403 seragam terlebih dahulu, kemudian menjelaskan "kredensial dicabut" pada penggunaan aman berikutnya. Catat pencabutan dalam log audit, beri tahu pemilik untuk merotasinya, dan jangan pernah menempatkan nilai sensitif dalam log, cache, atau badan kesalahan (error body).
6. Migrasi dengan aman
Tolak HTTP terlebih dahulu di SDK dan lingkungan pengujian, lalu nonaktifkan titik masuk teks biasa untuk tenant baru, dan akhirnya migrasikan tenant lawas secara bertahap (batch). Berikan endpoint transisi singkat yang tidak pernah menerima kredensial kepada klien yang memerlukan proksi lama. Tetapkan tenggat waktu, pantau tingkat 403 dan penyelesaian rotasi, serta pindahkan API terotentikasi ke nama host atau kebijakan gateway terpisah jika sumber daya publik masih memerlukan HTTP.
7. Verifikasi kontrol
Gunakan penangkapan paket (packet capture) untuk mengonfirmasi bahwa Authorization, cookie, dan kunci API tidak pernah muncul dalam teks biasa. Verifikasi kegagalan koneksi dan perilaku 403, lalu uji caching HSTS, kunjungan pertama, proksi, percobaan ulang, dan rollback. Lacak permintaan teks biasa, permintaan teks biasa yang memuat kredensial, pencabutan otomatis, false positive 403, pangsa klien lawas, dan penyelesaian migrasi.
Contoh jawaban berkualitas tinggi
Saya tidak akan memperlakukan 301 sebagai solusi keamanan untuk API yang terotentikasi, karena kredensial telah melintasi jaringan teks biasa sebelum pengalihan terjadi. Pengamat pasif dapat menyalin token Bearer atau cookie, dan percobaan ulang HTTPS yang berhasil dapat menyembunyikan kesalahan klien.
Server harus terlebih dahulu menonaktifkan HTTP publik pada endpoint terotentikasi. Jika host bersama tidak dapat melakukannya segera, gateway mengembalikan 403 yang sama untuk setiap permintaan HTTP yang memuat kredensial, tidak mengungkapkan validitas kredensial, dan menandai kredensial sebagai berpotensi terekspos. Token yang dapat diputar ulang, kunci API, dan cookie dicabut serta dirotasi. SDK, CLI, dan pemeriksaan konfigurasi menolak http secara default; rekaman DNS HTTPS dan HSTS mengurangi kesalahan penggunaan pertama dan berulang, serta cookie membawa Secure.
Migrasikan secara bertahap di seluruh lingkungan pengujian, tenant baru, dan tenant lawas. Berikan proksi perusahaan jalur transisi singkat yang tidak menerima kredensial. Verifikasi dengan penangkapan paket dan ukur permintaan teks biasa, permintaan teks biasa yang memuat kredensial, penyelesaian pencabutan dan rotasi, false positive 403, serta pangsa klien lawas. Dokumen IETF masih berupa draf, sehingga komitmen penerapan tetap dapat disesuaikan.
Kesalahan umum
- Menganggap bahwa pengalihan HTTPS melindungi header Authorization atau cookie yang sudah terlanjur dikirim.
- Hanya mengonfigurasi HSTS sambil mengabaikan penggunaan pertama, klien lawas, dan SDK non-browser.
- Mengembalikan respons teks biasa yang berbeda untuk kredensial valid dan tidak valid.
- Memperlakukan setiap kredensial secara identik dan mengabaikan perbedaan tanda tangan turunan versus token yang dapat diputar ulang.
- Menghapus HTTP tanpa rencana migrasi, pemantauan, pencabutan, atau rollback.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika titik masuk HTTP masih melayani sumber daya publik?
Pindahkan API terotentikasi ke nama host terpisah, atau pisahkan jalur dan header kredensial di gateway. Sumber daya publik dapat memiliki kebijakan pengalihannya sendiri; endpoint terotentikasi harus menolak permintaan teks biasa yang memuat kredensial.
Apakah HSTS menyelesaikan masalah kunjungan pertama?
Tidak sepenuhnya. HSTS memerlukan koneksi HTTPS sebelumnya yang berhasil dan persistensi klien. SDK, pemeriksaan konfigurasi, rekaman DNS HTTPS, dan pemeriksaan deployment harus mencakup koneksi pertama juga.
Kapan kredensial harus dicabut?
Perlakukan kredensial yang terlihat dalam teks biasa sebagai berpotensi terekspos. Cabut dan rotasi token yang dapat diputar ulang, kunci API, dan cookie. Untuk tanda tangan turunan yang tidak dapat dipalsukan, tentukan dari model ancaman apakah pencabutan diperlukan.
Bagaimana cara menghindari migrasi yang mengganggu?
Aktifkan penolakan dalam pengujian dan tenant baru terlebih dahulu, amati klien lawas dan false positive 403, lalu migrasikan secara bertahap. Pertahankan endpoint transisi singkat yang tidak menerima kredensial dan hapus setelah batas waktu yang jelas.