Jangan alihkan HTTP API ke HTTPS

• TL;DR: Alih-alih mengalihkan panggilan API dari HTTP ke HTTPS, tandai sebagai kegagalan. Nonaktifkan HTTP sepenuhnya atau kembalikan respons kesalahan HTTP yang jelas, dan cabut API key yang dikirim melalui koneksi tanpa enkripsi. Sayangnya, saat ini banyak penyedia API terkenal tidak melakukannya.

Latar belakang

• Saat browser web mengakses URL HTTP, layanan sering kali mengalihkan permintaan tersebut ke halaman HTTPS.
• Lalu lintas HTTP awal tidak terenkripsi, sehingga rentan terhadap serangan man-in-the-middle (MITM) di jaringan.
• Teknologi seperti HSTS (HTTP Strict Transport Security) telah diperkenalkan untuk memperkuat keamanan.

Risiko dari salah ketik sederhana

• Saat mengerjakan integrasi dengan API pihak ketiga, URL dasar API salah diketik menjadi http:// alih-alih https://.
• fetch di Node.js diam-diam mengikuti pengalihan ke HTTPS.
• API key terkirim dalam bentuk teks biasa, sehingga bisa menimbulkan risiko keamanan.
• Kesalahan tersebut ditemukan saat code review dan masalahnya diperbaiki.

Prinsip fail fast

• Jika API mengalihkan permintaan HTTP ke HTTPS, salah ketik seperti ini bisa mudah terlewat.
• Lebih baik mengikuti prinsip fail fast: panggilan API tanpa enkripsi harus gagal secara jelas.
• Sebaiknya nonaktifkan antarmuka HTTP pada server API, atau kembalikan pesan kesalahan untuk permintaan HTTP.

Contoh dari API lain

• Sejumlah API terkenal mengembalikan pesan kesalahan 403 untuk permintaan HTTP atau menonaktifkan antarmuka HTTP.
• Namun, beberapa API masih mengalihkan dari HTTP ke HTTPS.

Perlunya best practice

• Pada aplikasi yang berorientasi ke pengguna, pengalihan dari HTTP ke HTTPS adalah hal yang umum.
• Namun untuk API, pengalihan dari HTTP ke HTTPS justru bisa merugikan.
• Diperlukan panduan yang jelas untuk API dari proyek keamanan seperti OWASP.

Kesimpulan

• API seharusnya membuat permintaan tanpa enkripsi gagal secara jelas, alih-alih mengalihkan dari HTTP ke HTTPS.
• Jika API key dikirim melalui koneksi yang tidak terenkripsi, kunci tersebut harus segera dicabut.
• Best practice keamanan API perlu diperbarui agar memberikan panduan yang jelas.

Opini GN⁺

• Perlunya penguatan keamanan: Keamanan API sangat penting, dan pengalihan dari HTTP ke HTTPS dapat menimbulkan celah keamanan.
• Prinsip fail fast: Penting untuk mengikuti prinsip fail fast agar kesalahan bisa ditemukan dan diperbaiki pada tahap awal pengembangan.
• Pembaruan best practice: Proyek keamanan seperti OWASP perlu menyediakan panduan yang jelas tentang keamanan API.
• Pencabutan kunci otomatis: API key yang dikirim melalui koneksi tanpa enkripsi harus dicabut secara otomatis.
• Merujuk contoh dari API lain: Perlu memperkuat keamanan API sendiri dengan merujuk pada praktik keamanan API lain.

[wkang586]

Sepertinya ini area yang perlu diatur lewat regulasi.
Untuk sementara, catatan... larang pengalihan https di API

[koxel]

Secara teknis isinya memang benar,
namun sebagian besar klien perusahaan memiliki pedoman keamanan yang mewajibkan pengiriman redirect ke HTTPS saat ada akses HTTP.
Selain itu, mereka juga cenderung tidak suka menampilkan layar error kepada pelanggan yang menggunakan situs mereka, jadi kecuali untuk layanan yang mereka operasikan sendiri, dari posisi sebagai pihak pemasok rasanya ini seperti cerita dari negeri yang jauh..

[thxgeeknews]

Saat mengerjakan integrasi dengan API pihak ketiga, URL dasar API salah dimasukkan sebagai "https://"; alih-alih "http://";.
Sepertinya http <-> https tertukar.

[xguru]

Wah, AI bisa bikin kesalahan seperti ini wkwk. Sudah saya perbaiki.

[GN⁺]

Komentar Hacker News

• OpenAI API telah diperbarui agar mengembalikan error 403 untuk permintaan HTTP.
• API Stack Exchange dinilai lebih baik karena mencabut API key yang dikirim melalui HTTP dan mengembalikan pesan error.
• Perlu berhati-hati agar tidak otomatis mengatur pengalihan dari HTTP ke HTTPS.
• Pengaturan bawaan cURL yang tidak mengikuti pengalihan secara otomatis memang disengaja dan merupakan default yang baik.
• Penting untuk memblokir akses HTTP dan hanya menyediakan HTTPS.
• Mengejutkan bahwa "Provider B" menanggapi bahwa serangan MITM berada di luar cakupan program.
• Ada pertanyaan apakah penyadapan HTTP termasuk salah satu bentuk serangan MITM.
• Diharapkan HTTPS dan record DNS SVCB pada akhirnya dapat menggantikan pengalihan server HTTP tradisional.
• Penyedia API sebaiknya memeriksa log akses HTTP lama mereka dan mengecek seberapa luas penggunaan HTTP plaintext.
• Banyak API dihosting di balik web application firewall yang menetapkan pengalihan HTTPS otomatis sebagai aturan default.
• API tidak boleh otomatis mengalihkan dari HTTP ke HTTPS, dan library klien juga tidak boleh mengikuti pengalihan secara default.
• Mengatur pengalihan dari HTTP ke HTTPS membantu mengurangi trafik dalam jangka panjang.
• Dalam infrastruktur, pengalihan sering kali diatur untuk cepat menyelesaikan masalah akibat salah ketik URL.