Bloga geri dön
Peki, API’larınız ne kadar güvenli biliyor musunuz? Savunmasız bilgileri sızdırmadığımızdan, uç noktaların spam edilmediğinden, her şeyin yolunda gittiğinden ve uygun şekilde korunduğundan emin olmak için dikkate almanız gereken 5 önemli şey var. Bu yazıda dikkat edilmesi gereken ana noktaları derledim. İyi okumalar.
Güvenli bir API’ın 5 adımına geçmeden önce SOAP ve REST kavramlarına bakmak iyi olacaktır.
SOAP Protokolü nedir?
API güvenliği, veri alışverişi sırasında hassas bilgilerin korunmasını sağlamak için geliştirilen bir dizi önlemleri içerir. Bu önlemler arasında SOAP (Simple Object Access Protocol), güvenli bir veri iletişimini temin etmek adına önemli bir rol oynar.
SOAP, basit nesne erişim protokolü (Simple Object Access Protocol) olarak bilinir ve web servislerinde kullanılan bir iletişim protokolüdür. XML tabanlı bir protokol olan SOAP, farklı platformlardaki uygulamalar arasında yapılandırılmış bilgi alışverişini mümkün kılar.
SOAP (Simple Object Access Protocol):
Aşağıda SOAP tabanlı bir API örneğini görebilirsiniz:
Bu örnekte, bir öğrenci bilgi sistemi API'ı simüle edilmektedir. API, öğrenci bilgilerini almak ve güncellemek için SOAP protokolünü kullanır. Ayrıca, güvenlik önlemleri olarak kimlik doğrulama ve veri şifreleme kullanılmaktadır.
Bu örnekteki güvenliği incelemek gerekirse:
REST nedir?
REST ise “Representational State Transfer”ın kısaltmasıdır ve genellikle web tabanlı servisler arasında veri iletişimini kolaylaştırmak için kullanılır. RESTful API'lar, HTTP protokolü üzerinden standart HTTP metodları (GET, POST, PUT, DELETE vb.) kullanarak kaynaklara erişim sağlar.
Örnek olarak bir blog uygulamasının yazılarına erişim sağlayan bir API ve Bu API’ın aşağıdaki özellikleri olduğunu düşünelim:
5 adımda API güvenliği
1. ADIM: HTTPS
Saldırganların ortadaki adam saldırısını gerçekleştirmemeleri ve client’tan server’a gidip gelen verileri okumamaları için client ve server arasındaki bağlantının şifrelenmiş olduğundan emin olmak gerekir. Bu genelde bizim için otomatik olarak yapılır.
2. ADIM: AUTHENTICATION & AUTHORIZATION
Kullanıcının olduğunu iddia ettiği kişi olduğundan OAuth, Google, Github, email-şifre vs. kullanarak emin olmak “authentication” adına yapmamız gereken şeydir. Bunun karşılığında, bu kimlik bilgileri karşılığında, kullanıcı bir json web token (JWT) olan bir token alır veya bu sizin de bir veritabanında sakladığınız bir oturum token’ı olabilir. Bunlar kimlik doğrulamaya yönelik 2 farklı yaklaşımdır.
Bu “authentication” kısmıydı. Bu adımdan sonra artık kullanıcının olduğunu iddia etti kişi olduğunu biliyoruz.
“Authorization” ise şu soru ile özetlenebilir: “Kullanıcıların ne yapmaya yetkisi var?”
Rol tabanlı kimlik doğrulaması varsa (yönetici mi, kullanıcı mı…) veya yoksa, herhangi bir kullanıcının ne yapmaya izni vardır? Örneğin veri tabanındaki isimlerini değiştirebilirler mi? Veri tabanı ile nasıl iletişim kurabilirler?
“Authorization” aşaması bunlarla ilgilidir.
Genelde yaptığımız şey API endpoint ile link edilmiş kesin bir aksiyon almadan önce mantıksal kontrolleri sağlamaktır. Örneğin bir “endpoint”in amacı veritabanındaki kullanıcı adını değiştirmek olsun. Bunu yapmadan önce, yetkilendirme açısından, şu örnek verilebilir:
“Kullanıcı geçtiğimiz 1 saat içerisinde 3’ten fazla isim değiştirdi mi?”
Eğer değiştirdiyse, aynı işlemi aynı saat içerisinde tekrar yapma yetkisi yoktur.
Amaç, kullanıcı adını değiştirmek:
Artık şifreli veri trafiği gönderiyoruz, kullanıcının kim olduğunu ve ne yapmasına izin verildiğini biliyoruz.
Ama bir saniye! Herhangi biri, oturum açmamış olsa bile, API bağlantı noktanızı tamamen spam’layabilir ve sizi veritabanınıza ileri geri birçok istekte bulunmaya zorlayabilir ve bu da size paraya mal olur.
Bununla ilgili sıradaki adımımız ise: Rate limits.
3. ADIM: RATE LIMITS
Rate limit için “upstash” kullanılabilir. Bu sayede API endpoint’lerimizi korumamız kolaylaşır (özellikle serverless bir environment’ta). Bunun dışında yine rate limit için kullanılan başka paketler de vardır.
Örnek:
Ancak kişinin kötü niyetli bir istekte bulunmaya çalıştığından emin olamayız çünkü kullanıcının kim olduğunu bilmek, onun saldırgan olmadığı anlamına gelmez. Bu yüzden input doğrulaması yapmamız gerekir.
4. ADIM: INPUT VALIDATION
Herkes istediği veriyle API rodlarımızdan herhangi birine istekte bulunabilir. Sunucuya aldığımız ve istekte işlediğimiz verilerin aslında beklediğimiz gibi olduğundan ve kötü niyetli girdi olmadığından emin olmamız gerekir.
Bunun için TypeScript'te yup kütüphanesini veya zod kütüphanesini kullanabiliriz. Öncelikle backend kısmında beklediğimiz ve daha sonra tekrar parse edebileceğimiz veri için belirli bir şemayı tanımlarız. Böylece bu şemaya aykırı ne olursa olsun herhangi bir veriyi ayrıştırabiliriz. Ayrıştırdığımız veriler şemayla eşleşmiyorsa sunucumuz beklemediğimiz verilerle isteği işleyemeyeceğimiz ve yalnızca API uç noktamıza iletilen verileri belirli şema türünde işleyebileceğimiz için hata verecektir.
Örnek:
Tüm bu adımlardan sonra yapabileceğimiz son şey ise hataları yönetmek olacaktır.
5. ADIM: ERROR HANDLING
API'ımızda her şeyin sorunsuz çalıştığından asla emin olamayız. Yanlış gidebilecek pek çok şey olabilir. Burada “try catch” blokları kullanılabilir. İyi hata yönetiminin sırrı, olup bitenlere ilişkin uygun HTTP durum kodlarını geri göndermektir, çünkü daha sonra bunları “client” tarafında kontrol edebilir ve kullanıcıya uygun bir hata mesajı görüntüleyebiliriz.
Örnek:
Hatanın ne olduğu hakkında hiçbir fikrimiz yoksa generic 500 hata mesajını kullanabiliriz.
Bu beş önemli faktörü ele alarak SOAP veya REST API'ımızı potansiyel güvenlik açıklarına karşı güçlendirebilir ve genel güvenliğini artırabiliriz.
Hocam elinize sağlık bu dönemde çok ihtiyaç duyduğumuz bir yazı olmuş.
Teşekkürler
