API’nizin HTTP’yi HTTPS’ye yönlendirmesine izin vermeyin

• TL;DR: API çağrılarını HTTP’den HTTPS’ye yönlendirmek yerine başarısız olacak şekilde tasarlayın. HTTP’yi tamamen devre dışı bırakın ya da açık bir HTTP hata yanıtı döndürün ve şifrelenmemiş bağlantı üzerinden gönderilen API anahtarlarını iptal edin. Ne yazık ki bugün birçok büyük API sağlayıcısı bunu yapmıyor.

Arka plan

• Web tarayıcıları bir HTTP URL’sine bağlandığında, servisler çoğu zaman ilgili isteği HTTPS sayfasına yönlendirir.
• İlk HTTP trafiği şifrelenmemiştir; bu da onu ağ üzerindeki aradaki adam (MITM) saldırılarına açık hale getirir.
• HSTS (HTTP Strict Transport Security) gibi teknolojiler devreye alınarak güvenlik güçlendirilmiştir.

Basit bir yazım hatasının riski

• Çalışma sırasında üçüncü taraf bir API ile entegrasyon yaparken, API temel URL’si yanlışlıkla https:// yerine http:// olarak girildi.
• Node.js’in fetch fonksiyonu sessizce HTTPS yönlendirmesini takip etti.
• API anahtarı düz metin olarak iletildiği için bir güvenlik riski doğabilirdi.
• Hata kod incelemesi sırasında fark edilerek sorun giderildi.

Hızlı başarısız olma ilkesi

• Bir API HTTP isteklerini HTTPS’ye yönlendirirse, bu tür yazım hataları kolayca gözden kaçabilir.
• Hızlı başarısız olma ilkesini izlemek daha iyidir: şifrelenmemiş API çağrıları açıkça başarısız olmalıdır.
• API sunucusunun HTTP arayüzünü devre dışı bırakmak ya da HTTP isteklerine hata mesajı döndürmek önerilir.

Diğer API’lerdeki örnekler

• Birçok tanınmış API, HTTP istekleri için 403 hata mesajı döndürüyor ya da HTTP arayüzünü devre dışı bırakıyor.
• Ancak bazı API’ler hâlâ HTTP’den HTTPS’ye yönlendirme yapıyor.

En iyi uygulama ihtiyacı

• Kullanıcı odaklı uygulamalarda HTTP’den HTTPS’ye yönlendirme yaygındır.
• Ancak API’ler söz konusu olduğunda, HTTP’den HTTPS’ye yönlendirme tersine zararlı olabilir.
• OWASP gibi güvenlik projelerinde API’ler için daha açık yönergelere ihtiyaç var.

Sonuç

• API’ler, HTTP’den HTTPS’ye yönlendirmek yerine şifrelenmemiş istekleri açıkça başarısız kılmalıdır.
• API anahtarları şifrelenmemiş bir bağlantı üzerinden iletilirse derhal iptal edilmelidir.
• API güvenliği en iyi uygulamaları güncellenerek açık rehberlik sağlanmalıdır.

GN⁺ görüşü

• Güvenliği güçlendirme gereği: API güvenliği son derece önemlidir ve HTTP’den HTTPS’ye yönlendirme güvenlik açıklarına yol açabilir.
• Hızlı başarısız olma ilkesi: Hataların geliştirme sürecinin erken aşamasında fark edilip düzeltilebilmesi için bu ilkenin izlenmesi önemlidir.
• En iyi uygulamaların güncellenmesi: OWASP gibi güvenlik projeleri, API güvenliği konusunda açık yönergeler sağlamalıdır.
• Otomatik anahtar iptali: Şifrelenmemiş bağlantılar üzerinden gönderilen API anahtarları otomatik olarak iptal edilmelidir.
• Diğer API örneklerinden yararlanma: Kendi API güvenliğini güçlendirmek için diğer API’lerin güvenlik uygulamalarından yararlanmak gerekir.

[wkang586]

Yasayla düzenlenmesi gereken bir alan gibi görünüyor.
Öncelikle not: API'de https yönlendirmesi yasak

[koxel]

Teknik olarak doğru bir nokta, ancak
çoğu kurumsal istemcide güvenlik politikaları gereği HTTP erişiminde koşulsuz olarak HTTPS yönlendirmesi göndermek standart haline gelmiş durumda.
Ayrıca kendi sitelerini kullanan müşterilere hata ekranı göstermeyi de istemedikleri için, kendi hizmetini işleten bir yer değilse tedarikçi tarafında bakınca biraz uzak bir mesele gibi kalıyor..

[thxgeeknews]

Çalışırken üçüncü taraf bir API ile entegrasyon sürecinde, API temel URL'sini "http://"; yerine yanlışlıkla "https://"; olarak girdim.
http <-> https yer değiştirmiş gibi görünüyor.

[xguru]

Vay, yapay zeka böyle bir hata yapmış haha, düzelttim.

[GN⁺]

Hacker News görüşü

• OpenAI API, HTTP istekleri için 403 hatası döndürecek şekilde güncellendi.
• Stack Exchange API’nin, HTTP üzerinden gönderilen API anahtarlarını iptal edip bir hata mesajı döndürmesi daha iyi bir yaklaşım.
• HTTP’den HTTPS’ye yönlendirmeyi otomatik olarak ayarlamamaya dikkat edilmeli.
• cURL’ün varsayılan olarak otomatik yönlendirme yapmaması kasıtlı ve iyi bir varsayılan davranış.
• HTTP erişimini engelleyip yalnızca HTTPS sunmak önemli.
• "Provider B"nin, MITM saldırısının program kapsamı dışında olduğunu söylemesi şaşırtıcı.
• HTTP sniffing’in bir MITM saldırısı türü olup olmadığına dair soru işaretleri var.
• Zamanla HTTPS ve SVCB DNS kayıtlarının, geleneksel HTTP sunucu yönlendirmelerinin yerini alması umuluyor.
• API sağlayıcıları geçmiş HTTP erişim günlüklerini kontrol etmeli ve düz metin HTTP kullanımının ne kadar yaygın olduğunu gözden geçirmeli.
• Birçok API, otomatik HTTPS yönlendirmesini varsayılan kural olarak ayarlayan web uygulaması güvenlik duvarlarının arkasında barındırılıyor.
• API’ler HTTP’den HTTPS’ye otomatik yönlendirme yapmamalı; istemci kütüphaneleri de varsayılan olarak yönlendirmeleri takip etmemeli.
• HTTP’den HTTPS’ye yönlendirme ayarlamak, uzun vadede trafiği azaltmaya yardımcı olur.
• Altyapıda URL yazım hatalarından kaynaklanan sorunları hızlı çözmek için yönlendirme ayarlamak sık görülen bir durum.