Express API Güvenliği
Biz yazılımcılar olarak temel problemlerimizden biri aslında kodun kendisine ve çalışıp çalışmamasına odaklanmamız diyebilirim.
Bu durum o kadar içimize işler ki bir yerden sonra güvenlik ve optimizasyonlar unutulur. Hep sonra ekleneceği be muhakkak yapılacağı vurgulanır.
Özellikle kendi adımıza geliştirdiğimiz küçük uygulamalar için güvenlik en son düşündüğümüz parametredir. Ancak bunu bir alışkanlık bir düşünüş biçimi olarak uygulamak her sistem için kritik olabilmektedir.
“If you spend more on coffee than on IT security, you will be hacked. What’s more, you deserve to be hacked”
― Richard Clarke
Bildiğimiz üzere asla güvenlik diye bir şey yoktur. Aslında güvenlik yanılsaması vardır dersek daha doğru bir tanım yapmış olabiliriz.
Çünkü her yöntemin bir anti yöntemi muhakkak bulunabilir. Özellikle web sektörü için bu durumda dahada kritik diyebiliriz.
“If security were all that mattered, computers would never be turned on, let alone hooked into a network with literally millions of potential intruders”
― Dan Farmer
Bugün basitçe bir node js api için güvenlik konusunu ele alacağız. Bunun için önce başımıza gelebilecek belli güvenlik açıklarını tanımlamaya başlasak daha faydalı olabilir.
1) Ah şu ayar dosyaları…
Sorun: Database şifrelerimiz , gizli şifrelerimiz vb vb.. bunların hepsini düz text veya json dosyalarında tutuyorsanız yada unutuyorsanız, başınız belada olabilir. Şifrelemek için oluşturduğunuz gizli şifreyi normal dosyada tutmak sizi uzun süre korumaz değil mi?
Çözüm: Özellikle git’ için bu dosyaları kesinlikle git stage içine almamak ve ignore etmek en faydalısı. Eğer dosyadan okuyorsak .env yapılarını kullanmak ve tutacağımız şifre dosyalarını şifrelemek bir çözüm olabilir.
2) İstek Limitleri
Sorun: Api yapımız hepimizin bildiği üzere dışarıdan gelen requestlere cevap vermek üzerine geliştirdiğimiz bir yapı. Eğer bize aynı kullanıcıdan gelen istekleri saymaz , bilmezsek ne mi olur ? Hoşgeldin Ddos saldırısı!
Ddos saldırısı temelinde yapılabilmesi aşırı basit ancak hala çok etkili bir saldırı yöntemi.
Çözüm: Bu saldırıdan mümkün mertebe uzak durmanın yolu cloud load balancerı, cloud firewalları ve başlıcarate-limiter-flexible npm kütüphanesini kurmak diyebiliriz. Bu şekilde aynı kullanıcı belli zaman periyodu içinde belli bir istek sayısından fazla istek atarsa artık o istekleri kaale almayı bırakıyoruz harika değil mi :)
3) Http Başlıkları… Ama kaskımız var
Sorun: Uygulamanızın, saldırganların siteler arası komut dosyası (XSS), ve diğer kötü amaçlı saldırılar gibi yaygın saldırıları kullanmasını önlemek için güvenli header kullanılması gerekir.
Çözüm: En popüler npm kütüphanelerinden olan helmet bu derde deva!
4) Veriler bizim veriler mi ?
Sorun: Api için kullanıcıdan beklediğimiz değerler ve bu değerlere verdiğimiz cevaplar bütünü vardır. Kullanıcıdan gelen değerlerin doğru olduğuna emin olmamamız bizi bürçok kontrolden kurtardığı gibi aslında bir nevi güvenlik sağlamaktadır.
Çözüm: En popüler npm kütüphanelerinden olan joi ve express-validation bu derde deva!
5) Limit payload, limit iyidir
Sorun: Gelen isteklerimizin içinde bize ulaşan payloadların büyüklüğü bizim için önemlidir. Çünkü büyük yük thread için baş belasıdır. Aynı anda birçok kullanıcı istek attığında uygulamamız kolayca çökebilir.
Çözüm: Middleware katmanında gelen payloadı kolayca limitleyebiliyoruz.
6) Hatalarımız… Onlar değerliler
Sorun: Sistemimizin herhangi bir yerinden oluşabilecek hatalarımızın kesinlikle son kullanıcı tarafından görünmemesi gerekli. Eğer hatamız düzenlemez ise kötü niyetli kullanıcılara ipucu verebilir.
Çözüm: Middleware katmanında hata ayıklaması yapmalıyız.
Eveeet, geldik yazımızın sonuna. Güvenlik öyle büyük bir alanki yukarıda verdiğim bilgiler sadece denizde bir kum tanesi olabilir. Güvenli, güvenlikte kalın!
