Production'da servis işletiyorsanız, saldırı yüzeyiniz API'lerinizdir. Son yılların en çok ses getiren API ihlallerinde egzotik exploit'ler yoktu — çağıranın asla görmemesi gereken nesneleri isteyen sıradan, kurallara uygun istekler vardı. OWASP API Security Top 10 listesinin var olma nedeni, bu hata kalıplarının şaşırtıcı bir tutarlılıkla tekrarlanmasıdır. 2026'da bir API'yi güvence altına almak, kısa bir listeyi titizlikle uygulamak demektir. İşte o liste.

Taşıma Katmanı: TLS 1.2 veya 1.3, Başka Hiçbir Şey

"SSL" on yılı aşkın süredir kullanımdan kalkmış durumda; bir doküman hâlâ SSL diyorsa bunu TLS olarak okuyun ve hangi sürümlerin gerçekten etkin olduğunu kontrol edin. Varsayılan olarak TLS 1.3 sunun, eski istemciler için taban olarak TLS 1.2'yi tutun ve daha eski her şeyi devre dışı bırakın. İstemcilerin asla düz metne düşmemesi için HSTS ekleyin:

# nginx — yalnızca TLS 1.2/1.3, HTTP'ye düşüş yok
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
add_header Strict-Transport-Security "max-age=63072000" always;

Kimlik Doğrulama: OAuth 2.0 ve OIDC, API Anahtarları Kendi Yerinde

Kullanıcıya dönük API'lerde standart, kısa ömürlü access token'lı OAuth 2.0'dır; doğrulanmış kullanıcı kimliği gerektiğinde üzerine OpenID Connect eklenir. Makineden makineye çağrılar için client credentials grant kullanın. API anahtarlarının hâlâ bir rolü var, ama ne olduklarını iyi anlayın: bunlar tanımlayıcıdır, güçlü kimlik doğrulama değil. Düşük riskli endpoint'lerde kullanım ataması ve kota uygulaması için uygundurlar; hassas operasyonlar için bir erişim kontrolü değildirler. Anahtarları düzenli döndürün; URL'lerden ve istemci tarafı koddan uzak tutun. Bu listede yeri olmayan bir şey ise biyometri — parmak izi, bir insanı bir cihaza doğrular; API'nize ulaşan şey yine bir token'dır ve doğrulamanız gereken de o token'dır.

JWT'ler birkaç klasik hatayı bir arada barındırır. Kabul edilen imza algoritmalarını sabitleyin ve alg: none'ı reddedin; her istekte exp, iss ve aud alanlarını doğrulayın; anahtar rotasyonu yeniden deploy gerektirmeden çalışsın diye doğrulama anahtarlarını issuer'ın JWKS endpoint'inden çekin; access token ömürlerini günlerle değil dakikalarla ölçün.

Yetkilendirme: Bir Numaralı API Açığı BOLA

Broken Object Level Authorization, 2019'dan beri OWASP API listesinin zirvesinde ve gerçek dünyada en sık görülen API kusuru olmayı sürdürüyor: başka bir müşteriye ait, kusursuz derecede geçerli bir token taşıyan bir /invoices/8371 isteği. Çözüm gösterişsizdir — nesne sahipliğini her istekte, servisin içinde, veri ilişkilerinin yaşadığı yerde kontrol edin. İki kardeş açık da aynı muameleyi hak ediyor: fonksiyon düzeyinde yetkilendirme (admin olmayan token'larla erişilebilen admin endpoint'leri) ve mass assignment'ın istemciye role veya price gibi asla yazılabilir olmaması gereken alanları set etme imkânı verdiği özellik düzeyinde yetkilendirme. İstemcilerin gönderebileceği özellikleri allow-list'e bağlayın.

Girdiyi Bir Şemaya Karşı Doğrulayın

API'yi OpenAPI ile tanımlayın ve bu şemayı gateway'de veya middleware'de zorunlu kılın: tipler, aralıklar, uzunluklar, formatlar ve bilinmeyen alanların reddi. Injection, API'ler web formlarının yerini aldı diye ortadan kalkmadı — bir veritabanına, bir shell'e veya bir template'e ulaşan her şey hâlâ parametrize edilmelidir. Bu kontrollerle birlikte sıkça anılan output encoding ise aslında API'nizin verisini render eden tarayıcılar için bir XSS savunmasıdır; API'yi değil istemciyi korur, o yüzden onu API tarafı bir kontrol olarak saymayın.

Rate Limiting ve Kötüye Kullanım Kontrolleri

Token'a veya client ID'ye bağlı istemci başına limitler koyun, 429'u Retry-After ile döndürün ve limitleri endpoint bazında ayarlayın — login ve parola sıfırlama rotaları, okuma yollarından çok daha sıkı olmalı. Bu tek kontrol; credential stuffing'i, nesne-ID enumerasyonunu, scraping'i ve OWASP'ın unrestricted resource consumption başlığı altına koyduğu kaynak tüketimi saldırılarını köreltir. Tek bir pahalı sorgunun saldırganın işini onun yerine yapmaması için istek boyutu ve sayfalama üst sınırlarıyla birlikte kullanın.

Kenarda Gateway, İçeride mTLS

Bir API gateway — AWS API Gateway, Kong, Apigee veya Envoy tabanlı bir kurulum — TLS sonlandırma, token doğrulama, şema kontrolleri, rate limit'ler ve WAF entegrasyonunu her serviste yeniden yazmak yerine tek bir yerde doğru yapma imkânı verir. Gateway'in yapamayacağı şey nesne düzeyinde yetkilendirmedir: o mantık servislerde kalır. Servisten servise trafik için, iki tarafın da birbirini doğruladığı mutual TLS kullanın; Istio veya Linkerd gibi bir service mesh ya da bir SPIFFE/SPIRE kurulumu workload sertifikalarını otomatik üretir ve döndürür — mTLS'in gerçek operasyonlarla temasa dayanmasının tek yolu budur.

Son olarak, hepsini enstrümante edin. Gateway ve kimlik doğrulama logları, sahip olduğunuz en yüksek değerli tespit kaynakları arasındadır: bunları SIEM ve tespit pipeline'ınıza akıtın; token anomalilerine ve 401/403 sıçramalarına alarm kurun. Mevcut bir API envanterinin bu kontrol listesine karşı yapılandırılmış bir incelemesini istiyorsanız, SecOps pratiğimizin yaptığı iş tam olarak budur. Platforma özgü sıkılaştırma için AWS'nin API Gateway koruma rehberi sağlam bir referanstır.

Bunun hesaplarınıza karşı kontrol edilmesini ister misiniz? AWS güvenlik değerlendirmemiz ISO 27001, SOC 2, NIS2 ve DORA'ya eşlenmiş 98 maddeyi kapsar — sabit fiyat, kanıtlar dahil.

Etiketler: #APIGüvenliği #OAuth2 #mTLS #OWASP