API Güvenliği

Rate Limiter

Proje genelinde rate limiter politikası uygulanmalı.

Rate limiter Brute Force ataklarına karşı API’ye gereğinden fazla request atılmasını engelleyen bir yöntemdir. Rate Limiter politikası bir IP’nin belirli bir zaman içerisinde belirli sayıda istek atmasını sağlar. Örneğin 1 saniyede bir IP’den sadece 2 istek gelebilir gibi. Mevcut yazılım dilinde bir middleware olarak yazılabileceği gibi Azure, AWS, CloudFlare vb. platformlar üzerinden de konfigürasyonu yapılabilir.

Paket:
https://www.npmjs.com/package/ratelimiter

Örnek Makale:
https://www.cloudflare.com/learning/bots/what-is-rate-limiting/

---

Captcha Politikası

Projede dışarıya açık formlar varsa (login, register, contact vb.) frontend ve backend üzerinde senkron olan bir captcha kullanılmalıdır.

Cloudflare, Google reCAPTCHA kullanılabilir. Cloudflare captcha ücretsiz ve yaygın kullanımda olduğu için tercih edilmektedir. Cloudflare captcha yeni adıyla Turnstile olarak da bilinir.

Örnek Makale:
https://www.cloudflare.com/en-ca/learning/bots/how-captchas-work/

---

Backend Validation

Projenin dışarıdan parametre alan tüm endpointleri (GET, POST vb. metot fark etmeksizin) bir validation’a sahip olmalıdır.

Dışarıdan gelen tüm datalar validation’a tabi tutulmalıdır. Örneğin POST endpointine gelen bir modelde alan kontrolleri tipleriyle birlikte yapılmalıdır. “ProductName” ve “UnitPrice” alanlarını dışarıdan alan bir endpoint, bu alanların boş geçilemeyeceği ve tiplerinin belirlenen tipte olması gibi kuralları uygulamalıdır.

Eğer data içerisinde SQL Injection, XSS pattern vb. atak stringleri içeriyorsa bu data blacklist helper’dan geçirilmelidir. Proje içerisinde bir blacklist pattern string helper yazılmalı, bu duruma sebep olan IP’ler süre bazlı kısıtlanabilmelidir.

---

IP Kısıtlama Politikası

Projede şüpheli IP’lerin veya IP bloklarının geçici veya kalıcı olarak banlanması sağlanmalıdır.

• Temporary Ban: Şüpheli davranış sonrası belirli süreliğine engelleme (örn. 15 dk).
• Permanent Ban: Sürekli saldırı tespit edilen IP’nin kalıcı olarak yasaklanması.

Eğer proje belirli IP aralıklarından erişilebilecekse (internal bir projeyse) o IP’ler tanımlanmalı ve sadece o IP’lere erişim açık olmalıdır. Bu gibi IP kısıtlamaları ve politikaları için Cloudflare, AWS WAF vb. platformlarda gelişmiş çözümler mevcuttur.

Not: Kimi projelerde coğrafi IP kısıtlaması da uygulanabilir.

---

HTTPS Zorunluluğu

API projesinde requestler sadece HTTPS üzerinden gelmelidir.

API projesine gelen requestlerin HTTPS üzerinden gelme zorunluluğunu kontrol eden bir middleware yazılmalıdır. Her gelen request üzerinde bu requestin HTTPS içerip içermediğini kontrol eden bir helper olmalıdır. Bu yapı middleware dışında sunucu üzerindeki NGINX vb. web serverlar üzerinden de konfigüre edilebilir.

---

Log Yapısı

Proje ihtiyacına göre bir log yapısı kurulmalıdır. Mevcut teknolojiye özel bir log library seçilebilir.
Örn: Node.js → morgan, .NET → log4net.

• Projedeki her request loglanmalıdır: Gelen IP, endpoint, HTTP metodu, gelen request’in header bilgileri vb. datalar log kaydına alınmalı ve veritabanına veya başka bir dosyaya yazılmalıdır.
• Bu genel request loglamasının dışında tüm auth işlemleri ayrıca loglanmalıdır. Örn: giriş, çıkış, yanlış giriş işlemi gibi auth olayları.
• Log seviyeleri info, warn, error seviyelerinde tutulmalıdır.
• Büyük projeler için ElasticSearch vb. teknolojiler kullanılabilir.
• Projedeki kritik loglar ayrıca mail, SMS yoluyla da gönderilebilir.

---

API Security Headers

Projedeki API responselarında header olarak bazı başlıkların eklenmesi gerekmektedir.

Aşağıdaki kütüphaneler bu işlemleri kolayca sağlar:

• Node.js: https://www.npmjs.com/package/helmet
• Python (Flask): https://github.com/GoogleCloudPlatform/flask-talisman

---

API File Güvenliği

Dışarıdan dosya alan API’lerde dosya tipi, boyutu vb. kontroller olmalıdır.

• Dosya türü, dosya boyutu, içerik kontrolü yapılmalıdır.
• Gelen dosya adı direkt olarak kaydedilmemeli, farklı uniq bir isimle saklanmalıdır.
• Dosya doğrudan API projesine değil, bir storage servisine kaydedilmelidir.
• Eğer mümkünse dosya bir antivirüs web servisi ile kontrol edilmelidir.

ÖNEMLİ: Response olarak Content-Disposition: attachment eklenmelidir. Böylelikle dosya tarayıcıda direkt çalışmaz, önce indirilir.

Makale:
https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html

---

Error & Exception Handling

Frontend projesine response olarak hata detayı döndürülmemelidir.

• API projesindeki hatalar için sadece 500 Internal Server Error gibi genel response’lar dönülmelidir.
• Mevcut hatanın direkt dönmesi projeye ait detayları barındıracağından güvenlik açığı oluşturur.
• Development modunda bu kural devre dışı bırakılabilir.

---

Dependency Security

Kullanılan paketlerin güvenlik açıkları düzenli olarak kontrol edilmelidir.

• Node.js: npm audit
• Python: pip audit
• .NET: dotnet list package --vulnerable

Ayrıca GitHub veya ilgili ekosistemin güvenlik danışmanlık dökümanları takip edilmelidir.

---

Data Protection & Privacy

• KVKK kapsamındaki datalar maskelenmeli, parola vb. datalar tek taraflı şifrelenmelidir.
• View olarak gözükecek datalarda, API responselarındaki kimi hassas veriler (IBAN, Soyad vb.) data grid vb. ekranlarda direkt gözükmemesi için maskelenmelidir.
• Kullanıcı şifreleri güçlü crypto kütüphaneleri ile hashlenip veritabanına öyle kaydedilmelidir.

---

ENV Yönetimi

API’de kullanılan JWT secret key, DB connection string, API key, 3rd party servis şifreleri gibi tüm kritik veriler kodun içine gömülmemelidir.

• Her projede en az 2 tane .env dosyası olmalıdır:
  • development.env → development ortamında kullanılacak.
  • production.env → production ortamında kullanılacak, repoya dahil edilmemeli ve sadece sunucuda tutulmalıdır.
• Büyük projelerde .env dosyaları yerine cloud tabanlı çözümler tercih edilmelidir:
  • Azure Key Vault, AWS Secrets Manager, vb.

---

Güvenli CORS Politikası

• Sadece izinli domainler ve HTTP metodları CORS policy’ye dahil edilmelidir.
• Header whitelist eklenmeli, API’ye gereksiz header datası gönderilmemelidir.
• Sadece ihtiyaç olan header’lara izin verilmelidir.

---

JWT Politikası

API projelerinde kimlik doğrulama ve yetkilendirme için JWT (JSON Web Token) kullanılmalıdır. JWT kullanımı sırasında aşağıdaki güvenlik politikalarına uyulmalıdır:

• Kısa Ömürlü Access Token → Access token süresi kısa tutulmalıdır (örn. 15 dakika). Kullanıcı sürekli giriş yapmak zorunda kalmasın diye refresh token yapısı kullanılmalıdır.
• Refresh Token Rotation → Refresh token tek kullanımlık olmalıdır. Kullanıldığında yeni bir refresh token üretilmeli, eski token geçersiz hale gelmelidir.
• İmzalama Algoritması → HS256 yerine mümkünse RS256 veya ES256 gibi asimetrik algoritmalar tercih edilmelidir. Token’lar mutlaka strong secret key veya private key ile imzalanmalıdır.
• Token Doğrulama → Backend tarafında token mutlaka doğrulanmalı (signature, exp, nbf, aud, iss).
• Token Saklama → Web uygulamalarında token’lar HttpOnly, Secure, SameSite cookie içerisinde saklanmalıdır. Mobil uygulamalarda secure storage kullanılmalıdır.
• Revocation (Geçersiz Kılma) → Çalınan veya iptal edilmesi gereken token’lar için server tarafında blacklist/denylist tutulmalıdır.
• Ek Güvenlik → Sensitive işlemler (para transferi vb.) için sadece JWT yeterli olmamalı, ek doğrulama (OTP, e-mail, SMS) istenmelidir.