REST Api Güvenliği Nasıl Sağlanır?

Bu yazı RESTFul Api Tasarım İncelikleri serisinin bir parçası niteliğindedir. Eğer okumadıysanız önce serinin diğer yazılarını okumanızı tavsiye ederim.

HTTPS

REST Api güvenliğinin ilk adımı kesinlikle HTTPS protokolü. Üretim ortamındaki bir REST API’nin HTTPS üzerinde çalışması şart. Aksi eve kapı ve pencere takmadan hırsız alarmı kurmaya benziyor. HTTP üzerinden kurulan bir iletişim çok rahat bir şekilde manipüle edilirken, HTTPS protokolünde bu çok daha zor. Ama istemciye doğrudan müdahale edip, onu sahte bir HTTPS bağlantısını kullanacak şekilde kandırabilecek imkan veya beceriye sahip bir kişinin bunu yapması halen mümkün. Çok önemli bir adım ama tek başına yeterli değil.

Erişim Kontrolü

Eğer API’nız herkesin erişimine açık değilse ve kullanıcı bazında yetki veya istek limitleri tanımlanması gerekiyorsa bir kimlik doğrulama ve erişim kontrolü sistemi planlamanız gerekiyor. Uygulama tarafında erişim kontrolü nasıl sağlayacağınız Rest API tanımının biraz dışına çıkarak, uygulamanız ve ihtiyaçlarına özel çözüm üretmeniz gereken bir başlık. Her uygulama için ortak sayılabilecek kimlik doğrulama başlığına ise bu yazı dizisinin önceki bölümlerinde değinmiştm.

REST API Kimlik Doğrulama Nasıl Yapılır?

Özetle kimlik doğrulama için ihtiyacınıza bağlı olarak Basic Authentication, Bearer, JWT Token, OAuth veya OpenID gibi çeşitli yöntemler kullanabilirsiniz.

Girdilerin doğrulanması

Sadece Rest API değil, genel olarak bütün web uygulamalarında geçerli olan kural istemciden gelen bilgi ve parametrelerin doğruluğuna güvenmemek, bunları sunucu tarafında doğrulamak ve filtrelemektir.

Doğrulama belirli parametrelerin varlığı, belirli bir format veya uzunluğa uygun olması, isteğin belirli bir boyuttan daha büyük olmaması vb. şekilde olabilir. Doğrulama hatalarını kayıt altına almanız varsa kodunuzdaki açıkları yakalamanızı, kullanıcı davranışlarını görüp frontend’de buna yönelik düzeltmeler yapmanızı ve/veya saldırı amaçlı istekler geliyorsa bunları yakalamanızı sağlar.

Yönetim amaçlı kullanılan uç noktalar

Yönetim amaçlı kullanacağınız uç noktalar varsa bunları mümkünse internetten ulaşılabilir kılmayın, VPN veya en kötü ihtimalle IP denetimine tabi tutun. Eğer bunlar mümkün değilse, kullanıcı doğrulamasının kuvvetli olduğuna emin olun. Sadece basit bir API key’e güvenerek tüm sistemi ayaklar altına sermeyin. Ek olarak eğer mümkünse yönetim noktaları ana sunucunuzdan farklı bir sunucu ve portta çalışsın.

Hata yönetimi

Bir önceki bölümde hata yönetimi ve kullanıcıya hata hakkında detaylı bilgi vermenin öneminden bahsetmiştik. Detaylı bilgi vereceğim derken kantarın topuzunu kaçırmayın. Örneğin “database.ornek.com:3306 veritabanına erişmeye yetkiniz yok” şeklinde detaya girmeye gerek yoktur “veirtabanına erişmeye yetkiniz yok” mesajı yeterlidir. Az detay kulllanıcı deneymini, fazla detay güvenliği yerle bir edecektir.

Rate Limit

İsteklere uygulama veya sunucusu seviyesinde talep sınırı koymanız hem saldırılara karşı koruma sağlar, hem de kaynaklarınızın sömürülmesinin önüne geçer. Hem sunucu genelini, hem de hesap bazında kötü niyetli kullanımlara karşı korur.

Örneğin Facebook API’lerinde belirli bir rate limit olmasa, bunu sınırsız sömürmeye kalkacak on binlerce kötü niyetli insan, hem kaynakları sömürür hem de edindiği bilgilerle Facebook’un başını başka şekilde derde sokabilirdi.

Rate Limit sadece güvenlik değil ticari sebeplerle de uygulanabilir. Örneğin ücretsiz hesap sahipleri dakikada en fazla 20 sorgulama yaparken, ücretli hesaplar 300 sorgulama yapabilsin şeklinde bir sınır koyabilirsiniz.

Öte yandan API’nizi kullanan kişinin bu sınırlara uyabilmesi, gereksiz hata mesajları ile karşılaşmaması ve gereksiz sorgular yapmasının önüne geçmek için sunucu yanıtlarınızda bu sınırlar ile ilgili bilgi yer alması iyi olur. Bunun için yanıtlarda aşağıdaki sunucu başlıklarını kullanabilirsiniz;

X-Rate-Limit-Limit - Mevcut zaman dilimi içindeki izin verilen azami istek sayısı
 X-Rate-Limit-Remaining - Mevcut zaman dilimi içinde kalan istek hakkı
 X-Rate-Limit-Reset - Mevcut zaman diliminin bitimine kalan süre, yani istek hakkının ne zaman sıfırlanacağı

Bu başlıkları aynen kullanmak zorunda değilsiniz, sizin API’nizde sizin tanımlarınız geçerlidir, ama genel kullanıma uyması açısından yukarıdaki başlık bilgilerini kullanmanız iyi olur.

WAF – Web Application Firewall

Kodumuzda XSS saldırıları, SQL enjekte etme, deneme yanılma saldırıları vb. durumlara karşı önlem alsak da, bunu bu iş için özelleşmiş yazılımlar (veya donanımlar) kullanarak çözmek hem daha iyi bir koruma sağlar, hem de kaynak kullanımı açısından daha verimli olur. Esasen bu ihtiyacı ne kadar alt seviyede çözersek verimlilik ve başarı o kadar artar (bu iş için özel tasarlanmış ağ donanım ve yazılımları, sunucu seviyesinde programlar veya servis sağlayıcımızın sunduğu çözümler gibi).

Projemize dahil edeceğimiz kütüphaneler kaynak kullanımı açısından avantaj sağlamasa bile, bu işe özelleşmiş yazıldıkları için bizim atlayacağımız açıkları da kapatabilirler. Benim küçük dünyam için ikinci seçenek daha kullanılabilir bir çözüm ve her zaman daha üst seviyeye yükseltme imkanı var. 🙂

Aklıma geldikçe veya tecrübe ettikçe buraya yeni başlıklar veya bilgiler ekleyeceğim. Bir sonraki bölümde “API dokümantasyonunu nasıl yapılır” başlığını inceleyeceğiz.