REST API nasıl güvenli hâle getirilir? Pratik bir kontrol listesi

API, çoğu zaman modern bir uygulamanın en açıkta kalan parçasıdır. Tanımı gereği dış dünyadan gelen istekleri kabul etmek için tasarlanmıştır; bu da onu saldırganın verilerinize ve iş mantığınıza ulaşabileceği en doğrudan yol yapar. Bir API'yi gerçekten güvenli hâle getirmek tek bir özellikle olmaz; her biri ayrı ayrı ve bilinçli olarak ele alınması gereken konulardan oluşan bir kontrol listesidir.

Kimlik doğrulama: İsteği kimin yaptığını kanıtlamak

Korunan bir uç noktaya (endpoint) gelen her istekte, isteği kimin yaptığını güvenilir biçimde belirlemenin bir yolu olmalıdır. Yaygın ve sağlam yaklaşımlar arasında servisler arası iletişim için API anahtarları, kullanıcıya dönük uygulamalar için token tabanlı kimlik doğrulama (OAuth 2.0 veya JWT gibi) sayılabilir. Hangi mekanizmayı seçtiğiniz, temelleri doğru kurmaktan daha az önemlidir: Token'ların süresi dolmalı, yalnızca şifreli bağlantılar üzerinden iletilmeli ve asla URL'de yer almamalıdır; çünkü URL'deki bir token'ın güvensiz bir yerde loglanma ihtimali çok daha yüksektir.

Yetkilendirme: Ne yapmaya izinli olduğunu kontrol etmek

Kimlik doğrulama “Kimsiniz?” sorusunu yanıtlar. Yetkilendirme ise “Ne yapmaya izniniz var?” sorusunu yanıtlar ve yalnızca girişte bir kez değil, her istekte ayrıca yapılması gereken bir kontroldür. Çok yaygın ve ağır sonuçlu bir hata şudur: API, isteğin geçerli bir token taşıdığını doğru biçimde kontrol eder, ancak istenen kaynağın gerçekten o kullanıcıya ait olup olmadığını hiç doğrulamaz. Bir kullanıcının, istekteki bir ID'yi değiştirerek başka bir kullanıcının verilerini görüntüleyebilmesi ya da düzenleyebilmesi tam olarak böyle olur. Bu, gerçek güvenlik denetimlerinde en sık rastlanan bulgulardan biri olan bozuk erişim kontrolünün (broken access control) bir türüdür.

İstek sınırlama: Kötüye kullanıma ve aşırı yüke karşı koruma

İstek sınırlama (rate limiting) olmadan tek bir istemci, ister kötü niyetli ister sadece yanlış yapılandırılmış olsun, API'nizi isteklerle bombalayabilir. Amaç bir giriş uç noktasına kaba kuvvet (brute-force) saldırısı yapmak da olabilir, altyapınızı aşırı yüklemek de. Pratikte istek sınırlama; kullanıcı ya da API anahtarı başına makul limitler belirlemek, limite takılan istemciye açık bir yanıt döndürmek ve giriş ile şifre sıfırlama gibi hassas uç noktalara rutin okuma isteklerinden daha sıkı limitler uygulamak demektir.

Girdi doğrulama: Gelen hiçbir şeye güvenmeyin

Her istekteki her alan, uygulama mantığınızın herhangi bir yerinde kullanılmadan önce gerçekte beklenen değerlere göre doğrulanmalıdır: tür, uzunluk, biçim, izin verilen aralık. Bu, SQL enjeksiyonunu önleyen ilkenin aynısıdır, ancak kapsamı çok daha geniştir: Hatalı biçimlendirilmiş ya da beklenmedik girdiler, yalnızca veritabanı sorgularında değil, gerçek uygulama açıklarının büyük bir bölümünün arkasında yatar.

Aktarım güvenliği: İstisnasız her şeyi şifreleyin

Her istek ve yanıt HTTPS üzerinden iletilmeli; düşük riskli gibi görünen uç noktalarda bile şifresiz bir alternatif bırakılmamalıdır. Let's Encrypt gibi modern araçlar, bunu doğru biçimde kurmayı neredeyse ücretsiz hâle getiriyor; dolayısıyla API yüzeyinizin herhangi bir yerinde bundan vazgeçmek için geçerli bir mazeret nadiren vardır.

Makul hata mesajları

Ayrıntılı hata mesajları geliştirme sırasında gerçekten işe yarar, canlı ortamda ise gerçekten tehlikelidir. Dahili dosya yollarını, veritabanı sürümünü ya da tam bir stack trace'i açığa çıkaran bir hata, saldırgana gerçek bir zayıflık bulma yolunda avantaj sağlar. Canlı ortamdaki hata yanıtları işe yarayacak kadar bilgilendirici olmalı, fazlası değil.

Loglama ve izleme

Kimin neye ne zaman eriştiğinin gerçek bir kaydına ihtiyacınız var. Amaç hiçbir şeyi yavaşlatmak değil; bir şeyler ters gittiğinde omuz silkmek yerine incelenebilecek somut bir iz bulunmasını sağlamak. Bir hesabın aniden alışılmadık yüksek hacimde istek göndermesi gibi olağan dışı örüntüleri takip etmek, süren bir saldırıyı gerçek bir olaya dönüşmeden erkenden yakalamanızı sağlayabilir.

Kendi API'nizde uygulamanız gereken kontrol listesi

• Bilinçli olarak herkese açık bırakılanlar dışında her uç nokta kimlik doğrulama gerektiriyor mu?
• Her istekte kullanıcının yalnızca genel olarak giriş yapmış olduğu değil, o belirli kaynak için yetkili olduğu da kontrol ediliyor mu?
• Özellikle giriş, şifre sıfırlama ve diğer hassas uç noktalarda istek sınırlama uygulanıyor mu?
• Yalnızca bariz biçimde riskli görünenler değil, tüm girdiler kullanılmadan önce doğrulanıyor mu?
• HTTPS her yerde, istisnasız zorunlu mu?
• Canlı ortamdaki hata yanıtları dahili uygulama ayrıntılarını sızdırmaktan kaçınıyor mu?
• Bir olayı sonradan gerçekten inceleyebilecek kadar loglama var mı?

Bu listeyi soyut düzeyde değil, uç nokta uç nokta titizlikle ele almak, Burncode'un müşterileri için yürüttüğü uygulamalı güvenlik denetimlerinin ta kendisidir. Bu çalışmaya altyapı sıkılaştırma ve gerçek bir uyumluluk denetimine hazırlık da eşlik eder.