REST API güvenlik adımları - Kapsamlı Bakış

# REST API Güvenliği: Kapsamlı Bir Koruma Rehberi Modern yazılım mimarisinin bel kemiğini oluşturan REST API'ler, mobil uygulamalardan mikroservisler...

REST API güvenlik adımları - Kapsamlı Bakış

REST API Güvenliği: Kapsamlı Bir Koruma Rehberi

Modern yazılım mimarisinin bel kemiğini oluşturan REST API'ler, mobil uygulamalardan mikroservislere, IoT cihazlarından üçüncü parti entegrasyonlara kadar her yerde karşımıza çıkıyor. Ancak bu yaygınlık, beraberinde ciddi bir güvenlik yükümlülüğü getiriyor. OWASP'ın API Security Top 10 listesi her yıl güncellenirken, veri ihlallerinin önemli bir kısmı doğrudan API katmanındaki zafiyetlerden kaynaklanıyor.

Bu rehberde, bir REST API'yi baştan sona güvenli hale getirmek için izlemeniz gereken adımları katman katman ele alacağız. Amacım sadece bir kontrol listesi sunmak değil; her adımın neden gerekli olduğunu ve pratikte nasıl uygulandığını göstermek.


1. Kimlik Doğrulama (Authentication): Kapıyı Kim Açıyor?

Her API isteğinin ilk sorusu şudur: "Bu isteği yapan kim?" Kimlik doğrulama, güvenlik zincirinin ilk ve en kritik halkasıdır.

Token Tabanlı Yaklaşımı Benimseyin

Session tabanlı kimlik doğrulama, dağıtık sistemlerde ölçeklenme sorunları yaratır. Bunun yerine JWT (JSON Web Token) veya OAuth 2.0 / OpenID Connect gibi standartları tercih edin.

  • Kısa ömürlü access token (5-15 dakika) kullanın
  • Refresh token mekanizmasıyla uzun oturumları yönetin
  • Token'ları HttpOnly, Secure, SameSite cookie'lerde veya güvenli bellek alanlarında saklayın
  • JWT kullanıyorsanız asla alg: none kabul etmeyin ve algoritmayı sunucu tarafında sabitleyin

API Anahtarları Yetersizdir

API anahtarları yalnızca "hangi uygulama" sorusunu yanıtlar, "hangi kullanıcı" sorusunu değil. Kullanıcı bağlamı gerektiren her senaryoda OAuth 2.0 veya en azından imzalı token kullanın.

// Kötü örnek: Algoritma istemciden geliyor
const decoded = jwt.verify(token, secret); 

// İyi örnek: Algoritma sabitlenmiş
const decoded = jwt.verify(token, secret, { algorithms: ['RS256'] });

2. Yetkilendirme (Authorization): Kim Neyi Yapabilir?

Kimlik doğrulama "kim olduğunuzu", yetkilendirme ise "ne yapabileceğinizi" belirler. Bu ikisini karıştırmak, en sık görülen API güvenlik açıklarından biridir.

BOLA ve BFLA'ya Dikkat

OWASP API Top 10'un ilk sırasında BOLA (Broken Object Level Authorization) yer alıyor. Kullanıcı A, /api/orders/123 isteğiyle Kullanıcı B'nin siparişini görebiliyorsa, ciddi bir yetkilendirme açığı var demektir.

  • Her kaynak erişiminde sahiplik kontrolü yapın
  • Rol tabanlı (RBAC) veya özellik tabanlı (ABAC) modeller kullanın
  • Varsayılan olarak reddet (deny by default) politikası uygulayın
# Kötü örnek: Sadece ID ile getir
order = Order.query.get(order_id)
return order.to_dict()

# İyi örnek: Sahiplik kontrolü
order = Order.query.filter_by(id=order_id, user_id=current_user.id).first()
if not order:
    abort(404)  # 403 yerine 404, bilgi sızdırmaz
return order.to_dict()

İpucu: Yetkisiz erişimlerde 403 Forbidden yerine 404 Not Found döndürmek, kaynak varlığı hakkında bilgi sızmasını engeller.


3. Taşıma Katmanı Güvenliği: Yolda Kimse Dinlemesin

HTTPS Zorunlu Olmalı

HTTP üzerinden çalışan bir API, ağdaki herkese açık bir davetiye gibidir. TLS 1.2 veya üzeri kullanın ve HTTP isteklerini HTTPS'e yönlendirin.

  • HSTS (HTTP Strict Transport Security) başlığını ekleyin
  • Zayıf şifreleme paketlerini (RC4, 3DES) devre dışı bırakın
  • Sertifika pinleme (certificate pinning) değerlendirin

Güvenlik Başlıkları

Aşağıdaki HTTP başlıkları API yanıtlarınıza mutlaka eklenmelidir:

Başlık Amaç
Strict-Transport-Security Tarayıcıyı HTTPS'e zorlar
X-Content-Type-Options: nosniff MIME sniffing'i engeller
X-Frame-Options: DENY Clickjacking'i önler
Content-Security-Policy XSS yüzeyini daraltır
Cache-Control: no-store Hassas verilerin önbelleğe alınmasını engeller

4. Girdi Doğrulama ve Enjeksiyon Önleme

API'ye gelen her veri, potansiyel bir saldırı vektörüdür. "İstemciye güvenme" prensibi burada altın kuraldır.

Şema Tabanlı Doğrulama

Gelen tüm istekleri katı bir şemaya göre doğrulayın. JSON Schema, OpenAPI spesifikasyonları veya kütüphane düzeyinde doğrulama araçları kullanın.

// Express + Joi örneği
const schema = Joi.object({
  email: Joi.string().email().required(),
  age: Joi.number().integer().min(18).max(120).required()
});

const { error, value } = schema.validate(req.body);
if (error) return res.status(400).json({ error: error.details });

SQL Enjeksiyonunu Önleyin

  • Parametreli sorgular veya ORM kullanın
  • Dinamik sorgu oluşturmayın
  • Veritabanı kullanıcısına en az yetki prensibi uygulayın

NoSQL Enjeksiyonunu Unutmayın

{ "username": { "$ne": null } } gibi payload'lar MongoDB sorgularını manipüle edebilir. Girdi tiplerini katı biçimde doğrulayın.


5. Hız Sınırlama (Rate Limiting) ve Kaynak Koruma

Bir API, sınırsız istek kabul ediyorsa hem DDoS hem de brute-force saldırılarına açıktır.

Katmanlı Sınırlama Stratejisi

  • Global limit: IP başına dakikada X istek
  • Kullanıcı bazlı limit: Token başına saatte Y istek
  • Endpoint bazlı limit: Login gibi hassas uçlarda daha sıkı kurallar
  • Maliyet tabanlı limit: Ağır işlemler için farklı kotalar
# Nginx örneği
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    limit_req_status 429;
}

Ek Koruma Katmanları

  • Pagination zorunluluğu: ?limit=10000 gibi istekleri reddedin
  • İstek boyutu sınırı: Büyük payload'ları erken kesin
  • Zaman aşımı: Uzun süren istekleri sonlandırın

6. Hassas Veri Sızıntısını Önleme

API yanıtları, gereğinden fazla bilgi döndürdüğünde saldırgana istemeden yol haritası çizersiniz.

Aşırı Veri İfşası (Excessive Data Exposure)

  • Yanıtlarda sadece gerekli alanları döndürün
  • Hassas alanları (şifre hash'i, iç ID'ler, dahili notlar) filtreleyin
  • DTO (Data Transfer Object) veya serializer kullanın
# Kötü: Tüm model dönüyor
return jsonify(user.__dict__)

# İyi: Sadece gerekli alanlar
return jsonify({
    "id": user.public_id,
    "name": user.name,
    "email": user.email
})

Hata Mesajlarını Sadeleştirin

Stack trace, SQL hataları veya dahili dosya yolları asla istemciye dönmemelidir. Kullanıcıya genel bir mesaj, log'a ise detaylı bilgi yazın.


7. Günlükleme, İzleme ve Olay Müdahalesi

Güvenlik, önleme kadar tespit ve müdahale ile ilgilidir.

Neyi Loglamalı?

  • Tüm kimlik doğrulama denemeleri (başarılı/başarısız)
  • Yetkilendirme reddi olayları
  • Şüpheli girdi kalıpları
  • Rate limit ihlalleri
  • Kritik kaynak değişiklikleri

Neyi Loglamamalı?

  • Şifreler, token'lar, API anahtarları
  • Kredi kartı numaraları, TC kimlik numaraları
  • Kişisel verilerin tamamı (KVKK/GDPR uyumu)

İzleme Altyapısı

  • SIEM çözümleriyle anormal davranış tespiti
  • Anomali tespiti: Alışılmadık saatlerde, coğrafyalarda veya hacimlerde istekler
  • Alarm mekanizmaları: Belirli eşikler aşıldığında otomatik uyarı

8. API Versiyonlama ve Yaşam Döngüsü

Güvenlik, yalnızca yeni özelliklerle değil, eski zafiyetlerin kapatılmasıyla da ilgilidir.

  • Versiyonlama stratejisi belirleyin (/v1/, /v2/)
  • Eski versiyonlar için kullanım sonlandırma (deprecation) takvimi yayınlayın
  • Güvenlik yamalarını tüm aktif versiyonlara uygulayın
  • Kullanımdan kaldırılan uçları izleyin ve engelleyin

9. Üçüncü Parti Bağımlılıkları Yönetin

API'niz, kullandığınız kütüphaneler kadar güvenlidir.

  • SCA (Software Composition Analysis) araçlarıyla zafiyet taraması yapın
  • Dependabot, Snyk gibi araçlarla otomatik güncelleme
  • Kullanılmayan bağımlılıkları kaldırın
  • Lisans ve güvenlik açısından kütüphane seçimini titizlikle yapın

10. Güvenlik Testleri: Kendi Kapınızı Kendiniz Çalın

Son adım, tüm bu önlemlerin gerçekten çalıştığını doğrulamaktır.

Test Türleri

  • SAST: Kaynak kod analizi
  • DAST: Çalışan uygulamaya yönelik dinamik testler
  • IAST: Etkileşimli testler
  • Penetrasyon testi: Yılda en az bir kez bağımsız uzman görüşü
  • Fuzzing: Rastgele girdilerle sınır durumlarını zorlama

Sürekli Entegrasyon

Güvenlik testlerini CI/CD hattınıza zorunlu adım olarak ekleyin. Zafiyet tespit edildiğinde dağıtım otomatik durmalıdır.


Sonuç: Güvenlik Bir Ürün Değil, Süreçtir

REST API güvenliği, tek seferlik bir yapılacaklar listesi değil; sürekli iyileştirilen bir disiplindir. Bugün güvenli olan bir API, yarın yeni bir zafiyetle karşılaşabilir. Bu nedenle:

  • Savunma derinliği ilkesini benimseyin; tek bir kontrolün sizi koruyacağını varsaymayın
  • En az yetki prensibini her katmanda uygulayın
  • Loglayın, izleyin, öğrenin ve olaylardan ders çıkarın
  • OWASP API Security Top 10 listesini düzenli olarak gözden geçirin
  • Ekibinizde güvenlik farkındalığı kültürü oluşturun

Unutmayın: Saldırganlar kapınızı bir kez çalmakla yetinmez. Siz de savunmanızı bir kez kurmakla yetinmemelisiniz.

İLGİLİ İÇERİKLER

Bunları da Okumak İsteyebilirsiniz