Modern yazılım mimarilerinde sunucu ile istemci arasındaki sınırların belirginleşmesi, arka plandaki servislerin doğrudan internete açılan uç noktalar (endpoints) üzerinden haberleşmesini zorunlu kıldı. Bu mimaride web API güvenliği, yalnızca sistem kaynaklarını yetkisiz tüketimden korumakla kalmaz; aynı zamanda otomasyon araçlarının, üçüncü taraf entegrasyonların ve kullanıcı verilerinin bütünlüğünü garanti altına alan birincil savunma hattını oluşturur. Bir API ucunu güvenli hale getirmek, tek bir güvenlik mekanizmasına bel bağlamak yerine kimlik doğrulama (authentication), yetkilendirme (authorization) ve trafik denetimini kapsayan çok katmanlı bir yaklaşım gerektirir.

API anahtarlarının rolü ve kullanım sınırları

API anahtarları (API keys), sunucuya istek atan istemcinin kimliğini tespit etmek için kullanılan en ilkel ancak yaygın dizgelerdir. Genellikle istemcinin hangi projeye veya hesaba ait olduğunu doğrulamak amacıyla HTTP başlıklarında (X-API-Key veya Authorization) ya da sorgu parametrelerinde (query string) gönderilir.

Bu yöntemin temel zayıflığı, kimlik doğrulama ile yetkilendirmeyi birbirine karıştırmasından kaynaklanır. Bir API anahtarı, isteğin "hangi uygulamadan" geldiğini söyler; isteği yapan "kullanıcının" kim olduğunu veya o anki işlem için geçerli izinlere sahip olup olmadığını doğrulamaz.

Avantajları Riskleri ve Sınırları
Kurulumu ve doğrulaması son derece basittir. İstemci tarafı (frontend/mobil) kodlarda saklandığında kolayca çalınabilir.
Sunucu tarafında minimum işlem yükü oluşturur. Tek başına kullanıcı bazlı detaylı yetkilendirme (RBAC) sağlayamaz.
Geliştirici portalı üzerinden kolayca iptal edilip yenilenebilir. Sorgu parametrelerinde iletildiğinde sunucu erişim loglarına düz metin olarak kaydedilir.

API anahtarlarını güvenli biçimde kullanmak için şu kurallara dikkat edilmelidir:

  • İstemci koduna gömmeyin: Anahtarlar asla açık kaynak repolara, mobil uygulama ikililerine veya tarayıcı tarafında çalışan JavaScript dosyalarına dahil edilmemelidir. Bu tür ortamlarda sunucu taraflı bir ara katman (proxy/backend-for-frontend) üzerinden istek yapılmalıdır.
  • Yetki kapsamını (scope) daraltın: Anahtara yalnızca ihtiyaç duyduğu uç noktalara okuma veya yazma izni verilmeli, genel yönetici yetkileri tanımlanmamalıdır.
  • Düzenli rotasyon uygulayın: Anahtarların belirli periyotlarla yenilenmesini sağlayacak altyapı kurulmalıdır.

Token tabanlı mimariler: JWT ve OAuth 2.0

Durum bilgisi tutmayan (stateless) mikroservis ve modern web yapılarında, her istekte veritabanı sorgusu yaparak oturum kontrolü gerçekleştirmek performans darboğazı yaratır. Bu sorunun çözümü, doğrulanabilir veriyi kendi içinde taşıyan token mimarilerinden geçer.

JSON Web Token (JWT), taraflar arasında güvenli veri aktarımı sağlayan kompakt, URL güvenli bir açık standarttır (RFC 7519). Üç ana bileşenden oluşur:

  1. Header (Başlık): Kullanılan algoritmayı (örneğin HMAC SHA256 veya RSA) ve token türünü belirtir.
  2. Payload (Gövde): Kullanıcı kimliği, rolü ve token'ın geçerlilik süresi (claims) gibi verileri taşır.
  3. Signature (İmza): Header ve Payload verilerinin sunucudaki gizli bir anahtar (secret key) veya özel anahtar (private key) ile imzalanmasıyla üretilir.

JWT'nin şifrelenmiş (encrypted) değil, yalnızca kodlanmış (Base64Url) ve imzalanmış olduğu unutulmamalıdır. İmza, içeriğin yolda değiştirilmediğini garanti eder; ancak token'ı ele geçiren herkes payload içeriğini okuyabilir. Bu nedenle token gövdesine asla parola veya hassas kişisel veri yazılmamalıdır.

Header (Base64Url) . Payload (Base64Url) . Signature

Üçüncü taraf entegrasyonların ve botların sisteme kontrollü erişimi gerektiğinde ise OAuth 2.0 protokolü devreye girer. OAuth 2.0 bir kimlik doğrulama yöntemi değil, yetki devri (authorization delegation) çerçevesidir. Kullanıcı, şifresini üçüncü taraf bir servisle paylaşmadan, o servise kendi adına belirli işlemleri yapma izni verir.

Token mimarisinde güvenliği sağlamlaştıran iki kritik kural bulunur:

  • Kısa ömürlü erişim token'ları (Access Token): Çalınma riskine karşı erişim token'larının ömrü 15 ila 60 dakika gibi kısa sürelerle sınırlandırılmalıdır.
  • Yenileme token'ları (Refresh Token): Kullanıcının sürekli oturum açmasını engellemek için daha uzun ömürlü yenileme token'ları güvenli, HTTP-only çerezlerde veya güvenli sunucu depolarında saklanmalı; her kullanımda eskisi geçersiz kılınarak rotasyona tabi tutulmalıdır.

Web API güvenliği için hız sınırlama ve trafik denetimi

Yetkilendirilmiş bir istemci bile, yanlış yapılandırılmış bir döngü, agresif bir veri kazıma (scraping) botu veya kötü niyetli bir DoS girişimi nedeniyle sistemi kullanılmaz hale getirebilir. Gerçek anlamda web API güvenliği, kimlik doğrulamanın hemen ardından gelen hız sınırlama (rate limiting) stratejileriyle tamamlanır.

Hız sınırlama, belirli bir zaman diliminde bir IP adresinden, API anahtarından veya kullanıcı hesabından kabul edilecek maksimum istek sayısını tanımlar. Eşik aşıldığında sunucu 429 Too Many Requests HTTP durum kodunu döndürerek işlemi reddeder.

Yaygın hız sınırlama algoritmaları şunlardır:

  • Token Bucket (Jeton Kovası): Belli aralıklarla kovaya jeton eklenir. Her istek bir jeton tüketir. Kova boşaldığında istekler reddedilir. Bu yöntem, anlık trafik sıçramalarına (burst) kontrollü biçimde izin verir.
  • Leaky Bucket (Sızdıran Kova): İstekler sabit bir hızda işlenir; gelen trafik ne kadar yoğun olursa olsun sunucuya iletilen istek hızı sabittir. Sistem aşırı yüklerini önlemede etkilidir.
  • Sliding Window Log (Kayan Pencere): İsteklerin zaman damgaları saklanır ve son $N$ saniye içindeki toplam sayı kontrol edilir. En hassas yöntemdir ancak bellek maliyeti yüksektir.

Hız sınırlandırma kuralları uygulanırken istemciye standart yanıt başlıkları sağlanmalıdır. X-RateLimit-Limit (izin verilen limit), X-RateLimit-Remaining (kalan hak) ve Retry-After (tekrar denemek için beklenmesi gereken süre) başlıkları, yasal otomasyon araçlarının ve entegrasyonların sistemi kilitlemeden kendi istek frekanslarını ayarlamalarına olanak tanır.

HMAC ile mesaj bütünlüğü ve yeniden oynatma saldırılarının engellenmesi

Web kancaları (webhooks) ve finansal/otomasyon veri aktarımlarında, isteğin yalnızca yetkili kaynaktan geldiğini bilmek yetmez; iletilen yükün (payload) ağ üzerindeki bir saldırgan tarafından değiştirilmediğinden ve isteğin tekrar tekrar gönderilmediğinden (replay attack) emin olunmalıdır.

HMAC (Hash-based Message Authentication Code), istemci ve sunucunun önceden bildiği paylaşılan bir gizli anahtar (shared secret) ile istek gövdesinin kriptografik hash fonksiyonundan (SHA-256 gibi) geçirilmesi esasına dayanır.

Doğrulama süreci şu adımlarla işler:

  1. Gönderici taraf, istek gövdesini ve mevcut zaman damgasını gizli anahtarla birleştirerek bir hash imzası üretir.
  2. İmza ve zaman damgası HTTP başlığında (X-Signature, X-Timestamp) sunucuya gönderilir.
  3. Alıcı sunucu, aynı verileri kendi elindeki gizli anahtarla tekrar hash'ler.
  4. İki imza sabit zamanlı karşılaştırma (constant-time comparison) yöntemiyle kontrol edilir; böylece zamanlama saldırılarının (timing attacks) önüne geçilir.
Payload + Timestamp + Shared Secret  ==[ SHA-256 ]==> HMAC İmzası

Yeniden oynatma saldırılarını engellemek için, sunucu gelen zaman damgasını kontrol eder. Örneğin 5 dakikadan daha eski olan veya sunucu saatinden ileride olan istekler doğrudan düşürülür. Ayrıca her isteğe benzersiz bir tek kullanımlık değer (nonce) eklenerek, aynı isteğin pencere süresi içinde ikinci kez çalıştırılması engellenebilir.

API savunma katmanları için uygulama çerçevesi

Güvenli bir API altyapısı kurarken tek bir yönteme güvenmek yerine, istek döngüsünün her adımında ayrı bir denetim noktası oluşturulmalıdır. Aşağıdaki çerçeve, üretim ortamındaki servislerin temel güvenlik gereksinimlerini özetler:

  • Taşıma Katmanı Güvenliği: İstisnasız tüm trafik TLS 1.3 protokolü üzerinden şifrelenmeli; güvensiz HTTP bağlantıları engellenmeli ve HSTS (HTTP Strict Transport Security) başlığı zorunlu tutulmalıdır.
  • Giriş Filtreleme ve Doğrulama: Gelen tüm parametreler katı bir şemaya (örneğin JSON Schema) göre tip, uzunluk ve biçim denetiminden geçirilmelidir. Doğrulanmamış girdi, SQL enjeksiyonu veya uzaktan kod çalıştırma açıklarına davetiye çıkarır.
  • Yetki Matrisi Denetimi: Kimlik doğrulandıktan hemen sonra, ilgili kullanıcının istenen nesne üzerinde işlem yapma yetkisi (IDOR - Insecure Direct Object References koruması) kod seviyesinde sorgulanmalıdır.
  • Güvenli Yanıt Başlıkları: API yanıtlarına Content-Type: application/json, X-Content-Type-Options: nosniff ve uygun CORS (Cross-Origin Resource Sharing) politikaları tanımlanmalı; Access-Control-Allow-Origin: * yapılandırmasından kaçınılmalıdır.
  • Detaylı Loglama ve İzleme: Başarısız kimlik doğrulama denemeleri, aşırı hız sınırı ihlalleri ve imza uyuşmazlıkları merkezi bir log sisteminde toplanmalı; hassas parametreler (token, parola, kredi kartı bilgisi) loglara yazılmadan önce filtrelenmelidir.