1. GİRİŞ

API (Application Programming Interface) güvenliği, modern yazılım mimarilerinin temel taşlarından biri haline gelmiştir. Uygulamalar ve servisler arasındaki iletişimin büyük çoğunluğu API'ler üzerinden yürütülür; mobil uygulamalar, web front‑end'ler, üçüncü parti entegrasyonlar ve mikroservisler hepsi API'leri tüketir. Bu nedenle API'lerin güvenli, gözlemlenebilir ve yönetilebilir olması siber saldırılara karşı ilk savunma hattını oluşturur.

Neden bugün önemli?

• Bulut‑native ve mikroservis mimarilerinin yaygınlaşmasıyla, yüzlerce hatta binlerce API uç noktası ortaya çıkıyor.
• Regülasyonlar (GDPR, PCI‑DSS, HIPAA vb.) veri koruma ve erişim kontrolleri konusunda katı gereksinimler getiriyor.
• API'ler dışa açıldığında (third‑party integrations) saldırı yüzeyi artıyor; zayıf bir endpoint tüm platformu riske atabilir.

Kimler için önemli?

• Yazılım mimarları ve güvenlik mühendisleri
• Backend geliştiriciler, SRE ve platform ekipleri
• Ürün yöneticileri ve üçüncü taraf entegrasyon ekipleri

2. KAVRAMSAL TEMELLER

2.1 Temel kavramlar

• Authentication (Kimlik Doğrulama): Kim olduğunu doğrulama süreci (kullanıcı, servis, uygulama).
• Authorization (Yetkilendirme): Kimlik doğrulandıktan sonra hangi kaynaklara hangi yetkilerle erişeceğinin belirlenmesi.
• Confidentiality (Gizlilik): İletilen verinin üçüncü taraflarca okunamamasını sağlamak.
• Integrity (Bütünlük): Verinin değiştirilmediğini garanti etmek.
• Non‑repudiation: Bir işlemi yapan tarafın işlemden geri dönememesi (veya inkar edememesi).

2.2 API Security domain bileşenleri

• Transport security (TLS, mTLS)
• Identity management (OAuth2, OpenID Connect, JWT)
• Access control (RBAC, ABAC, scopes, claims)
• API Gateway ve WAF (Web Application Firewall)
• Secrets management ve key rotation
• Rate limiting, quota ve throttling

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE PRATİKLER

3.1 TLS (Transport Layer Security) — Temel gereksinim

Tüm API trafiği TLS ile şifrelenmelidir (HTTPS). TLS sadece gizlilik sağlamaz; ayrıca server kimlik doğrulaması, optional client auth (mTLS) ve güvenli cipher suite seçimi ile veri bütünlüğünü güvence altına alır. Minimum TLS sürüm politikası belirleyin (ör. TLS 1.2+); zayıf cipher'ları engelleyin ve HSTS ile güçlü istemci davranışı sağlayın.

3.2 Kimlik doğrulama: OAuth2 & OpenID Connect

Modern API'lerde OAuth2, yetkilendirme delegasyonu için standarttır. OpenID Connect (OIDC) ise kimlik (authentication) için OAuth2 üzerine inşa edilmiş bir katmandır. Uygulamada genellikle şu yaklaşımlar kullanılır:

• Client credentials flow: Servis‑to‑servis (machine) iletişiminde kullanılır.
• Authorization code flow (PKCE dahil): Kullanıcı tabanlı uygulamalarda mobil ve web için güvenli olandır.
• Refresh tokens: Uzun süreli oturumlar için; rotate ve revoke mekanizmaları olmalıdır.

3.3 JWT (JSON Web Token) kullanım nüansları

JWT, taşınan claims ile birlikte identity ve authorization bilgisini taşımak için pratik ve yaygındır. Ancak kullanımda dikkat edilmesi gerekir:

• Token boyutu: büyük claim setleri HTTP header/URL için maliyetlidir.
• Expiration (exp) kısa tutulmalı; refresh mekanizmaları güvenli tasarlanmalı.
• Revocation: stateless JWT'lerin iptal edilmesi için blacklist/denylist veya token introspection mekanizmaları gerekir.
• Signing algoritması: RS256 (asymmetric) genelde önerilir; HMAC (HS256) kullanılıyorsa shared secret yönetimi katıdır.

3.4 Authorization: RBAC, ABAC ve policy based control

Yetkilendirme modeli seçimi uygulamanın karmaşıklığına göre yapılır. Role‑based access control (RBAC) basit uygulamalar için yeterlidir; attribute‑based (ABAC) ve policy based yaklaşımlar (ör. OPA — Open Policy Agent) daha esnek ve bağlam duyarlı kararlar verir. Scopes ve claims ile API endpoint seviyesinde granular kontrol sağlayın.

3.5 API Gateway, WAF ve edge güvenliği

API Gateway, authentication, rate limiting, request/response transformation, logging ve gateway düzeyinde caching yetenekleri sağlar. WAF ise injection, XSS, layer7 ataklarına karşı koruma sağlar. Gateway'i composition root olarak düşünün: kimlik, yetki, quota ve öncelikli güvenlik check'leri burada yapılmalıdır.

3.6 Rate limiting, throttling ve quota yönetimi

Rate limiting, Denial‑of‑Service (DoS) ve abuse ataklarını azaltmak için kritik önemdedir. Token bucket / leaky bucket algoritmaları yaygınken per‑client, per‑IP veya per‑tenant kotaları uygulamak gerekir. Throttling politikalarını SLO hedefleri ile uyumlu tasarlayın ve 429 + Retry‑After header ile istemciyi bilgilendirin.

3.7 Secrets management ve key rotation

API anahtarları, client secrets ve TLS özel anahtarları güvenli bir secret store'da saklanmalıdır (KMS, Vault, Key Vault). Otomatik key rotation, kısa ömürlü credential'lar ve audit logging gereklidir. Secrets kodda veya konfigürasyon dosyalarında asla düz metin olarak tutulmamalıdır.

3.8 Input validation ve output encoding

OWASP prensipleri gereği input validation hem client tarafında hem de server tarafında uygulanmalı; schema validation (JSON Schema, Protobuf) ile beklenen veri tipleri ve sınırlar tanımlanmalıdır. Output encoding ile XSS ve injection risklerini azaltın. Güvenlik testleri otomasyonunun parçası olarak fuzzing ve dynamic analysis uygulayın.

3.9 Logging, monitoring ve audit

Güvenlik için yeterli loglama şarttır: authentication event'leri, failed attempts, admin actions ve token lifecycle event'leri kaydedilmelidir. Loglar güvenli şekilde saklanmalı, erişim kontrolleri uygulanmalı ve belirli retention politikalarına göre arşivlenmelidir. SIEM ve anomaly detection (AIOps) entegrasyonu, saldırı tespitini hızlandırır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Stripe — güvenlik odaklı API ürünleri

Stripe, API tasarımında güvenlik ve kullanıcı deneyimini birleştirir: idempotency, güçlü dokümantasyon, client library'lar ve test ortamlarıyla güvenli entegrasyon sağlar. Payment işlemlerinde PCI gereksinimlerini karşılamak için tokenization ve minimal data exposure prensipleri uygulanır.

4.2 Google Cloud & AWS — kimlik ve erişim yönetimi

Büyük bulut sağlayıcıları, servis‑to‑servis kimlik doğrulaması, IAM rolleri, mTLS ve token exchange mekanizmaları sunar. Örneğin Google'ın Workload Identity, Kubernetes pod'larının güvenli şekilde kimlik almasını sağlar. AWS ise IAM rôles ve AWS KMS gibi güçlü gizli yönetim araçları sunar.

4.3 Netflix — güvenli edge ve client resilience

Netflix, API gateway, edge security, client side resilience ve observability entegrasyonları ile yüksek ölçekli güvenliği yöneten bir örnektir. Zero trust ve mTLS, servisler arası kimlik doğrulamada sıkça kullanılır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Doğru uygulandığında operasyonel riskleri, data leak ve abuse senaryolarını ciddi oranda azaltır.
• Güçlü kimlik yönetimi ve audit ile uyumluluk gereksinimleri karşılanır.
• API Gateway ve security stack ile merkezi kontrol, izleme ve hızlı müdahale imkanı sağlar.

Sınırlamalar

• Güvenlik çözümleri ek operasyonel karmaşıklık getirir; yanlış konfigürasyon yeni riskler oluşturabilir.
• Performans maliyeti: token validation, encryption/decryption ve logging latency'yi artırabilir—hot path'ler için optimize edilmelidir.
• Vendor lock‑in: birçok güvenlik çözümü provider‑specific olabilir; portability planlanmalıdır.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Tüm traffic TLS üzerinden olmalı; minimum TLS sürümü tanımlanmalı ve zayıf cipher'lar engellenmeli.
• API Gateway'i güvenlik, rate limiting ve logging için tek yetkili kapı olarak konumlandırın.
• OAuth2/OIDC ile kimlik yönetimi kurun; refresh token rotation ve revocation stratejilerini uygulayın.
• Secrets'i KMS/Vault gibi merkezi bir sistemde saklayın; otomatik rotation ve audit kaydı zorunlu olsun.

Performans optimizasyonu

• Token doğrulamalarını cache'leyin (ör. JWKS caching, introspection caching) ama short TTL kullanın.
• Hot path'lerde asimetrik/signature doğrulama yerine kısa süreli symmetric token'lar veya session cache tercih edilebilir fakat riskler değerlendirilmelidir.
• Log seviyelerini dinamik yönetip, yüksek trafikli dönemlerde örnekleme (sampling) uygulayın.

Güvenlik

• OWASP API Security Top 10 listesini uygulayın ve düzenli penetrasyon testleri yapın.
• Least privilege prensibini uygulayın; token scope'ları ve minimal claim'ler kullanın.
• Fail‑secure ve paranoid default konfigürasyon: başarısızlık halinde erişimi reddetme varsayılsın.

Observability

• TraceId/correlationId ile tüm security event'leri korele edin.
• Anomaly detection ile brute force, credential stuffing ve unusual access pattern'lerini otomatik tespit edin.
• Security runbook'ları ve playbook'ları hazırlayın; incident response tatbikatları yapın.

8. SIK YAPILAN HATALAR

• TLS zorunluluğunu atlamak—bazı endpoint'ler hala HTTP bırakılabiliyor; bu büyük bir güvenlik açığıdır.
• JWT revocation mekanizmasını ihmal etmek—stateless token'ların iptal edilememesi risk oluşturur.
• Secrets'ı kod veya config repo içinde saklamak—bu hatalar veri sızıntılarına yol açar.
• Rate limiting ve WAF'ı devre dışı bırakmak—production'da gerekli korumalar sağlanmadığında DDoS riski artar.

9. GELECEK TRENDLER

1. Zero Trust ve mesh‑based security: Service mesh'ler mTLS, policy enforcement ve observability ile servisler arası güvenliği daha merkezi hale getirecek.
2. Automated secrets & key management: KMS/Vault ile daha otomatik ve auditable key rotation, ephemeral credential'lar yaygınlaşacak.
3. AI‑driven anomaly detection: Güvenlik telemetrisinden otomatik saldırı tespiti ve müdahale önerileri artacak.
4. Standards for token revocation / introspection: Distributed token revocation için yeni standartlar ve altyapılar gelişecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. API'ler neden TLS kullanmalı?

   TLS, veri gizliliği ve bütünlüğünü sağlar; kimlik doğrulama için server sertifikası doğrulaması sunar. HTTPS olmadan veri ağ üzerinde okunabilir ve değiştirilebilir.

2. 2. JWT güvenli mi?

   JWT güvenlidir ancak doğru kullanılmalıdır: kısa expiry, secure signing algoritmaları, revocation stratejileri ve secret/key yönetimi şarttır.

3. 3. OAuth2 mi yoksa mTLS mi tercih edilmeli?

   Use case'e göre. Servis‑to‑servis iletişimde mTLS güçlü mutual auth sağlar; kullanıcı etkileşimli senaryolarda OAuth2/OIDC daha pratiktir.

4. 4. Token revocation nasıl uygulanır?

   Introspection endpoint, denylist/blacklist, token versioning veya short‑lived token + refresh token rotation kombinasyonları kullanılabilir.

5. 5. API Gateway ne işe yarar?

   Gateway authentication, rate limiting, caching, request transformation ve merkezi logging gibi cross‑cutting concern'ları yönetir; güvenlik için ilk savunma hattıdır.

6. 6. Secrets'i nasıl saklamalıyım?

   Managed secret store (Vault, KMS, Key Vault) kullanın; environment variable, config veya kod içinde düz metin saklamayın. Rotation otomatik olsun.

7. 7. Rate limiting hangi seviyede uygulanmalı?

   Per‑client, per‑API ve per‑tenant seviyelerinde düzenlenmeli; SLA ve kullanım desenlerine göre farklı kuota seviyeleri tanımlayın.

8. 8. OWASP API Security Top 10 neden önemli?

   API'lere özgü en yaygın ve kritik tehditleri listeler; güvenlik programınızı bu liste bazında planlamak riskleri azaltır.

Anahtar Kavramlar

TLS

Transport Layer Security — iletişimin şifrelenmesi ve bütünlüğü.

OAuth2

Yetkilendirme delegasyonu protokolü; access token ve refresh token mekanizmaları içerir.

OIDC

OpenID Connect — kimlik doğrulama katmanı, OAuth2 üzerine inşa edilir.

JWT

JSON Web Token — taşınan claim'lerle token temelli auth için kullanılır.

mTLS

Mutual TLS — hem istemci hem sunucu sertifika doğrulamasıyla güçlü kimlik doğrulama.

Öğrenme Yol Haritası

1. 0–1 ay: TLS, HTTPs, temel cryptography (symmetric/asymmetric) ve temel OAuth2 akışlarını öğrenin.
2. 1–3 ay: OpenID Connect, JWT yönetimi, token rotation ve basic API Gateway konfigürasyonları üzerinde pratik yapın.
3. 3–6 ay: mTLS, certificate lifecycle, secrets management (Vault/KMS) ve rate limiting stratejileri üzerine uygulamalı deneyim kazanın.
4. 6–12 ay: Service mesh, zero trust, anomaly detection ve otomatik security pipeline (SAST/DAST) entegrasyonları ile production‑grade security uygulamalarını olgunlaştırın.