Kurumsal API Güvenliği ve Rate Limiting Politikaları

Bir API'yi internete açmak birkaç endpoint yayınlamaktan çok daha fazlasıdır. Trafik büyüdüğünde saldırı, yanlış kullanım, credential sızıntısı, yetki hatası ve beklenmeyen maliyet aynı anda ortaya çıkabilir. On yıllık backend ve API altyapısı çalışmalarında gördüğüm en yaygın hata, güvenliği yalnız JWT doğrulaması ve IP bazlı rate limit ile çözmeye çalışmaktır. Kurumsal API Güvenliği ve Rate Limiting Politikaları doğru tasarlandığında authentication, authorization, trafik kontrolü, abuse detection ve gözlemlenebilirlik tek bir savunma modeli içinde çalışır. Bu rehberde kurumsal API güvenliği nasıl sağlanır, API rate limiting politikası nasıl oluşturulur ve API güvenliğinde rate limiting authentication authorization ve API key yönetimi nasıl birlikte ele alınmalıdır sorularını üretim bakışıyla adım adım inceleyeceğiz.

Kurumsal API Güvenliği Nedir?

Kurumsal API güvenliği, API'lerin kim tarafından, hangi yetkiyle, hangi hızda ve hangi veri kapsamına erişebileceğini kontrollü biçimde yönetmektir. Güvenlik yalnız request'in kimliğini doğrulamakla bitmez. Object-level authorization, payload validation, rate limiting ve audit logging de aynı mimarinin parçalarıdır. Public, partner ve internal API'ler farklı risk profilleri taşır. Bu nedenle tek tip policy yerine risk ve kullanım bağlamına göre katmanlı güvenlik uygulanmalıdır.

API Güvenliği Neden Klasik Web Güvenliğinden Farklıdır?

API'ler çoğu zaman kullanıcı arayüzü olmadan doğrudan veri ve business operation sunar. Saldırgan HTML sayfasını değil request formatını hedefler. Automated client yüksek hızda enumeration veya scraping yapabilir. Authorization hataları kullanıcı arayüzünde görünmeyen veri sızıntılarına yol açabilir. Bu yüzden API güvenliği endpoint, object ve business flow seviyesinde ele alınmalıdır.

API'ler Neden Kurumsal Saldırı Yüzeyinin Kritik Parçasıdır?

Kurumsal sistemler mobil uygulama, web frontend, partner ve internal service trafiğini API üzerinden taşır. Bu durum API'yi business data'ya doğrudan geçiş noktası haline getirir. Eski veya belgelenmemiş endpoint'ler saldırgan için ek fırsat oluşturabilir. Credential ele geçirildiğinde geniş veri erişimi mümkün olabilir. Envanter ve owner yönetimi bu yüzden güvenlik kadar önemlidir.

Public, Partner ve Internal API Farkı

Public API bilinmeyen internet client'larından trafik alır ve en geniş abuse yüzeyine sahiptir. Partner API sözleşmeli client'larla çalışır fakat credential sızıntısı riski taşır. Internal API yalnız iç ağda olduğu için otomatik olarak güvenli sayılmamalıdır. Her kategori farklı authentication ve rate limit politikası kullanabilir. Risk sınıflandırması ilk mimari adımlardan biri olmalıdır.

API Security ile API Management Arasındaki Fark

API security erişim, yetkilendirme, kötüye kullanım ve veri korumasına odaklanır. API management ise lifecycle, routing, analytics, developer experience ve quota gibi daha geniş konuları kapsar. İki alan API gateway üzerinde kesişebilir. Ancak gateway ürünü kullanmak tek başına güvenli API anlamına gelmez. Policy, test ve operasyon süreçleri ayrıca kurulmalıdır.

Defense-in-Depth Yaklaşımı

Defense-in-depth aynı tehdidi birden fazla bağımsız kontrolle sınırlandırmayı hedefler. Edge kötü trafiği azaltırken gateway authentication ve rate limiting uygular. Backend service object-level authorization kontrolünü tekrar yapabilir. Database ve downstream sistemleri de kendi kapasite ve erişim sınırlarını korur. Tek katman atlatıldığında diğer kontroller riskin tamamını taşımaya devam eder.

Kurumsal API Güvenlik Mimarisi Nasıl Olmalı?

Sağlıklı bir kurumsal API güvenlik mimarisi client'tan backend'e kadar birden fazla kontrol noktası oluşturur. CDN ve edge katmanı büyük hacimli kötü trafiği erken durdurur. API gateway kimlik doğrulama, rate limiting ve schema kontrolü için merkezi nokta sağlar. Identity provider ve authorization policy engine kimlik ile yetki kararlarını ayrıştırır. Backend, service mesh ve SIEM katmanları ise iç servis trafiği ve olay görünürlüğünü tamamlar.

Client

Client güvenlik modelinin ilk parçasıdır ancak güvenilir kabul edilmemelidir. Mobil veya web client içindeki değerler saldırgan tarafından değiştirilebilir. API key gibi gizli bilgiler public client içine gömülmemelidir. Client retry ve 429 davranışına uymalıdır. Güvenlik enforcement her zaman server tarafında yapılmalıdır.

CDN / Edge

CDN ve edge kötü trafiği origin'e ulaşmadan azaltabilir. IP, ASN ve coğrafi sinyaller burada kullanılabilir. DDoS saldırılarında backend'in connection kapasitesini korur. Basit rate limit ve bot filtreleri edge seviyesinde etkilidir. User-level authorization gibi business context ise daha iç katmanlarda uygulanmalıdır.

WAF ve Bot Protection

WAF bilinen saldırı pattern'lerini ve riskli request özelliklerini filtreleyebilir. Bot protection otomatik trafik davranışını analiz eder. Credential stuffing veya scraping yalnız IP limit ile durdurulamayabilir. Device ve davranış sinyalleri ek koruma sağlar. WAF kuralları application authorization kontrolünün yerine geçmemelidir.

API Gateway

API gateway kurumsal API trafiği için merkezi enforcement noktasıdır. Authentication, token validation ve rate limiting burada uygulanabilir. Route ve policy standardizasyonu sağlar. Logging ile her request ortak metadata kazanabilir. Gateway yüksek erişilebilir olmalı ve tek hata noktası haline gelmemelidir.

Identity Provider

Identity provider kullanıcı ve machine identity doğrulamasını merkezi yönetir. OAuth ve OIDC token'ları burada üretilebilir. MFA ve credential politikası bu katmanda uygulanabilir. API yalnız doğrulanmış issuer tarafından üretilen token'ı kabul etmelidir. Identity provider'ın availability hedefi API altyapısıyla uyumlu olmalıdır.

Authorization Policy Engine

Policy engine kullanıcının belirli kaynağa veya action'a erişip erişemeyeceğine karar verebilir. RBAC, ABAC veya relation tabanlı model kullanılabilir. Policy koddan ayrılarak merkezi versionlanabilir. Backend gerekli object context'i engine'e iletir. Karar latency'si request path içinde ölçülmelidir.

Backend Services

Backend gateway'in yaptığı kontrolleri tamamen güvenilir varsaymamalıdır. Object ownership ve business permission burada tekrar doğrulanabilir. Sensitive endpoint kendi rate ve concurrency sınırını uygulayabilir. Request context güvenilir identity metadata'sı taşımalıdır. Service authorization failure'ları merkezi olarak loglanmalıdır.

Service Mesh

Service mesh internal API trafiğinde mTLS ve workload identity sağlayabilir. East-west trafik için policy enforcement noktası oluşturur. Service-to-service authorization merkezi hale gelebilir. Mesh iç ağın güvenli olduğu varsayımını ortadan kaldırmaya yardım eder. Ancak application-level object authorization yine backend responsibility'sidir.

Observability ve SIEM

API güvenliği görünür değilse incident sırasında saldırı ile normal trafik ayırt edilemez. Authentication failure, authorization denial ve 429 oranı izlenmelidir. SIEM farklı sistemlerden gelen güvenlik event'lerini ilişkilendirebilir. Correlation ID olay zincirini takip etmeyi kolaylaştırır. Hassas token ve payload bilgilerinin loglara yazılmaması gerekir.

API Gateway Güvenlik Mimarilerinde Ne İşe Yarar?

API gateway birçok ortak güvenlik politikasını merkezi hale getirir. Farklı backend ekiplerinin aynı authentication ve rate limiting standardını kullanmasını sağlar. Schema validation ve TLS termination gibi işleri application kodundan ayırabilir. Routing ve gözlemlenebilirlik de aynı noktada standardize edilir. Buna rağmen object authorization ve business abuse kontrolleri yalnız gateway'e bırakılamaz.

Merkezi Authentication

Gateway access token veya API key doğrulamasını merkezi yapabilir. Backend servislerinin farklı auth implementasyonu yazması gerekmez. Issuer ve audience kontrolleri standardize edilir. Hatalı token backend'e ulaşmadan reddedilir. Auth policy değişikliği merkezi rollout ile uygulanabilir.

Authorization Enforcement

Coarse-grained authorization gateway seviyesinde uygulanabilir. Scope veya route-level role kontrolü buna örnektir. Object ownership gibi data context isteyen karar backend'de yapılmalıdır. Gateway policy engine ile merkezi PDP kullanabilir. Yetki kontrolü kimlik doğrulamadan ayrı düşünülmelidir.

Rate Limiting

Gateway consumer veya endpoint bazlı request hızını sınırlandırabilir. API key, user ID veya tenant ID limit anahtarı olabilir. Distributed counter store birden fazla gateway node arasında ortak state sağlar. 429 response standardize edilebilir. Sensitive endpoint'ler normal API'den farklı limit kullanmalıdır.

Schema Validation

Gateway OpenAPI veya JSON Schema üzerinden payload formatını doğrulayabilir. Büyük array veya aşırı string uzunluğu erken reddedilebilir. Unknown field kabulü sınırlandırılabilir. Bu kontrol backend parser ve database yükünü azaltır. Schema validation authorization'ın yerine geçmez.

TLS Termination

Gateway client TLS bağlantısını sonlandırabilir. Certificate yönetimi merkezi hale gelir. Internal hop için yeniden TLS kullanılmalıdır. mTLS gerekiyorsa client certificate kontrolü gateway'de yapılabilir. Plaintext backend bağlantısı yalnız güvenli kabul edilmemelidir.

Routing

Gateway version ve service bazlı route yönetir. Canary deployment veya emergency endpoint disablement kolaylaşır. Deprecated API trafiği burada görülebilir. Route policy yanlış yapılandırılırsa güvenlik bypass oluşabilir. Configuration review ve test bu nedenle önemlidir.

Logging ve Tracing

Gateway request metadata'sını standart log formatına dönüştürebilir. Consumer, endpoint ve rate limit sonucu kaydedilebilir. Authorization header redaction uygulanmalıdır. Distributed trace için correlation ID eklenebilir. Log pipeline güvenlik analizine uygun retention kullanmalıdır.

API Gateway Tek Güvenlik Katmanı Olmalı mı?

Hayır, gateway yalnız katmanlardan biridir. Gateway bypass edilen internal route veya compromised service farklı risk yaratabilir. Backend object-level authorization'ı kendisi doğrulamalıdır. Edge ve service mesh de ayrı kontroller sunar. Kurumsal güvenlik tek ürüne bağımlı olmamalıdır.

API Authentication ve Authorization Arasındaki Fark

Authentication request'i yapan kimliği belirler. Authorization ise bu kimliğin belirli resource veya action üzerinde ne yapabileceğini belirler. Kimliği doğrulanmış kullanıcı her veriye erişemez. Bu ayrım özellikle BOLA açıklarını anlamak açısından kritiktir. Merkezi AuthN ve service-level AuthZ birlikte kullanılabilir.

Authentication: Kim Arıyor?

Authentication kullanıcı, servis veya partner kimliğini doğrular. Password, token, certificate veya signed request kullanılabilir. Başarılı doğrulama güvenilir principal üretir. Principal ID downstream context'e taşınır. Bu işlem permission kararı vermez.

Authorization: Neye Erişebilir?

Authorization principal'ın belirli action'ı yapıp yapamayacağını kontrol eder. Role, attribute veya relationship kullanılabilir. Aynı kullanıcı bir tenant içinde admin, diğerinde normal user olabilir. Resource ID değiştirilirse ownership tekrar doğrulanmalıdır. Policy her request'te business context ile çalışabilir.

Authentication Başarılıysa Her Kaynağa Erişim Verilir mi?

Hayır, authentication yalnız kimliği kanıtlar. Kullanıcının başka bir müşteri hesabına erişim hakkı olduğu anlamına gelmez. Endpoint içindeki object ID ayrıca yetkilendirilmelidir. Backend data query'si tenant veya owner koşulu taşımalıdır. Bu kontrol yapılmazsa BOLA açığı oluşabilir.

Merkezi AuthN + Dağıtık AuthZ Modeli

Authentication identity provider veya gateway üzerinden merkezi yürütülebilir. Authorization ise business context'e yakın backend servislerinde uygulanabilir. Ortak policy engine karar standardı sağlar. Böylece her service kendi rule dilini icat etmek zorunda kalmaz. Policy audit ve versioning merkezi tutulabilir.

API Authentication Yöntemleri

API authentication yöntemi client türüne ve risk seviyesine göre seçilmelidir. API key basit server-to-server tanımlama için yeterli olabilir. OAuth ve OIDC kullanıcı veya delegated access senaryolarında daha güçlü model sunar. mTLS service identity ve yüksek güvenli partner entegrasyonlarında kullanılabilir. Tek authentication yöntemi tüm API türleri için uygun değildir.

API Key

API key client application'ı tanımlayan statik credential olarak kullanılabilir. User identity taşımayabilir. Rotation ve revocation desteklenmelidir. Key server-side secret store içinde tutulmalıdır. Public frontend içinde gizli tutulabileceği varsayılmamalıdır.

OAuth 2.0

OAuth 2.0 delegated authorization için standart framework sunar. Client access token kullanarak API'ye belirli scope ile erişebilir. Grant type client tipine göre seçilir. Token süresi kısa tutulabilir. Refresh token ayrı risk profiline sahiptir.

OpenID Connect

OIDC OAuth üzerine identity katmanı ekler. ID token kullanıcının authentication sonucunu temsil eder. API access için access token kullanılmalıdır. Client login flow OIDC ile standardize edilir. Issuer ve nonce kontrolleri doğru yapılmalıdır.

JWT

JWT signed token formatıdır, başlı başına authentication protokolü değildir. Access token veya ID token formatı olarak kullanılabilir. Signature validation zorunludur. exp, iss ve aud gibi claim'ler kontrol edilmelidir. Token payload gizli bilgi saklamak için uygun değildir.

mTLS

Mutual TLS hem server hem client certificate doğrulaması yapar. Service-to-service veya partner API için güçlü identity sağlar. Certificate lifecycle yönetimi gerekir. Rotation otomatik olmalıdır. mTLS user-level authorization'ın yerine geçmez.

Signed Requests

Request body ve metadata secret veya private key ile imzalanabilir. Webhook veya yüksek güvenli partner entegrasyonlarında kullanışlıdır. Timestamp ve nonce replay saldırısını azaltır. Canonicalization formatı açık tanımlanmalıdır. Signature verification failure ayrıntılı olarak loglanmalıdır.

Hangi Yöntem Hangi API Türüne Uygundur?

Public user API için OAuth ve OIDC çoğu zaman iyi başlangıçtır. Simple partner integration API key veya signed request kullanabilir. High-security partner bağlantısında mTLS eklenebilir. Internal service trafiğinde workload identity tercih edilebilir. Seçim client capability ve risk üzerinden yapılmalıdır.

API Key Ne Zaman Kullanılmalı?

API key basit machine-to-machine entegrasyonlarda düşük operasyon maliyeti sunar. Ancak user authorization veya güçlü identity proof gerektiğinde tek başına yeterli değildir. Key her environment için ayrı olmalıdır. Rotation ve revocation otomasyonu bulunmalıdır. Key bazlı rate limit abuse ve maliyet kontrolüne yardım eder.

Server-to-Server Entegrasyon

Backend service sabit partner API'ye bağlanıyorsa API key kullanılabilir. Credential client-side uygulamaya sızmaz. TLS zorunludur. Key belirli route veya scope ile sınırlandırılabilir. Daha yüksek riskte OAuth client credentials veya mTLS tercih edilebilir.

API Key'in Sınırları

API key genellikle credential sahibi kullanıcının kim olduğunu göstermez. Key sızdığında onu kullanan herkes aynı yetkiye sahip olur. Fine-grained authorization zordur. Rotation yapılmazsa yıllarca geçerli kalabilir. Bu nedenle least privilege ve monitoring gerekir.

API Key Rotation

Key belirli periyotlarda yenilenmelidir. Zero downtime rotation için eski ve yeni key kısa süre birlikte kabul edilebilir. Kullanılmayan eski key daha sonra revoke edilir. Secret manager distribution süreci otomatikleştirebilir. Rotation failure partner entegrasyonunu kesmemelidir.

Environment Bazlı Key'ler

Development, staging ve production aynı key'i kullanmamalıdır. Bir environment sızıntısı diğerini etkilememelidir. Quota ve permission ayrı tanımlanabilir. Production key staging loglarına düşmemelidir. Environment isolation audit sürecini kolaylaştırır.

Key'in Client-Side Kodda Saklanmaması

Browser veya mobil uygulama içindeki secret gerçek secret değildir. Kullanıcı binary veya network request üzerinden key'i çıkarabilir. Client-side uygulama backend proxy veya user token kullanmalıdır. Public identifier secret ile karıştırılmamalıdır. Sızmış key rate limit bypass veya maliyet yaratabilir.

Key Başına Rate Limit

Her API key kendi quota ve RPS sınırına sahip olabilir. Partner davranışı birbirinden izole edilir. Noisy client tüm backend'i tüketemez. Contractual limit gateway üzerinde uygulanabilir. Key rotate olduğunda quota continuity politikası düşünülmelidir.

OAuth 2.0 ve OpenID Connect

OAuth 2.0 authorization delegation, OIDC ise authentication identity için kullanılır. İki standart birlikte user-facing API güvenliğinde güçlü temel oluşturur. Authorization Code + PKCE public client için yaygın güvenli modeldir. Client Credentials machine-to-machine erişimde kullanılır. Scope tasarımı token'ın erişim yüzeyini minimum tutmalıdır.

OAuth 2.0 Ne Çözer?

OAuth resource owner adına sınırlı access token üretmeyi sağlar. Client kullanıcının ana credential'ını API'ye taşımaz. Scope erişim kapsamını belirler. Token kısa süreli tutulabilir. Revocation ve consent modeline göre farklı flow'lar uygulanabilir.

OIDC Ne Çözer?

OIDC kullanıcının kimliğini standart biçimde doğrular. ID token client uygulamanın authentication sonucunu anlamasına yardımcı olur. User profile claim'leri standardize edilebilir. API authorization access token üzerinden yapılmalıdır. OIDC session security ayrıca ele alınmalıdır.

Authorization Code + PKCE

Authorization code flow public client için PKCE ile güçlendirilir. Code interception saldırısına karşı verifier kullanılır. Access token browser URL'sine doğrudan taşınmaz. Redirect URI sıkı doğrulanmalıdır. State ve nonce kontrolleri ayrıca uygulanmalıdır.

Client Credentials

Client credentials service-to-service erişimde kullanılır. Kullanıcı kimliği yerine application identity temsil edilir. Scope minimum tutulmalıdır. Secret veya private key güvenli saklanmalıdır. Credential rotation otomatik yapılmalıdır.

Device Authorization

Input kapasitesi sınırlı cihazlarda device flow kullanılabilir. Kullanıcı ayrı cihaz üzerinden authorization tamamlar. Polling rate kontrol edilmelidir. Device code kısa ömürlü olmalıdır. Phishing ve code guessing riskleri değerlendirilmelidir.

Refresh Token

Refresh token yeni access token üretmek için kullanılır. Access token'dan daha uzun ömürlü olduğu için daha hassastır. Rotation ve reuse detection uygulanabilir. Public client storage güvenliği önemlidir. Compromise durumunda revoke edilebilmelidir.

Scope Tasarımı

Scope çok geniş tutulursa token compromise etkisi büyür. Çok fazla küçük scope yönetimi zorlaştırabilir. Business capability seviyesinde dengeli model kurulmalıdır. Read ve write scope ayrılabilir. Scope object-level authorization'ın yerine geçmemelidir.

JWT Güvenliği Nasıl Sağlanır?

JWT güvenliği yalnız token'ın parse edilmesiyle sağlanmaz. Signature, algorithm, issuer, audience ve expiration birlikte doğrulanmalıdır. JWKS key rotation mekanizması güvenilir cache ile yönetilmelidir. Access token kısa ömürlü tutulmalıdır. Revocation gereksinimi varsa ek state veya token introspection kullanılabilir.

Signature Validation

JWT signature doğrulanmadan claim'lere güvenilmemelidir. Public key güvenilir issuer kaynağından alınmalıdır. Signature failure anında request reddedilir. Debug amacıyla token içeriği loglanmamalıdır. Library secure default'ları kullanılmalıdır.

Algorithm Pinning

Token header içindeki algoritma kör biçimde kabul edilmemelidir. API önceden izin verilen algoritmaları tanımlamalıdır. Algorithm confusion riskleri bu şekilde azalır. Key type ile algorithm uyumlu olmalıdır. Policy deployment'ta test edilmelidir.

Issuer Kontrolü

iss claim token'ı hangi identity provider'ın ürettiğini belirtir. Beklenen issuer ile birebir doğrulanmalıdır. Aynı public key'e sahip farklı environment token'ı kabul edilmemelidir. Tenant-aware sistemlerde issuer mapping açık olmalıdır. Invalid issuer authentication failure üretmelidir.

Audience Kontrolü

aud claim token'ın hangi API için üretildiğini gösterir. Başka service için oluşturulmuş token kabul edilmemelidir. Multi-audience token riskli olabilir. Gateway ve backend aynı audience policy'sini kullanmalıdır. Test token'ı production API'de geçerli olmamalıdır.

Expiration Kontrolü

Expired token kabul edilmemelidir. Clock skew için küçük tolerans tanımlanabilir. Çok uzun access token ömrü compromise riskini artırır. Refresh mekanizması kullanıcı deneyimini koruyabilir. exp kontrolü tüm verification path'lerinde uygulanmalıdır.

JWKS ve Key Rotation

Identity provider public signing key'leri JWKS üzerinden yayınlayabilir. API key ID üzerinden doğru key'i seçer. Cache süresi rotation hızına uyumlu olmalıdır. Bilinmeyen kid için güvenli refresh yapılabilir. JWKS endpoint outage token verification'ı tamamen durdurmamalıdır.

Short-Lived Access Tokens

Kısa token ömrü sızmış credential'ın kullanım penceresini sınırlar. Çok kısa süre excessive refresh trafiği yaratabilir. Risk seviyesine göre süre belirlenir. Service token ile user token farklı ömür kullanabilir. Rotation strategy monitoring ile desteklenmelidir.

Token Revocation

JWT stateless olduğunda anlık revocation doğal değildir. Blacklist veya session version kontrolü eklenebilir. Çok kritik sistem token introspection kullanabilir. Short-lived token revocation ihtiyacını azaltır. Logout semantiği business requirement'a göre tanımlanmalıdır.

Service-to-Service API Güvenliği

Internal servis trafiği dış client trafiği kadar ciddiye alınmalıdır. Client credentials, mTLS ve workload identity service identity sağlamada kullanılabilir. SPIFFE/SPIRE ve service mesh otomatik certificate ve identity yönetimi sunabilir. Her service yalnız gerekli downstream action'a erişebilmelidir. Compromised service'in blast radius'u least privilege ile sınırlandırılır.

Client Credentials

Service identity OAuth client üzerinden temsil edilebilir. Access token belirli scope taşır. Secret güvenli store içinde tutulur. Token kısa ömürlü olabilir. Service account'ların owner ve rotation politikası bulunmalıdır.

mTLS

Mutual TLS iki service arasında cryptographic identity sağlar. Certificate otomatik yenilenmelidir. SAN veya workload identity mapping kullanılabilir. Network içinde plaintext trafiği azaltır. Authorization yine identity üzerinden ayrıca uygulanmalıdır.

Workload Identity

Workload identity statik secret yerine runtime environment'a bağlı kimlik sunar. Container veya VM belirli service account ile ilişkilendirilir. Secret dağıtımı azalır. Token kısa süreli üretilebilir. Compromised workload yalnız kendi identity yetkilerini taşır.

SPIFFE/SPIRE Yaklaşımı

SPIFFE workload identity için standard identifier modeli sunar. SPIRE identity attestation ve credential dağıtımı sağlayabilir. Service mesh ile entegre edilebilir. Certificate rotation otomatik hale gelir. Organizational trust domain tasarımı dikkat ister.

Service Mesh

Mesh sidecar veya proxy üzerinden mTLS uygulayabilir. East-west traffic policy merkezi yönetilebilir. Service-to-service authorization identity bazlı uygulanabilir. Telemetry ortak format kazanır. Mesh application-level data authorization'ın yerine geçmez.

Least Privilege

Her service yalnız ihtiyacı olan endpoint ve action'a erişmelidir. Wildcard scope kullanımından kaçınılmalıdır. Permission review periyodik yapılır. Kullanılmayan service account revoke edilir. Least privilege lateral movement etkisini azaltır.

API Authorization Modelleri

Authorization modeli organization ve data ilişkisinin yapısına göre seçilmelidir. RBAC role odaklı basit kontrol sağlar. ABAC context ve attribute'lara göre daha esnek karar verir. ReBAC ilişki yoğun ürünlerde güçlü olabilir. OAuth scope ve policy-based authorization bu modelleri tamamlayabilir.

RBAC

Role-Based Access Control kullanıcıya role atar. Admin, editor ve viewer gibi roller kullanılabilir. Basit ve anlaşılırdır. Çok fazla özel durum role explosion yaratabilir. Object ownership için tek başına yeterli olmayabilir.

ABAC

Attribute-Based Access Control kullanıcı, resource ve context attribute'larını kullanır. Department, region veya risk level karar girdisi olabilir. Esneklik yüksektir. Policy debugging daha zor hale gelebilir. Attribute kaynaklarının güvenilir olması gerekir.

ReBAC

Relationship-Based Access Control kullanıcı ile resource arasındaki ilişkiyi kullanır. Workspace member veya document owner buna örnektir. Collaboration ürünlerinde doğal model sunar. Graph tabanlı authorization engine kullanılabilir. Relationship freshness ve consistency önemlidir.

OAuth Scopes

Scope token'ın coarse-grained erişim yetkisini sınırlar. `orders.read` veya `orders.write` gibi capability ifade edebilir. Scope object ID ownership kontrolü yapmaz. Backend daha ayrıntılı karar vermelidir. Çok geniş scope compromise riskini büyütür.

Policy-Based Authorization

Policy engine birden fazla identity ve context bilgisini birlikte değerlendirir. Rule'lar version control altında tutulabilir. Merkezi audit imkanı sunar. Policy latency request path'i etkileyebilir. Cache kullanırken stale authorization riski değerlendirilmelidir.

Model Seçim Matrisi

Küçük ve sabit role yapısında RBAC yeterli olabilir. Context-heavy enterprise sistem ABAC'den faydalanabilir. Collaboration ve hierarchy yoğun ürünlerde ReBAC daha doğal olabilir. OAuth scope dış client yetkisini sınırlandırmak için kullanılabilir. Birden fazla model birlikte uygulanabilir.

Policy as Code ile API Yetkilendirme

Policy as code authorization kurallarını application içine dağılmış condition bloklarından çıkarır. Merkezi karar noktası ve enforcement noktaları oluşturulur. OPA, Cedar veya relationship engine'leri farklı yaklaşım sunabilir. Policy Git üzerinden review ve test edilebilir. Bu model compliance ve audit ihtiyacını da kolaylaştırır.

Merkezi Policy Decision Point

PDP access kararını hesaplayan merkezi mantıktır. Input principal, action, resource ve context içerebilir. Policy version net olmalıdır. Decision log audit için saklanabilir. PDP outage davranışı risk seviyesine göre planlanmalıdır.

Policy Enforcement Point

PEP PDP kararını uygulayan gateway veya backend noktasıdır. Deny kararı request'i durdurur. Enforcement bypass edilememelidir. Context doğru ve güvenilir biçimde PDP'ye iletilmelidir. PEP metric authorization denials'ı göstermelidir.

Open Policy Agent

Open Policy Agent genel amaçlı policy engine yaklaşımı sunar. Rego ile authorization ve configuration policy yazılabilir. Sidecar veya merkezi deployment kullanılabilir. Policy bundle versionlanabilir. Performance ve cache modeli gerçek workload ile test edilmelidir.

Cedar

Cedar authorization policy ifade etmeye odaklanan bir policy dilidir. Principal, action ve resource ilişkisini açık biçimde modelleyebilir. Policy analysis ve validation avantaj sağlayabilir. Application integration ayrı planlanmalıdır. Domain model policy tasarımına doğru yansıtılmalıdır.

SpiceDB

SpiceDB relation tabanlı authorization problemlerinde değerlendirilebilir. User-resource relationship graph tutar. Collaboration ve sharing modeli için güçlü olabilir. Consistency ve latency ihtiyacı test edilmelidir. Permission modelinin domain ile uyumlu olması gerekir.

Version-Controlled Authorization Policies

Authorization policy repository içinde versionlanmalıdır. Pull request review yanlış geniş yetki verilmesini azaltır. Unit ve negative test eklenebilir. Environment promotion kontrollü yapılır. Acil policy değişikliği de audit trail bırakmalıdır.

BOLA Nedir?

BOLA, API güvenliğinde en kritik authorization problemlerinden biridir. Kullanıcı geçerli şekilde login olmuş olsa bile başka kullanıcıya ait object ID üzerinden veri erişebilir. Sorun authentication eksikliği değil object-level authorization eksikliğidir. Her resource erişiminde ownership veya permission doğrulanmalıdır. Negative authorization testleri bu açığı yakalamanın etkili yollarındandır.

Broken Object Level Authorization

BOLA resource kimliğinin authorization kontrolünden bağımsız kullanılmasını ifade eder. `/orders/123` gibi endpoint'te yalnız order ID bulunması yeterli değildir. Request principal'ın bu order'a erişimi kontrol edilmelidir. Database query owner veya tenant filter içermelidir. Authorization failure 403 veya uygun policy sonucu üretmelidir.

ID Değiştirerek Başka Kullanıcının Verisine Erişme

Saldırgan kendi resource ID'sini başka değerle değiştirebilir. Sequential ID enumeration saldırıyı kolaylaştırabilir. UUID kullanmak riski gizler ama çözmez. Backend object permission kontrolü yapmalıdır. Automated negative test farklı kullanıcı resource'larını denemelidir.

Authentication Neden BOLA'yı Önlemez?

Authentication yalnız request'in kimden geldiğini bilir. Hangi object'e erişebileceğini söylemez. Geçerli token saldırganın kendi hesabına ait olabilir. Başka object ID'si gönderildiğinde token yine geçerlidir. Authorization ayrı değerlendirilmediğinde veri sızıntısı oluşur.

Object Ownership Kontrolü

Resource owner ID principal ile karşılaştırılabilir. Multi-tenant sistemde tenant membership ayrıca kontrol edilmelidir. Complex paylaşım modelinde relationship engine kullanılabilir. Query mümkünse authorization condition ile birlikte yapılmalıdır. Fetch-then-check race riskleri incelenmelidir.

Negative Authorization Testleri

Test yalnız başarılı erişimi doğrulamamalıdır. User A'nın User B resource'una erişemediği açıkça test edilmelidir. Role downgrade ve tenant switch senaryoları eklenebilir. Property-level access ayrıca kontrol edilir. CI içinde bu testler sürekli çalıştırılmalıdır.

Diğer Kritik OWASP API Security Riskleri

API güvenliği yalnız BOLA'dan ibaret değildir. Authentication, resource consumption, function authorization ve sensitive business flow abuse gibi farklı riskler bulunur. SSRF ve security misconfiguration backend altyapısını doğrudan etkileyebilir. Inventory eksikliği eski endpoint'lerin unutulmasına yol açar. Third-party API responses da güvenilir kabul edilmemelidir.

Broken Authentication

Weak credential validation veya token handling hesap ele geçirilmesine yol açabilir. Password spraying ve credential stuffing rate limit ile azaltılabilir. Token expiration ve issuer doğrulanmalıdır. MFA riskli akışlarda kullanılabilir. Authentication event'leri davranış analiziyle izlenmelidir.

Broken Object Property Level Authorization

Kullanıcı resource'a erişebilir ancak tüm field'ları görmeye yetkili olmayabilir. Admin-only alan response içinde yanlışlıkla dönebilir. Update request de protected property değiştirebilir. Serialization ve update mapping permission-aware olmalıdır. Schema testleri property seviyesini kapsamalıdır.

Unrestricted Resource Consumption

Client çok büyük payload veya pahalı query ile backend kaynağını tüketebilir. Rate limit yalnız request sayısını ölçerse yetersiz kalır. Payload, query cost ve concurrency sınırlandırılmalıdır. Timeout ve budget uygulanmalıdır. Maliyet metrikleri endpoint bazında izlenmelidir.

Broken Function Level Authorization

Kullanıcı normal endpoint'ten admin operation'a geçebilir. Route-level role kontrolü eksikse problem oluşur. HTTP method değişikliği de test edilmelidir. UI'da buton gizlemek authorization değildir. Backend her function için açık permission kontrolü yapmalıdır.

Unrestricted Access to Sensitive Business Flows

Teknik olarak geçerli request business olarak kötüye kullanılabilir. Ticket satın alma veya coupon kullanımı otomasyonla sömürülebilir. User ve device bazlı hız limitleri gerekir. Bot ve risk scoring eklenebilir. Business operation maliyeti güvenlik politikasına yansıtılmalıdır.

SSRF

API user-supplied URL üzerinden server-side request yapıyorsa SSRF riski oluşur. Internal metadata veya private network hedeflenebilir. Allowlist tercih edilmelidir. Redirect ve DNS rebinding senaryoları düşünülmelidir. Network egress policy ek koruma sağlar.

Security Misconfiguration

Debug endpoint veya varsayılan credential production'da açık kalabilir. CORS ve TLS ayarları yanlış olabilir. Gateway route policy'si eksik olabilir. Configuration as code review süreci riski azaltır. Environment drift düzenli taranmalıdır.

Improper Inventory Management

Organization hangi API'lerin açık olduğunu bilmiyorsa güvenlik politikası eksik kalır. Eski v1 endpoint yeni v2'den daha zayıf auth kullanabilir. Staging API internete açık olabilir. Her API owner, version ve lifecycle bilgisi taşımalıdır. Discovery ve inventory otomasyonu yararlıdır.

Unsafe Consumption of APIs

Third-party API response güvenilir kabul edilmemelidir. Schema validation ve timeout kullanılmalıdır. Provider compromise veya unexpected payload application'ı etkileyebilir. Retry budget provider failure sırasında storm'u önler. Outbound credential minimum yetkiye sahip olmalıdır.

Rate Limiting Nedir?

Rate limiting belirli kimlik veya resource için izin verilen request hızını sınırlandırır. Amaç yalnız saldırıyı engellemek değildir. Fair usage, backend protection ve maliyet kontrolü için de kullanılır. Limit zaman, concurrency veya weighted cost üzerinden uygulanabilir. API rate limiting token bucket sliding window ve fixed window yöntemleri karşılaştırması yapılırken traffic burst ve accuracy gereksinimi dikkate alınmalıdır.

Rate Limit Nasıl Çalışır?

Rate limiter request için bir anahtar üretir. Sayaç veya token state'i bu anahtara göre güncellenir. Policy sınırı aşılırsa request reddedilir veya yavaşlatılır. Distributed sistemde state ortak store üzerinde tutulabilir. Decision latency request path'in parçasıdır.

Neden API Güvenliğinin Parçasıdır?

Authentication başarılı client yine abuse yapabilir. Compromised credential yüksek hızda veri çekebilir. Rate limit blast radius'u sınırlar. Enumeration ve brute force saldırıları yavaşlatılır. Backend kapasitesi güvenlik saldırısından bağımsız olarak korunur.

DoS ve Abuse Koruması

Application-level flood backend thread veya connection pool'u tüketebilir. Rate limit client başına kullanım hızını sınırlar. DDoS için edge protection ayrıca gerekir. Sensitive flow özel eşik kullanmalıdır. Tek limit tüm saldırı türünü durdurmaz.

Fair Usage

Bir client toplam kapasitenin tamamını tüketmemelidir. Tenant veya API key başına quota adil dağılım sağlar. Enterprise müşteriye farklı limit verilebilir. Shared backend noisy neighbor etkisinden korunur. SLA ve quota birbirine bağlanabilir.

Backend Protection

Database veya downstream service belirli concurrency üzerinde doygunlaşabilir. Rate limiter kapasite sınırından önce trafiği keser. Queue büyümesini önler. Load shedding daha genel koruma sağlar. Limit load test sonucuna göre kalibre edilmelidir.

Maliyet Kontrolü

Her request eşit maliyetli değildir. Third-party API veya AI inference doğrudan para harcayabilir. Weighted quota işlem maliyetini temsil eder. Tenant budget aşımı kontrol edilebilir. Denial-of-wallet saldırıları bu şekilde azaltılır.

Rate Limiting, Throttling ve Quota Arasındaki Fark

Rate limit belirli zaman içindeki maksimum request hızını ifade eder. Throttling aşırı trafiği yavaşlatma veya kontrollü işleme anlamına gelebilir. Quota daha uzun dönemli toplam kullanım sınırıdır. Burst limit kısa süreli trafik sıçramasını yönetir. Concurrency limit aynı anda çalışan işlem sayısını sınırlar.

Rate Limit

Örneğin kullanıcı başına saniyede on request sınırı rate limit'tir. Window veya token bucket ile uygulanabilir. Aşım genellikle 429 üretir. Kimlik anahtarı önemlidir. Endpoint riskine göre değer değişir.

Throttling

Throttling trafiği tamamen reddetmek yerine yavaşlatabilir. Queue veya token refill ile pacing sağlanabilir. Backend'e ani burst gitmesini önler. Çok uzun queue kullanıcı latency'sini artırır. Bu nedenle bounded waiting kullanılmalıdır.

Quota

Quota aylık yüz bin request gibi daha uzun dönemli sınırdır. Subscription plan ile ilişkilendirilebilir. Quota bitince yeni istek reddedilebilir. Metering sistemi billing'den ayrı tutulmalıdır. Reset zamanı client'a bildirilebilir.

Burst Limit

Burst limit kısa süreli yüksek request oranına izin verir. Token bucket capacity bu davranışı modelleyebilir. Normal refill rate daha düşük olabilir. Legitimate traffic spike tolere edilir. Aşırı burst backend saturation yaratmamalıdır.

Concurrency Limit

Concurrency limit aynı anda kaç request'in işlenebileceğini belirler. Long-running operation için RPS'den daha anlamlı olabilir. Report veya export endpoint'i buna örnektir. Queue depth ayrıca sınırlandırılmalıdır. Request tamamlandığında slot serbest bırakılır.

Kullanım Senaryolarına Göre Farklar

Login endpoint rate limit ve anti-brute-force kuralı ister. Export endpoint concurrency ve weighted cost ile daha iyi korunabilir. Subscription API quota kullanabilir. Streaming service connection limit uygular. Bir API aynı anda birkaç kontrol kullanabilir.

Rate Limiting ile Circuit Breaker Arasındaki Fark

Rate limiter client traffic'i backend kapasitesine göre sınırlar. Circuit breaker ise downstream sistem hata vermeye başladığında yeni çağrıları geçici olarak durdurur. Load shedding genel saturation altında request reddeder. Bulkhead kaynakları ayrı havuzlara böler. Bu kontroller birlikte kullanıldığında failure propagation ciddi biçimde azalır.

Rate Limiter Client Trafiğini Kontrol Eder

Limiter consumer bazında ne kadar request kabul edileceğini belirler. Sistem sağlıklı olsa bile quota aşımı reddedilebilir. Fair usage ve abuse temel hedeflerdir. Policy consumer identity kullanabilir. Decision downstream health'ten bağımsız olabilir.

Circuit Breaker Downstream Failure'ı Kontrol Eder

Downstream hata oranı yükselirse breaker açılır. Yeni request'ler hızlı fail ederek kaynak tüketmez. Belirli süre sonra half-open test yapılabilir. Failure recovery otomatik olabilir. Client quota ile aynı problem değildir.

Load Shedding

Sistem saturation noktasına yaklaştığında düşük öncelikli request'ler reddedilebilir. Global CPU veya queue depth sinyal olarak kullanılabilir. Rate limit policy'den bağımsız dinamik korumadır. Priority-aware olabilir. User-facing error güvenli ve anlaşılır olmalıdır.

Bulkhead

Bulkhead farklı workload'ları ayrı resource pool'larında tutar. Heavy report login API connection'larını tüketemez. Thread veya connection pool ayrılabilir. Failure blast radius küçülür. Rate limiter her pool'un girişini ayrıca kontrol edebilir.

Bu Kontroller Birlikte Nasıl Kullanılır?

Edge rate limit kötü trafiği azaltır. Application limiter fair usage uygular. Circuit breaker unhealthy downstream çağrısını keser. Bulkhead kritik operation kaynaklarını izole eder. Load shedding sistem tamamen doymadan düşük öncelikli işi reddeder.

Rate Limiting DDoS Koruması Yerine Geçer mi?

Hayır, application rate limiting DDoS korumasının yalnız bir katmanıdır. Büyük network saldırısı request gateway'e ulaşmadan bağlantı kapasitesini tüketebilir. Edge DDoS service ve WAF daha yukarıda çalışır. Bot management application abuse için ek sinyal sağlar. Layered protection farklı saldırı seviyelerini birlikte karşılar.

Application Rate Limit

Application limiter authenticated user veya tenant context'ini bilir. Business operation bazlı limit uygular. Ancak trafik uygulamaya ulaştığı için altyapı kaynağı zaten tüketilmiş olabilir. Massive flood için geç müdahaledir. Yine de credential abuse için değerlidir.

Edge DDoS Protection

Edge infrastructure yüksek hacimli trafiği origin'e ulaşmadan absorbe eder. Network ve transport attack'lara karşı daha uygundur. Anycast ve büyük kapasite avantaj sağlar. Application identity bilgisi sınırlı olabilir. Gateway policy ile birlikte kullanılmalıdır.

WAF

WAF HTTP request pattern'lerini inceleyebilir. Bilinen exploit veya suspicious signature engellenebilir. IP reputation ve custom rule kullanılabilir. Business authorization yapmaz. False positive düzenli izlenmelidir.

Bot Management

Bot management request behavior ve fingerprint sinyallerini değerlendirir. IP rotation kullanan otomasyonu yakalamaya yardım eder. Human-like automation yine zor olabilir. Risk score authentication policy'ye aktarılabilir. Sensitive flow'larda CAPTCHA veya step-up auth kullanılabilir.

Network-Layer Attack

SYN flood veya volumetric traffic application rate limiter'a hiç ulaşmayabilir. Network kapasitesi hedeflenir. Upstream veya edge mitigation gerekir. Firewall tek başına yeterli olmayabilir. Network monitoring ayrıca kurulmalıdır.

Layered Protection

Edge volume attack'ı, WAF malicious request'i, gateway consumer abuse'u ve backend business abuse'u kontrol eder. Her katman farklı context görür. Tek üründe tüm güvenlik garantisi aranmaz. Policy'ler birbirini tamamlar. Incident runbook katmanlar arası koordinasyonu içerir.

Rate Limit Hangi Kimliğe Göre Uygulanmalı?

Rate limit anahtarı API'nin gerçek consumer'ını temsil etmelidir. IP anonymous traffic için faydalı olsa da authenticated sistemlerde tek başına yetersizdir. User, API key, OAuth client ve tenant daha güçlü kimliklerdir. Endpoint ve resource boyutu da eklenebilir. Çoğu kurumsal sistem composite veya hierarchical limit kullanır.

IP Bazlı

Anonymous public endpoint için IP ilk sinyaldir. Basit abuse'u azaltabilir. NAT nedeniyle birçok gerçek kullanıcı aynı IP'yi paylaşabilir. Botnet IP rotation ile limiti aşabilir. Bu nedenle tek güvenlik katmanı olmamalıdır.

Kullanıcı Bazlı

Authenticated request user ID ile limitlenebilir. Token yenilemek limiti sıfırlamamalıdır. Kullanıcının farklı cihazları aynı quota'yı paylaşabilir. Sensitive operation ek IP limiti kullanabilir. Account takeover durumunda blast radius sınırlandırılır.

API Key Bazlı

Partner veya developer API'lerinde key doğal consumer identifier'dır. Her key farklı quota alabilir. Key sızıntısında kullanım tek consumer üzerinde görünür. Rotation quota state'i etkileyebilir. Key owner metadata'sı dashboard'da bulunmalıdır.

OAuth Client Bazlı

OAuth client application identity'sini temsil eder. B2B partner veya backend integration buna göre sınırlandırılabilir. Aynı client içindeki kullanıcılar ayrıca user limiti alabilir. Contractual quota client ID'ye bağlanabilir. Revoked client yeni request kabul etmemelidir.

Tenant Bazlı

SaaS ortamında tenant shared backend capacity kullanır. Tenant-level quota noisy neighbor etkisini azaltır. Büyük enterprise tenant özel limit alabilir. User sub-limit aynı tenant içindeki adaleti sağlar. SLA ve billing planı quota ile ilişkilendirilebilir.

Device Bazlı

Device identifier abuse sinyali olarak kullanılabilir. Public device ID kolay taklit edilebilir. Güçlü device attestation varsa güven artar. User + device kombinasyonu suspicious automation tespitine yardım eder. Device limit privacy açısından dikkatle tasarlanmalıdır.

Endpoint Bazlı

Her endpoint aynı maliyet ve riskte değildir. Login daha katı anti-brute-force limiti ister. Search endpoint daha yüksek CPU tüketebilir. Static metadata endpoint daha yüksek RPS kabul edebilir. Policy route seviyesinde tanımlanmalıdır.

Resource Bazlı

Belirli hesap veya object üzerinde aşırı işlem sınırlandırılabilir. Payment account veya gift card buna örnektir. Saldırgan token veya IP değiştirerek aynı resource'u hedefleyebilir. Resource-level counter bu bypass'ı zorlaştırır. Privacy-sensitive resource key hashlenebilir.

IP Bazlı Rate Limiting'in Sınırları

IP bazlı rate limiting uygulanması kolay olduğu için sık kullanılır. Ancak modern network yapıları gerçek kullanıcı ile IP arasında birebir ilişki kurmaz. NAT, corporate proxy ve mobile network birçok kullanıcıyı aynı adres arkasında toplar. Botnet ve residential proxy saldırgana binlerce IP sağlayabilir. X-Forwarded-For bilgisi yalnız güvenilir proxy zincirinden kabul edilmelidir.

NAT

NAT arkasında yüzlerce kullanıcı aynı public IP'yi paylaşabilir. Düşük limit yanlış kullanıcıları engelleyebilir. Enterprise office trafiğinde sık görülür. Authenticated user ID daha iyi anahtardır. IP yalnız ek güvenlik sinyali olabilir.

Corporate Proxy

Kurumsal ağ tüm çalışanları tek proxy üzerinden çıkarabilir. IP limit tüm şirketi tek consumer gibi görür. Partner API'de ciddi false positive oluşabilir. OAuth client veya tenant ID kullanılmalıdır. Proxy IP allowlist rate limit'i tamamen kaldırmamalıdır.

Mobile Networks

Mobil operatörler carrier-grade NAT kullanabilir. Çok sayıda subscriber aynı public IP paylaşabilir. IP kısa sürede değişebilir. User-based limit daha stabildir. Device signal yardımcı olabilir.

Botnet

Botnet çok sayıda ele geçirilmiş cihaz üzerinden trafik gönderir. Her IP düşük hızda kalsa bile toplam attack büyük olabilir. Global ve account-level limit gerekir. Behavioral analytics dağıtık pattern'i yakalayabilir. Edge bot protection ek fayda sağlar.

Residential Proxy

Residential proxy saldırgana gerçek ev bağlantılarından IP sağlayabilir. IP reputation daha az etkili hale gelir. User ve resource limit önem kazanır. Device ve behavior signal eklenebilir. Business flow abuse detection gerekir.

IPv6

IPv6 geniş address space nedeniyle tek adres limitini farklı hale getirir. Client çok sayıda adres kullanabilir. Prefix-level policy düşünülebilir. Legitimate network davranışı test edilmelidir. IPv4 varsayımları doğrudan taşınmamalıdır.

X-Forwarded-For Güvenliği

Client bu header'ı doğrudan gönderebilir. Gateway yalnız trusted proxy tarafından eklenen hop bilgisini kullanmalıdır. Header chain doğru parse edilmelidir. Aksi halde saldırgan sahte IP ile limit bypass edebilir. Original client IP standardizasyonu merkezi yapılmalıdır.

Authenticated API'lerde Per-User Rate Limiting

Authenticated API için user ID çoğu zaman en güvenilir rate limit anahtarıdır. Access token değişse bile aynı user aynı limit altında kalır. Birden fazla device aynı quota'yı tüketebilir. Sensitive endpoint'te user ve IP birlikte kullanılabilir. Account compromise etkisi user-level limit sayesinde sınırlandırılır.

User ID'nin Limit Anahtarı Olması

Token doğrulandıktan sonra stable subject veya internal user ID alınır. Counter bu ID'ye göre tutulur. Email gibi değişebilir identifier tercih edilmemelidir. Tenant context gerekiyorsa composite key yapılabilir. PII key store içinde hashlenebilir.

Token Değiştirerek Limiti Aşamamak

Limiter token string'i anahtar yaparsa kullanıcı yeni token alarak limiti sıfırlayabilir. Bunun yerine principal ID kullanılmalıdır. Refresh token yeni access token üretse bile counter aynı kalır. Multi-session davranışı doğal şekilde birleşir. Token revocation limit state'inden bağımsızdır.

Bir Kullanıcının Birden Fazla Device'ı

Kullanıcı telefon ve web üzerinden aynı anda API kullanabilir. User-level quota tüm device'ları paylaşır. Device-level sub-limit kötü tek cihazı izole edebilir. Legitimate concurrent kullanım desteklenmelidir. Policy product behavior'a göre ayarlanmalıdır.

User + IP Composite Limit

Login veya payment gibi endpoint'te hem user hem IP counter tutulabilir. Saldırgan aynı account'u birçok IP'den denese user limiti devreye girer. Aynı IP birçok account denerse IP limiti çalışır. İki sinyal credential attack'ı zorlaştırır. False positive değerleri shadow mode ile ölçülmelidir.

B2B SaaS İçin Tenant Bazlı Rate Limiting

B2B SaaS ortamında tenant doğal kapasite ve sözleşme sınırıdır. Tenant-level quota bir müşterinin ortak backend'i aşırı kullanmasını engeller. Tenant içinde user-level sub-limit adaleti korur. Enterprise müşteriye daha yüksek veya özel quota verilebilir. Tenant SLA ve rate limit policy birlikte tasarlanmalıdır.

Tenant-Level Quota

Her tenant aylık veya günlük kullanım bütçesine sahip olabilir. API gateway tenant ID üzerinden quota tüketir. Subscription plan limit değerini belirleyebilir. Quota aşımı açık hata mesajı üretir. Metering finansal billing sisteminden ayrı tutulabilir.

Tenant İçinde Per-User Sub-Limit

Tek user tenant quota'sının tamamını tüketmemelidir. User-level sub-limit bunu engeller. Admin veya service account farklı değer kullanabilir. Tenant ve user limit birlikte tüketilir. Hangi limitin aşıldığı response'ta fazla detay sızdırmadan gösterilebilir.

Noisy Neighbor Problemi

Shared service'te büyük tenant diğer müşterilerin latency'sini yükseltebilir. Tenant limit kaynakları adil paylaşır. Weighted cost heavy endpoint kullanımını da hesaba katar. Concurrency limit özellikle export için etkilidir. Capacity dashboard tenant bazında görünür olmalıdır.

Enterprise Müşteri Limitleri

Enterprise contract daha yüksek throughput gerektirebilir. Sadece sayı yükseltmek yeterli değildir. Backend capacity review yapılmalıdır. Dedicated pool veya queue gerekebilir. Exception süresi ve owner kayıt altına alınmalıdır.

Tenant Bazlı SLA

Quota ve throughput sözleşmedeki SLA ile tutarlı olmalıdır. Premium müşteri daha yüksek burst kullanabilir. Limit değerleri dokümante edilmelidir. Internal emergency limit SLA'dan farklı olabilir. Policy change müşteri iletişimi gerektirebilir.

Hierarchical Rate Limiting Nedir?

Hierarchical rate limiting aynı request'in birden fazla kapasite sınırını tüketmesini sağlar. Global limit tüm platformu korur. Tenant ve user limit fair usage sağlar. Endpoint ve operation limit pahalı işlevleri ayrıca sınırlar. Bu model tek counter'ın gizlediği riskleri azaltır.

Global Limit

Platform toplam RPS için üst sınır koyabilir. Massive attack veya traffic bug sırasında son savunma olur. Normalde consumer limitlerinden daha yüksek tutulur. Saturation noktasından güvenli mesafede olmalıdır. Global limit aşımı tüm kullanıcıları etkileyebilir.

Tenant Limit

Tenant shared capacity içindeki maksimum payını sınırlar. Subscription tier ile belirlenebilir. Büyük tenant özel policy alabilir. Cross-region deployment'ta quota partitioning gerekebilir. Tenant limit global limitin altında kalmalıdır.

User Limit

User account bazında fair usage sağlanır. Credential compromise etkisi azalır. Birden fazla token aynı counter'ı kullanır. Admin operation farklı policy kullanabilir. User limit tenant quota ile birlikte işler.

Endpoint Limit

Search ve export gibi pahalı endpoint'ler daha düşük limit alabilir. Cheap metadata endpoint daha yüksek değer kullanabilir. Endpoint cost ölçülmelidir. Route değişikliği policy drift yaratmamalıdır. Gateway config as code kullanılabilir.

Operation Limit

Aynı endpoint içinde operation type farklı maliyet taşıyabilir. GraphQL field veya RPC method buna örnektir. Operation name limit anahtarına eklenebilir. Business action seviyesinde quota uygulanabilir. Unknown operation default güvenli policy kullanmalıdır.

Bir Request'in Birden Fazla Limiti Tüketmesi

Request global, tenant, user ve endpoint counter'larını aynı anda etkileyebilir. Her kontrol mümkün olduğunca atomic değerlendirilmelidir. Hangi limitin önce kontrol edildiği latency'yi etkiler. En ucuz limit önce uygulanabilir. Distributed store round-trip sayısı optimize edilmelidir.

Composite Rate Limiting

Composite rate limiting birden fazla identity veya context bilgisini tek policy içinde kullanır. User + IP credential attack'a karşı yararlıdır. Tenant + endpoint pahalı operation'ı müşteri bazında sınırlar. Client + user delegated API kullanımında iyi model olabilir. Bu yaklaşım abuse evasion'ı tek anahtarlı limite göre zorlaştırır.

User + IP

Aynı account birçok IP'den hedeflenirse user counter devreye girer. Aynı IP birçok account denerse IP counter çalışır. Login ve password reset için faydalıdır. NAT false positive'i user katmanı azaltabilir. Threshold'lar ayrı tutulmalıdır.

Tenant + Endpoint

Her tenant belirli endpoint için farklı quota kullanabilir. Export gibi maliyetli route düşük limit alır. Standard read route daha yüksek olabilir. Enterprise tenant override alabilir. Policy key cardinality izlenmelidir.

Client + User

OAuth client ile user birlikte limitlenebilir. Aynı user farklı application üzerinden farklı kullanım hakkına sahip olabilir. Compromised client bütün kullanıcıları etkileyebilir. Client-level global limit ayrıca tutulmalıdır. Delegated access modeli daha görünür hale gelir.

Global + Per-Consumer

Consumer limit fair usage sağlar. Global limit sistemin toplam kapasitesini korur. Birçok consumer aynı anda peak yaparsa global guard devreye girer. Load shedding ile birlikte kullanılabilir. Global limit normal trafikte nadiren hit etmelidir.

Abuse Evasion'ı Zorlaştırmak

Saldırgan IP veya token değiştirerek tek counter'ı aşabilir. Composite limit farklı dimension'ları birlikte kontrol eder. Device ve resource signal eklenebilir. Behavioral risk score dinamik threshold üretebilir. Çok fazla dimension state maliyetini artırır.

Sensitive Endpoint'lerde Rate Limiting

Sensitive endpoint'ler normal read API gibi limitlenmemelidir. Login, password reset, OTP ve token creation enumeration veya brute force riski taşır. Payment ve gift card endpoint'leri finansal abuse hedefidir. User, IP, device ve resource limitleri birlikte uygulanabilir. Risk bazlı step-up kontrolü rate limit'i tamamlar.

Login

Login kullanıcı adı ve IP bazında sınırlandırılmalıdır. Password spraying birçok account'u tek IP'den hedefleyebilir. Credential stuffing rotating IP kullanabilir. User + IP composite limit faydalıdır. MFA ve bot detection ek koruma sağlar.

Password Reset

Password reset endpoint'i email veya phone enumeration için kullanılabilir. Response account varlığını sızdırmamalıdır. User identifier ve IP limit uygulanmalıdır. Message gönderim maliyeti ayrıca quota olabilir. Repeated reset talebi abuse alert üretmelidir.

OTP Verification

OTP code space sınırlı olduğu için deneme sayısı kısıtlanmalıdır. Session ve user bazlı counter tutulabilir. Başarısız giriş arttıkça cooldown uygulanabilir. OTP expiration kısa olmalıdır. Doğru kod sonrası counter reset policy dikkatle tasarlanmalıdır.

MFA

MFA challenge brute force'a karşı rate limit ister. Device veya session context kullanılabilir. Push fatigue saldırısında notification sayısı sınırlandırılmalıdır. Riskli davranış account lock veya manual review tetikleyebilir. Audit log challenge history tutmalıdır.

Token Creation

Token endpoint yüksek hızda çağrılırsa identity provider yükü artar. Client ID ve user bazlı rate limit uygulanabilir. Refresh token abuse ayrıca izlenmelidir. Token minting cost düşük görünse bile downstream attack hazırlığı olabilir. Failed auth ve success metric birlikte değerlendirilmelidir.

Account Creation

Fake account otomasyonu platform abuse yaratabilir. IP, device ve identity signal kullanılabilir. Email veya phone verification eklenebilir. Account creation velocity behavior analytics ile izlenebilir. Captcha tek başına yeterli değildir.

Payment

Payment endpoint fraud ve duplicate charge riski taşır. Idempotency key zorunlu olmalıdır. Account ve payment instrument bazlı limit uygulanabilir. Concurrency de sınırlandırılabilir. Fraud engine rate limiter ile birlikte çalışmalıdır.

Coupon ve Gift Card

Gift card code enumeration brute force hedefidir. Resource ve account limit gerekir. Failed attempt pattern'i davranış analiziyle izlenir. IP rotation tek başına bypass sağlamamalıdır. Suspicious kullanım manual review'e alınabilir.

Business Flow Abuse Nasıl Önlenir?

Business flow abuse teknik olarak geçerli request'lerin kötü amaçla otomatikleştirilmesidir. Ticket scalping veya inventory hoarding buna örnektir. Normal authentication bu davranışı durdurmaz. Rate limit, bot detection ve risk score birlikte kullanılmalıdır. Business operation'ın gerçek maliyeti policy tasarımına yansıtılmalıdır.

Ticket Scalping

Botlar release anında yüksek hızla ticket satın alabilir. User ve device limit uygulanabilir. Queue veya lottery fairness sağlayabilir. Bot score suspicious client'ı yavaşlatabilir. Purchase limit resource seviyesinde tutulmalıdır.

Fake Account Creation

Automated signup platform maliyetini ve spam riskini artırır. IP rotation nedeniyle device ve identity sinyali gerekir. Phone veya email verification yardımcı olabilir. Creation velocity global olarak izlenmelidir. Abuse cluster behavioral analytics ile bulunabilir.

Inventory Hoarding

Client çok sayıda ürünü sepete ayırarak gerçek kullanıcılara stok bırakmayabilir. Reservation süresi kısa tutulmalıdır. User veya payment identity bazlı limit uygulanabilir. Repeated abandon behavior risk score'a eklenir. Business rule rate limiter'dan daha önemli olabilir.

Price Scraping

Public product API otomatik scraping hedefi olabilir. IP limit distributed scraper karşısında yetersiz kalır. Session, device ve request pattern analiz edilebilir. Cache origin yükünü azaltır. Legal ve product policy ayrıca değerlendirilmelidir.

Gift-Card Enumeration

Saldırgan olası kodları yüksek hızda deneyebilir. Resource pattern ve failed attempt rate izlenir. User ve IP composite limit uygulanır. Response card validity hakkında minimum bilgi vermelidir. Suspicious pattern erken bloke edilmelidir.

Rate Limit + Bot Detection + Risk Score

Rate limit basit hız kontrolü sağlar. Bot detection automation sinyali üretir. Risk score identity, device ve behavior bilgisini birleştirir. Yüksek riskte limit dinamik olarak düşürülebilir. Çok yüksek riskte request tamamen engellenebilir.

Rate Limiting Algoritmaları

Rate limiting algoritması traffic pattern ve doğruluk ihtiyacına göre seçilmelidir. Fixed window basit ama boundary burst üretir. Sliding window daha hassas fakat daha fazla state gerektirir. Token bucket kontrollü burst sağladığı için API gateway'lerde yaygındır. Concurrency limiter ise zaman penceresi yerine aktif iş sayısını kontrol eder.

Fixed Window

Belirli zaman aralığında tek counter tutulur. Örneğin her dakika yüz request kabul edilir. Window sonunda sayaç sıfırlanır. Implementasyonu basittir. Window sınırında iki burst birleşebilir.

Sliding Window Log

Her request timestamp olarak tutulur. Son gerçek zaman penceresindeki kayıtlar sayılır. Enforcement çok hassastır. State ve memory maliyeti yüksektir. Sensitive low-volume endpoint için uygun olabilir.

Sliding Window Counter

Current ve previous window counter'larını ağırlıklandırarak yaklaşık sliding behavior sağlar. Log yönteminden daha az state kullanır. Fixed window boundary problemini azaltır. Tam hassas değildir. High-volume API için iyi denge sunabilir.

Token Bucket

Bucket belirli hızla token kazanır. Her request token tüketir. Capacity kısa burst'e izin verir. Refill uzun dönemli ortalama hızı sınırlar. Distributed implementation atomic update gerektirir.

Leaky Bucket

Request'ler queue benzeri bucket'a girer. Çıkış sabit hızda işlenir. Trafik smoothing sağlar. Queue dolarsa yeni request reddedilebilir. Downstream sistemi ani burst'ten korur.

GCRA

Generic Cell Rate Algorithm virtual scheduling yaklaşımıyla rate enforcement yapabilir. Düşük state ile düzgün trafik sınırı sağlar. Telecom kökenli olsa da API limiter'da kullanılabilir. Implementasyon dikkat ister. Clock ve atomicity davranışı test edilmelidir.

Concurrency Limiter

Limiter aktif request sayısını takip eder. Zaman penceresi yoktur. Long-running operation için güçlü koruma sağlar. Request bittiğinde slot serbest bırakılır. Timeout ve leak protection gerekir.

Fixed Window Nasıl Çalışır?

Fixed window en kolay anlaşılır rate limiting modellerinden biridir. Her consumer için belirli zaman diliminde counter tutulur. Window sonunda counter reset edilir. Basitliği yüksek throughput için avantajdır. Ancak pencere sınırında beklenenden iki kat burst oluşabilir.

Basit Sayaç

Key consumer ve window bilgisi içerir. Her request counter'ı artırır. Limit aşılırsa request reddedilir. Redis INCR benzeri atomic operation kullanılabilir. Expiration window sonunda state'i temizler.

Window Reset

Counter sabit dakika veya saniye sınırında sıfırlanır. Tüm client'lar aynı anda yeni quota alabilir. Bu durum traffic spike oluşturabilir. Randomized window bazı sistemlerde dağılımı iyileştirir. Client reset zamanını abuse için kullanabilir.

Boundary Burst Problemi

Client pencerenin son saniyesinde tüm quota'yı kullanabilir. Yeni pencerenin ilk saniyesinde tekrar aynı kadar request gönderir. Kısa sürede teorik limitin yaklaşık iki katı görülür. Backend burst'e dayanıklı olmalıdır. Sliding veya token bucket bu problemi azaltır.

Avantajları

Implementasyonu basittir. Counter state küçüktür. Distributed store üzerinde kolay uygulanır. Debug ve explainability yüksektir. Çok hassas enforcement gerekmeyen endpoint'ler için yeterli olabilir.

Dezavantajları

Boundary burst temel zayıflıktır. Reset anı client tarafından tahmin edilebilir. Trafik doğal olmayan spike gösterebilir. Fairness kısa zaman aralığında düşer. Sensitive brute-force kontrolünde daha hassas algoritma tercih edilebilir.

Sliding Window Nasıl Çalışır?

Sliding window sabit takvim penceresi yerine request anından geriye doğru gerçek zaman aralığını değerlendirir. Bu nedenle boundary burst problemi ciddi biçimde azalır. Log yöntemi yüksek doğruluk sağlar. Counter yaklaşımı daha düşük maliyetli yaklaşık sonuç sunar. Anti-abuse endpoint'lerinde hassas enforcement için güçlü seçenektir.

Gerçek Zaman Penceresi

Örneğin son altmış saniyedeki request sayısı değerlendirilir. Dakika sınırı önemli değildir. Her request kendi hareketli penceresine sahiptir. Burst daha doğal kontrol edilir. State cleanup düzgün yapılmalıdır.

Daha Hassas Enforcement

Client window sınırından yararlanamaz. Kısa sürede aşırı yoğunluk daha doğru görülür. Login veya OTP denemelerinde faydalıdır. High-volume traffic'te log state pahalı olabilir. Approximate counter alternatifi kullanılabilir.

State Maliyeti

Sliding log her request timestamp'ini tutabilir. Büyük RPS memory kullanımını artırır. Sorted set sık kullanılan implementasyonlardan biridir. Expired timestamp cleanup yapılmalıdır. Cost ve accuracy dengelenmelidir.

Anti-Abuse Kullanımı

Credential attack düzenli küçük burst'ler halinde gelebilir. Sliding window bu pattern'i fixed window'dan daha iyi yakalar. User ve IP dimension birlikte uygulanabilir. Risk arttıkça threshold düşürülebilir. Lockout yerine progressive delay tercih edilebilir.

Token Bucket Nasıl Çalışır?

Token bucket her consumer için belirli kapasitede sanal token havuzu tutar. Token'lar zamanla refill edilir. Request geldiğinde gerekli miktarda token tüketilir. Bucket doluysa kısa burst'e izin verilir. Uzun vadede refill rate ortalama kullanım hızını sınırlar.

Bucket Capacity

Capacity maksimum birikmiş token miktarıdır. Burst büyüklüğünü belirler. Çok yüksek capacity backend saturation riskini artırır. Çok düşük capacity normal kullanıcı spike'ını engelleyebilir. Değer load test ile seçilmelidir.

Refill Rate

Refill rate saniyede kaç token ekleneceğini belirler. Uzun dönemli throughput sınırıdır. Plan veya tenant SLA ile ilişkilendirilebilir. Dynamic policy load seviyesine göre düşürebilir. Time calculation monotonic clock kullanmalıdır.

Token Consumption

Her request bir veya daha fazla token tüketebilir. Weighted limit heavy operation'a daha fazla cost atar. Token yoksa 429 dönebilir. Negative token state'e izin verilmemelidir. Atomic check-and-update gerekir.

Controlled Burst

Bucket bir süre kullanılmadığında token birikir. Client kısa süre yüksek hızda request gönderebilir. Bu legitimate burst için faydalıdır. Ortalama rate yine korunur. Capacity backend safety margin ile uyumlu olmalıdır.

API Gateway'lerde Kullanımı

Token bucket gateway policy olarak sık uygulanır. Consumer ID ve endpoint key kombinasyonu kullanılabilir. Shared state distributed gateway node'larında tutarlı olmalıdır. Local bucket approximate mode sunabilir. Policy shadow mode ile kalibre edilmelidir.

Leaky Bucket Nasıl Çalışır?

Leaky bucket trafiği sabit veya kontrollü çıkış hızına dönüştürür. Request'ler bekleme kuyruğuna girer. Downstream service burst yerine daha düzgün trafik görür. Queue kapasitesi aşılırsa request reddedilir. Latency duyarlı endpoint'lerde uzun bekleme dikkatle sınırlandırılmalıdır.

Trafiği Düzleştirme

Ani burst queue içinde absorbe edilir. Backend sabit hızda request alır. CPU ve connection pool daha stabil kalır. Queue time kullanıcı latency'sine eklenir. Peak backlog için maksimum bekleme belirlenmelidir.

Sabit Çıkış Hızı

Limiter belirli interval ile request çıkarır. Downstream capacity biliniyorsa predictable load sağlar. Burst dışarı aynı hızla akar. Çok düşük hız throughput'u gereksiz sınırlar. Dynamic tuning uygulanabilir.

Queue Capacity

Queue sonsuz olmamalıdır. Büyük queue latency ve memory tüketir. Capacity dolunca yeni request reddedilir. Priority queue kullanılabilir. Critical operation ayrı bucket kullanabilir.

Downstream Service Protection

Legacy service ani traffic spike'a dayanamıyorsa leaky bucket yararlıdır. Connection pool aşırı büyümez. Retry storm etkisi azalır. Circuit breaker ile birlikte kullanılabilir. Queue health observability içinde görünmelidir.

Hangi Rate Limiting Algoritması Seçilmeli?

Tek bir en iyi rate limiting algoritması yoktur. Login API için hassas sliding window uygun olabilir. Public read API token bucket ile burst toleransı sağlayabilir. Heavy report endpoint concurrency ve weighted limit gerektirir. Seçim security risk, traffic shape ve backend kapasitesine göre yapılmalıdır.

Login API

Sliding window user + IP deneme hızını hassas kontrol eder. Fixed window boundary burst istenmeyebilir. Progressive cooldown eklenebilir. Bot risk score threshold'u değiştirebilir. MFA challenge ayrı counter kullanmalıdır.

Public Read API

Token bucket kısa legitimate burst'lere izin verir. IP veya API key anahtar olabilir. CDN cache backend yükünü azaltır. Global emergency limit bulunmalıdır. Scraping için bot signal eklenebilir.

Partner API

OAuth client veya API key bazlı quota uygulanabilir. Token bucket contractual RPS için uygundur. Aylık quota ayrıca tutulur. Enterprise burst sözleşmeye göre ayarlanabilir. 429 ve Retry-After davranışı dokümante edilmelidir.

Payment API

Payment operation user, account ve idempotency context'i ile sınırlandırılmalıdır. Sliding veya small token bucket kullanılabilir. Concurrency kontrolü duplicate işlem riskini azaltır. Fraud score ek sinyal sağlar. Rate limit tek finansal güvenlik kontrolü değildir.

Heavy Report API

RPS düşük olsa bile her report uzun süre CPU tüketebilir. Concurrency limiter temel kontroldür. Weighted cost tenant quota'ya bağlanabilir. Queue kullanılması gerekebilir. Result caching tekrar işleri azaltır.

Streaming API

Streaming bağlantıda request sayısından çok connection ve message rate önemlidir. Concurrent stream limit uygulanır. Message throughput ayrı quota olabilir. Maximum duration belirlenebilir. Idle connection timeout kaynakları korur.

Karar Matrisi

Kısa request ve burst toleransı için token bucket güçlü adaydır. Hassas abuse kontrolünde sliding window avantajlıdır. Basit düşük riskli endpoint fixed window kullanabilir. Long-running workload concurrency ister. Çok pahalı operation weighted cost ile birlikte sınırlandırılmalıdır.

Weighted Rate Limiting Nedir?

Weighted rate limiting her request'in aynı kaynak maliyetini taşımadığını kabul eder. Basit read bir unit tüketirken search veya export daha yüksek cost kullanabilir. Böylece kullanıcı yalnız request sayısını değil gerçek backend maliyetini tüketir. Tenant quota daha adil hale gelir. Cost model düzenli olarak gerçek telemetry ile güncellenmelidir.

Her Request Eşit Maliyetli Değildir

Health endpoint ile full export aynı backend yükünü oluşturmaz. Tek request database'de milyonlarca row tarayabilir. Flat RPS bu farkı görmez. Endpoint cost ölçülmelidir. Weighted quota kapasiteyi daha doğru temsil eder.

Request Cost Units

Her operation için integer veya decimal cost unit tanımlanabilir. Cost CPU, database ve third-party expense üzerinden hesaplanabilir. Policy basit tutulmalıdır. Çok hassas gerçek zaman hesaplama limiter latency'sini artırabilir. Versionlanmış cost table kullanılabilir.

Basit Read = 1 Unit

Küçük indexed read baseline cost olarak bir unit alabilir. Cache hit daha ucuz olsa bile policy sade kalabilir. User quota tahmini kolaylaşır. Endpoint behavior değişirse cost gözden geçirilir. Request size ayrıca influence edebilir.

Search = 5 Units

Search query daha fazla CPU ve database scan yapabilir. Beş unit gibi daha yüksek cost atanabilir. Query complexity ile dynamic cost uygulanabilir. Max page size yine sınırlandırılmalıdır. Search abuse yalnız weighted rate ile çözülmeyebilir.

Export = 100 Units

Bulk export çok pahalı operation olabilir. Yüksek cost kısa sürede quota tüketir. Concurrency limit ayrıca uygulanmalıdır. Async job tercih edilebilir. Download bandwidth de ayrı limitlenebilir.

Compute Cost'a Göre Quota

Cost unit gerçek compute veya monetary cost'a yaklaştırılabilir. AI inference buna iyi örnektir. Tenant budget doğrudan koruma sağlar. Cost model billing ile aynı sayaç olmak zorunda değildir. Operational rate control ve finansal metering ayrı sistemler olarak kalmalıdır.

Request Sayısı Dışındaki Kaynaklar Nasıl Limitlenir?

API kapasitesi yalnız request sayısıyla ölçülmez. Payload ve response size bandwidth ile memory tüketir. Database execution time veya CPU time backend saturation'a yol açabilir. Third-party API maliyeti doğrudan bütçeyi etkiler. Resource-aware limit tasarımı ağır endpoint'lerde flat RPS'den daha etkilidir.

Payload Size

Maximum request body boyutu gateway'de sınırlandırılmalıdır. Büyük payload parser ve memory yükü yaratır. Content-Length tek başına güvenilir olmayabilir. Streaming parser limit uygulamalıdır. Endpoint bazında farklı boyut kullanılabilir.

File Upload Size

Upload endpoint normal JSON API'den farklı limit ister. File size ve upload concurrency sınırlandırılabilir. Direct object storage upload backend yükünü azaltabilir. MIME ve content validation gerekir. Abuse için tenant storage quota uygulanabilir.

Response Size

Huge response egress ve memory maliyeti yaratır. Pagination zorunlu olabilir. Compression CPU tüketimini etkiler. Export ayrı async workflow'a taşınabilir. Client response size budget bilmelidir.

Pagination Size

Page size üst sınırı database load'u kontrol eder. Client `limit=100000` gönderememelidir. Default küçük tutulabilir. Deep pagination ayrıca engellenmelidir. Cursor pagination daha stabil olabilir.

CPU Time

Operation CPU cost telemetry ile ölçülebilir. Çok pahalı endpoint weighted quota alabilir. Runtime timeout sonsuz işlem riskini azaltır. Tenant compute budget kullanılabilir. Async queue workload'u izole edebilir.

Database Execution Time

Slow query request rate düşük olsa bile pool'u tüketebilir. Statement timeout kullanılabilir. Query cost endpoint policy'ye yansıtılabilir. Index ve query optimizasyonu temel çözümdür. Büyük veritabanlarında indeks yaklaşımı için https://www.diyarbakiryazilim.com.tr/posts/buyuk-veritabanlarinda-dogru-indeksleme-indexing-yaklasimlari içeriği bu kapasite boyutunu ayrıca düşünmeye yardımcı olabilir.

Memory

Large JSON veya image processing yüksek memory tüketebilir. Concurrent request sayısı bu nedenle sınırlandırılmalıdır. Payload streaming kullanılabilir. Per-request memory budget uygulanabilir. OOM tüm service'i etkileyebilir.

Third-Party API Cost

Her outbound request ücretli olabilir. Client abuse doğrudan maliyet yaratır. Provider quota ve internal budget birlikte izlenmelidir. Cache veya batching maliyeti azaltabilir. Spending limit rate limiter ile entegre edilebilir.

Concurrent Request Limiting

RPS kısa request'lerde faydalıdır ancak long-running operation için tek başına yeterli değildir. Saniyede yalnız iki report request gelse bile her biri beş dakika sürerse concurrency hızla büyür. File processing ve database export benzer risk taşır. AI inference GPU slot gibi sınırlı kaynak kullanır. Concurrency limiter aktif iş sayısını doğrudan korur.

Neden RPS Tek Başına Yeterli Değildir?

RPS request arrival hızını ölçer. Request duration uzunsa active work birikmeye devam eder. Little's Law bu ilişkiyi açıklar. Connection pool veya worker slot tükenebilir. Concurrency ayrı ölçülmelidir.

Long-Running Requests

Uzun HTTP request timeout ve resource kullanımını artırır. Async job modeli daha güvenli olabilir. Concurrent slot limit uygulanır. Client progress polling yapabilir. Cancellation desteklenmelidir.

Report Generation

Report query database'i uzun süre meşgul edebilir. Tenant başına bir veya iki concurrent report yeterli olabilir. Queue fairness uygulanabilir. Precomputed data kullanmak yükü azaltır. Export quota ayrıca tüketilebilir.

File Processing

Large file CPU ve I/O tüketebilir. Upload tamamlandıktan sonra background processing kullanılabilir. Worker concurrency sınırlanır. Tenant bazlı queue quota uygulanabilir. Failed job retry bütçesi taşımalıdır.

Database Export

Export database connection ve disk I/O kullanır. Aynı tenant çok sayıda export başlatmamalıdır. Concurrency ve weighted quota birlikte iyi çalışır. Snapshot consistency ayrı konudur. Result object storage üzerinden teslim edilebilir.

AI Inference

AI request GPU veya pahalı model kapasitesi tüketebilir. Token bazlı cost request sayısından daha anlamlıdır. Concurrent generation sınırı gerekir. Tenant token budget denial-of-wallet riskini azaltır. Model seviyesinde ayrı quota kullanılabilir.

Dynamic Rate Limiting Nedir?

Dynamic rate limiting sabit threshold yerine risk ve kapasite sinyallerine göre limit değiştirebilir. User reputation veya threat score kötü client'ın limitini azaltabilir. Sistem saturation seviyesinde global threshold geçici düşürülebilir. Attack mode daha agresif policy devreye alabilir. Trusted enterprise customer belirli kontrollü istisnalara sahip olabilir.

Static Threshold

Static limit predictable ve kolay explain edilebilir. Baseline policy olarak kullanılabilir. Traffic pattern değişince manual tuning gerekir. False positive riskini shadow mode ile ölçmek faydalıdır. Dynamic sistem static güvenli taban üzerinde kurulmalıdır.

User Reputation

Uzun süredir güvenilir davranış gösteren user daha yüksek burst alabilir. Yeni veya suspicious account daha düşük threshold kullanabilir. Reputation manipulation riski değerlendirilmelidir. Decision explainable olmalıdır. Kritik güvenlik kontrolü yalnız score'a bağlanmamalıdır.

Threat Score

WAF, bot engine veya SIEM risk score üretebilir. High-risk client'a daha düşük rate uygulanabilir. Çok yüksek risk block tetikleyebilir. Score freshness önemlidir. False positive monitoring yapılmalıdır.

Sistem Saturation Seviyesi

CPU, queue depth veya database pool saturation yükseldiğinde limit düşürülebilir. Bu adaptive load shedding sağlar. Policy ani oscillation üretmemelidir. Hysteresis kullanılabilir. Critical customer için minimum guaranteed capacity ayrılabilir.

Attack Mode

Incident sırasında emergency policy daha katı hale getirilebilir. Login veya search limitleri geçici düşürülebilir. WAF rule ve bot protection birlikte güncellenebilir. Değişiklik audit edilmelidir. Attack bitince normal policy otomatik veya kontrollü geri dönmelidir.

Trusted Customer Policies

Contractual partner yüksek limit alabilir. Güven yalnız allowlist anlamına gelmemelidir. Credential compromise hâlâ mümkündür. Maximum emergency cap tutulmalıdır. Exception expiration date ile yönetilmelidir.

Fair-Use ve Anti-Abuse Limitleri Ayrılmalı mı?

Evet, fair-use ve anti-abuse farklı amaçlara hizmet eder. Fair-use quota müşterilerin kapasiteyi adil paylaşmasını sağlar. Anti-abuse limit brute force ve enumeration gibi saldırıları hedefler. Aynı threshold iki problemi eşit iyi çözmez. Bu yüzden farklı time window ve dimension kullanmak daha güvenlidir.

Fair-Use Quota

Tenant veya plan bazlı kullanım hakkıdır. Normal kullanıcı davranışına göre belirlenir. Aylık quota veya sürekli RPS olabilir. SLA ve subscription ile bağlantılıdır. Abuse sinyali olmak zorunda değildir.

Client Bug'larından Koruma

Yanlış retry loop normal client'ı saniyeler içinde aşırı trafik üretir hale getirebilir. Fair-use limiter backend'i korur. 429 ve Retry-After client'ın toparlanmasını sağlar. SDK backoff doğru uygulanmalıdır. Monitoring ani consumer spike'ını göstermelidir.

Anti-Abuse Limit

Attack davranışına göre daha sıkı threshold kullanır. Login başarısızlıkları örnek olabilir. Başarılı normal traffic'ten ayrı counter tutulabilir. IP, device ve resource signal birlikte kullanılabilir. Risk score ile dinamik hale getirilebilir.

Brute Force

Tek account üzerinde çok sayıda parola veya OTP denenir. User-level counter temel kontroldür. IP rotation nedeniyle IP tek başına yeterli değildir. Lockout yerine delay veya MFA step-up kullanılabilir. Account availability korunmalıdır.

Scraping

Scraper düşük hata oranıyla normal read request gönderebilir. Request rate, navigation pattern ve pagination davranışı incelenebilir. Bot detection ek sinyal verir. Public data için policy business kararıdır. Cache origin yükünü azaltır.

Enumeration

Saldırgan valid user veya resource ID arayabilir. Failed lookup oranı izlenmelidir. Response timing ve body bilgi sızdırmamalıdır. Resource ve user rate limit kullanılabilir. Sequential ID kullanımının görünürlüğü artırdığı unutulmamalıdır.

İki Katmanı Birlikte Çalıştırmak

Normal traffic önce fair-use policy'den geçer. Sensitive flow ayrıca anti-abuse kontrolü uygular. Aynı request birkaç counter tüketebilir. Policy reason code observability için saklanabilir. Client'a iç detection mantığı açıklanmamalıdır.

Distributed Rate Limiting Nedir?

Distributed rate limiting birden fazla application veya gateway instance'ın aynı consumer için ortak limit uygulamasıdır. Local counter her node'da ayrı olduğu için toplam gerçek limit node sayısıyla çarpılabilir. Shared store veya coordination gerekir. Atomicity race condition'ları önler. Cluster-wide enforcement özellikle horizontal scaling ortamında zorunludur.

Tek Instance Counter

Tek process memory counter en basit çözümdür. Bir instance olduğunda doğru çalışabilir. Restart state'i kaybeder. Horizontal scale olduğunda her node farklı sayaç görür. Production kurumsal ortam için sınırlıdır.

Load Balancer Arkasında Limit Problemi

Client request'leri farklı node'lara dağıtılır. Her node yüz request kabul ederse dört node toplam dört yüz request geçirir. Sticky session bu sorunu kısmen azaltır. Failover sonrası state değişir. Shared counter daha doğru çözümdür.

Shared Counter Store

Redis gibi hızlı store tüm node'ların ortak state okumasını sağlar. Counter key consumer ve policy'yi temsil eder. Store request path içinde olduğu için latency önemlidir. High availability gerekir. State volume capacity planına dahil edilmelidir.

Atomicity

Check ve increment ayrı operation olursa race condition oluşabilir. Atomic command veya Lua script kullanılabilir. Token bucket refill ve consume tek transaction benzeri işlemde yapılmalıdır. Multi-key hierarchical limit daha zor olabilir. Consistency requirement dikkatle seçilmelidir.

Race Conditions

İki gateway aynı anda kalan quota'yı görebilir. İkisi de request kabul ederse limit aşılır. Atomic state update bunu azaltır. Eventual counter approximate enforcement sağlayabilir. Security-critical endpoint daha güçlü consistency isteyebilir.

Cluster-Wide Enforcement

Tüm gateway node'ları ortak policy ve counter kullanır. Autoscaling limit değerini değiştirmez. New node hemen aynı state'i görür. Store outage için fail-open veya fail-closed politikası gerekir. Decision latency SLO ile izlenmelidir.

Redis ile Distributed Rate Limiting

Redis düşük latency ve atomic operation desteği nedeniyle distributed rate limiter için sık tercih edilir. Basit fixed window INCR ve expiration ile uygulanabilir. Sliding window sorted set kullanabilir. Lua script atomic check-and-update için yararlıdır. Redis latency request path'in tamamını etkileyebileceği için topology dikkatle tasarlanmalıdır.

Counter Keys

Key içinde policy, consumer ve window bilgisi bulunabilir. Cardinality çok yüksekse memory kullanımı artar. PII doğrudan key içinde tutulmamalıdır. TTL state cleanup sağlar. Namespace environment'lar arasında ayrılmalıdır.

INCR / Expiration

Fixed window için INCR counter artırır. İlk request'te expiration ayarlanır. Race condition expiration eksik bırakmamalıdır. Atomic script kullanılabilir. TTL window süresine göre seçilir.

Sorted Sets

Sliding window log request timestamp'lerini sorted set içinde tutabilir. Eski entry'ler silinir. Current count set size üzerinden hesaplanır. High-volume consumer memory tüketebilir. Approximate counter daha ucuz olabilir.

Lua ile Atomic Check-and-Update

Lua script birden fazla Redis operation'ını atomic çalıştırabilir. Token refill, check ve consume tek adımda yapılır. Network round-trip azalır. Script latency izlenmelidir. Cluster key slot davranışı multi-key script'i etkileyebilir.

Token Bucket State

Bucket kalan token ve son refill timestamp'i tutabilir. Request anında yeni token miktarı hesaplanır. State atomik güncellenir. Clock difference minimize edilmelidir. Fixed precision arithmetic kullanılabilir.

Redis Latency'nin Request Path'e Etkisi

Her API request limiter store'a giderse küçük Redis gecikmesi bile p99'u etkiler. Local cache veya regional store kullanılabilir. Timeout kısa tutulmalıdır. Fail policy endpoint riskine göre belirlenir. Redis saturation tüm API'yi durdurmamalıdır.

Multi-Region Rate Limiting Nasıl Tasarlanır?

Multi-region rate limiting global doğruluk ile availability arasında trade-off oluşturur. Her request için global counter'a uzak region erişmek latency ekler. Regional quota partitioning bu maliyeti azaltabilir. Eventual synchronization limitin kısa süre aşılmasına yol açabilir. Kritik endpoint ile normal API farklı doğruluk seviyesi kullanabilir.

Global Sayaç

Tüm region'lar tek logical counter paylaşır. Quota çok doğru olur. Cross-region latency request path'e eklenebilir. Global store outage geniş etki yaratır. Strong global consistency pahalıdır.

Regional Sayaç

Her region local counter tutar. Latency düşer. User region değiştirerek toplam limiti aşabilir. Quota region'lar arasında bölünebilir. Global aggregate eventual olarak hesaplanabilir.

Quota Partitioning

Global yüz RPS quota iki region'a ellişer dağıtılabilir. Kullanılmayan kapasite bir region'da boş kalabilir. Dynamic reallocation yapılabilir. Attack sırasında region cap güvenli sınır sağlar. Enterprise traffic distribution dikkate alınmalıdır.

Cross-Region Latency

Remote counter store onlarca milisaniye ekleyebilir. API p99 ciddi biçimde kötüleşir. Local decision tercih edilebilir. Sensitive operation remote strong counter kullanabilir. Policy endpoint riskine göre ayrılmalıdır.

Eventual Counter Synchronization

Regional usage belirli aralıklarla global sisteme aktarılır. Kısa süre global quota aşılabilir. Fair-use için kabul edilebilir olabilir. Finansal veya abuse-sensitive limitte yetersiz kalabilir. Overshoot budget tanımlanmalıdır.

Global Accuracy vs Availability Trade-Off

Strong global counter doğruluğu artırırken network dependency getirir. Regional approximate model availability ve latency açısından iyidir. Policy business risk ile eşleştirilmelidir. Rate limit mükemmel doğruluk gerektirmeyebilir. Security-critical flow ayrı çözüm kullanabilir.

Rate Limiter Fail-Open mı Fail-Closed mı Çalışmalı?

Rate limiter store erişilemez olduğunda request'in kabul edilip edilmeyeceği önceden belirlenmelidir. Fail-open availability'yi korur ancak abuse riskini artırır. Fail-closed güvenliği güçlendirir fakat limiter arızasını API outage'a dönüştürebilir. Endpoint riskine göre farklı politika uygulanabilir. Payment ve public read API aynı davranışı kullanmak zorunda değildir.

Rate Limit Store Erişilemezse Ne Olur?

Limiter state okuyamazsa policy decision veremez. Timeout request latency'yi artırabilir. Fallback local limit kullanılabilir. Metric ve alert anında tetiklenmelidir. Default davranış dokümante edilmelidir.

Fail-Open

Store arızasında request geçmeye devam eder. Availability yüksek kalır. Backend başka kapasite korumalarına ihtiyaç duyar. Attack aynı anda gerçekleşirse risk büyür. Public düşük riskli read API için uygun olabilir.

Availability Avantajı

Redis outage tüm API'yi kapatmaz. User normal işlemlerine devam eder. Limiter independent failure domain olarak kalır. Local emergency cap yine kullanılabilir. Recovery sonrası shared policy tekrar devreye girer.

Abuse Riski

Saldırgan limiter failure penceresinden yararlanabilir. Sensitive endpoint kontrolsüz kalabilir. Backend saturation oluşabilir. Edge limit son savunma olabilir. Fail-open her route için kullanılmamalıdır.

Fail-Closed

Store erişilemezse request reddedilir. Abuse bypass ihtimali azalır. Limiter outage kullanıcı outage'ına dönüşebilir. Critical financial action için gerekçeli olabilir. Error handling ayrı status veya service unavailable kullanabilir.

Security Avantajı

Security-sensitive operation limiter olmadan çalışmaz. Brute force veya payment abuse kontrolü korunur. Compliance requirement buna ihtiyaç duyabilir. Emergency bypass sıkı yetkiyle tutulmalıdır. Decision audit edilmelidir.

Outage Riski

Shared store failure tüm sensitive API'yi durdurabilir. Multi-zone Redis ve local fallback gerekir. Availability SLO etkilenir. Timeout çok uzun tutulmamalıdır. Chaos test bu davranışı doğrulamalıdır.

Endpoint Riskine Göre Farklı Politika

Public product catalog fail-open kullanabilir. Login veya gift card verification fail-closed olabilir. Payment için degraded controlled mode tasarlanabilir. Policy route metadata'sında tanımlanmalıdır. Default unknown endpoint güvenli policy almalıdır.

Rate Limiter İçin High Availability

Rate limiter güvenlik katmanı olduğu kadar request path dependency'sidir. Shared store failover ve multi-zone deployment gerekir. Store erişilemezse local emergency limit kullanılabilir. Policy cache control plane outage'ını azaltır. Limiter'ın kendisi single point of failure olmamalıdır.

Shared Store Failover

Redis veya counter store replica ve failover yapısına sahip olmalıdır. Promotion süresi limiter SLO'yu etkiler. Client reconnect test edilmelidir. Split-brain counter doğruluğunu bozabilir. Managed veya self-managed topology düzenli test edilmelidir.

Local Emergency Limit

Shared store unreachable olduğunda node local conservative cap uygulayabilir. Tam global doğruluk olmaz. Backend yine korunur. Limit normalden daha düşük seçilebilir. Recovery sonrası local state discard edilebilir.

Cached Policy

Policy definition control plane'den local cache'e alınabilir. Control plane outage olsa bile mevcut policy çalışır. Cache version görünür olmalıdır. Expiration çok kısa olmamalıdır. Emergency policy push mekanizması bulunabilir.

Circuit Breaker

Limiter store sürekli timeout veriyorsa breaker remote çağrıyı geçici durdurabilir. Local fallback devreye girer. Request latency korunur. Recovery probe kontrollü yapılır. Breaker state metric olarak izlenmelidir.

Rate Limiter'ın Single Point of Failure Olmasını Önlemek

Gateway node'ları horizontal çalışmalıdır. Counter store high available olmalıdır. Policy cache local olmalıdır. Fail behavior açıkça tanımlanmalıdır. Chaos test düzenli yapılmalıdır.

HTTP 429 Too Many Requests Nasıl Kullanılmalı?

HTTP 429 client'ın geçerli endpoint'i çok yüksek hızda kullandığını belirtir. 403 permission denial ile karıştırılmamalıdır. Response body standard ve machine-readable olmalıdır. Retry-After client'ın ne zaman yeniden denemesi gerektiğini söyleyebilir. Error mesajı internal threshold detayını gereksiz yere sızdırmamalıdır.

429 Ne Anlama Gelir?

Request format ve authentication açısından geçerli olabilir. Ancak current policy usage sınırı aşılmıştır. Client daha sonra tekrar deneyebilir. Permanent authorization problemi değildir. Monitoring consumer ve endpoint dimension'ını göstermelidir.

429 ile 403 Arasındaki Fark

403 user'ın işlemi yapmaya yetkisi olmadığını belirtir. 429 geçici kullanım sınırını gösterir. Client 403 için sürekli retry yapmamalıdır. 429 için kontrollü retry mümkündür. SDK bu iki durumu farklı ele almalıdır.

Standard Error Body

Response error code ve human-readable message içerebilir. Internal Redis veya policy detayları gösterilmemelidir. Correlation ID debugging'e yardım eder. API version'ları aynı error contract'ı kullanmalıdır. Client code status üzerinden davranabilmelidir.

Retry-After

Retry-After saniye veya tarih bilgisi verebilir. Client bu süreyi beklemelidir. Sliding veya token bucket'ta kesin reset zamanı her zaman basit olmayabilir. Approximate retry değeri verilebilir. Retry storm'u azaltır.

Correlation ID

429 response request correlation ID taşıyabilir. Support ve log araması kolaylaşır. ID güvenli random formatta olmalıdır. User PII içermemelidir. Trace sistemiyle ilişkilendirilebilir.

Client'a Fazla İç Bilgi Sızdırmamak

Exact anti-abuse threshold saldırgana tuning bilgisi verebilir. Public quota bilgisi dokümante edilebilir. Security-specific hidden limitler açıklanmayabilir. Error message generic kalabilir. Internal reason loglarda saklanır.

Rate Limit Bilgisi API Client'a Nasıl İletilir?

API client kalan quota ve retry davranışını anlayabilirse daha sağlıklı trafik üretir. Current quota, remaining ve effective window bilgileri header üzerinden iletilebilir. Retry-After özellikle 429 response için değerlidir. RateLimit header standardizasyonu client SDK davranışını kolaylaştırabilir. Header'daki değerler her zaman contractual SLA olarak yorumlanmamalıdır.

Current Quota

Client total izin verilen quota'yı görebilir. Plan veya endpoint'e göre değişebilir. Hidden anti-abuse limit gösterilmek zorunda değildir. Quota dynamic ise header approximate olabilir. Documentation semantics'i açıklar.

Remaining Quota

Kalan kullanım client'ın pacing yapmasına yardım eder. Distributed approximate counter küçük fark gösterebilir. Client zero'a yaklaşınca request hızını azaltabilir. Retry behavior daha öngörülebilir olur. Security limit detayları gerekirse saklanabilir.

Reset / Effective Window

Fixed window'da reset zamanı doğrudan anlamlıdır. Sliding window'da effective recovery daha dinamik olabilir. Client'a uygun abstraction verilebilir. Absolute timestamp clock skew yaratabilir. Relative saniye daha basit olabilir.

Retry-After

429 sonrası en önemli client yönlendirmelerinden biridir. Exponential backoff ile birlikte kullanılabilir. Client daha erken denememelidir. Server dynamic load durumuna göre değer verebilir. Jitter yine önerilir.

RateLimit Header Standardizasyonu

Standard header kullanımı farklı API client'larının aynı davranışı geliştirmesini kolaylaştırır. Gateway merkezi olarak ekleyebilir. Semantics kullanılan standard sürümüne göre doğrulanmalıdır. Custom header minimum tutulabilir. API docs örnek response göstermelidir.

Header Bilgisinin SLA Olmaması

Runtime limiter value contract quota'dan düşük olabilir. Attack mode temporary threshold değiştirebilir. Client header'ı guaranteed capacity olarak kabul etmemelidir. Contractual SLA ayrı dokümanda tanımlanır. Operational safety policy gerektiğinde değişebilir.

API Client 429 Aldığında Ne Yapmalı?

İyi API client 429 response'u yeni request fırtınasıyla karşılamamalıdır. Önce ilgili consumer için istek hızı düşürülmelidir. Retry-After varsa buna uyulmalıdır. Exponential backoff ve jitter aynı anda binlerce client'ın yeniden denemesini engeller. Maximum retry ve retry budget sonsuz döngüyü önler.

İstek Göndermeyi Durdurmak

Client aynı endpoint'e anında tekrar request göndermemelidir. Queue yeni işi kısa süre bekletebilir. Interactive request kullanıcıya uygun mesaj verebilir. Background worker pacing uygulayabilir. 429 hata değil traffic signal olarak ele alınmalıdır.

Retry-After'a Uymak

Server belirtilen süre kadar beklenmesini ister. Client bunu ignore ederse daha fazla 429 üretir. Header yoksa default backoff kullanılabilir. Retry schedule jitter içermelidir. Kullanıcı cancellation hakkı korunmalıdır.

Exponential Backoff

Her başarısız retry sonrası bekleme süresi büyür. Downstream recovery için zaman tanır. Maximum delay sınırlandırılmalıdır. 429 ve 5xx aynı retry policy'yi kullanmak zorunda değildir. Idempotent olmayan operation dikkat ister.

Jitter

Tüm client aynı deterministic süreyi beklerse aynı anda geri döner. Jitter bekleme süresine random fark ekler. Thundering herd riski azalır. SDK standard policy sunabilir. Random range ölçülü olmalıdır.

Maximum Retry

Client sonsuza kadar yeniden denememelidir. Deneme sayısı operation riskine göre sınırlandırılır. User-facing action hızlı fail edebilir. Background job daha uzun budget kullanabilir. Son failure açık biçimde raporlanmalıdır.

Retry Budget

Sistem toplam request içinde retry yüzdesine sınır koyabilir. Massive downstream issue sırasında retry traffic original load'u katlamaz. Service-level budget tutulabilir. Circuit breaker ile birlikte çalışır. Observability retry ratio göstermelidir.

Retry Storm ve Thundering Herd Nasıl Önlenir?

Bir backend hata verdiğinde binlerce client aynı anda retry yaparsa recovery daha da zorlaşır. Bu durum thundering herd veya retry storm olarak görülür. Jitter ve randomized backoff client'ları zamana yayar. Server-side load shedding gerektiğinde yeni işi reddeder. SDK politikalarını merkezi standardize etmek büyük fark yaratır.

Aynı Anda Binlerce Client Retry Yaparsa

Downstream henüz recovery yapmadan tekrar doygunlaşır. Connection pool yeniden dolar. P99 latency yükselir. Failure süresi uzar. Retry traffic ayrı metric olarak izlenmelidir.

Jitter

Random küçük gecikme client'ların aynı anda uyanmasını önler. Backoff schedule daha düzgün dağılır. Basit full jitter çoğu sistemde etkilidir. SDK bu davranışı default sunabilir. Retry deadline korunmalıdır.

Randomized Backoff

Backoff yalnız sabit iki kat artış kullanmak zorunda değildir. Random range içinde süre seçilebilir. Large fleet daha iyi dağılır. Maximum cap uygulanır. Retry reason'a göre farklı policy olabilir.

Server-Side Load Shedding

Server kapasite sınırında düşük öncelikli request'i erken reddedebilir. Queue daha fazla büyümez. Retry-After doğru verilmelidir. Critical traffic için priority tutulabilir. Load shedding metric saturation ile ilişkilendirilir.

Client SDK Politikaları

Her ekip kendi retry mantığını yazarsa tutarsız davranış oluşur. Ortak SDK backoff, jitter ve retry budget standardı sağlar. Retry-safe method listesi belirlenir. Telemetry otomatik eklenebilir. Policy version controlled olmalıdır.

API Gateway'de Rate Limiting Nerede Uygulanmalı?

Rate limiting tek noktada uygulanmak zorunda değildir. Edge kötü trafik volume'unu azaltır. WAF pattern ve bot signal ile filtreleme yapar. Gateway identity ve endpoint bazlı merkezi limit uygular. Application business context, database ve downstream layer ise kendi kaynak sınırlarını korur.

Edge/CDN

Anonymous IP flood burada erken durdurulabilir. Origin bandwidth korunur. Geo ve ASN signal kullanılabilir. User-level identity çoğu zaman bilinmez. Basit coarse limit için uygundur.

WAF

WAF suspicious request pattern'ini filter edebilir. Rate-based rule kullanılabilir. Bot veya reputation signal eklenebilir. Business tenant context sınırlıdır. Application authorization burada yapılmamalıdır.

API Gateway

Gateway verified user, API key veya client ID'yi bilir. Per-consumer rate limit için doğal noktadır. Endpoint policy merkezi yönetilir. Distributed store kullanılabilir. 429 response standardizasyonu burada yapılır.

Application Layer

Application tenant tier ve business operation maliyetini bilir. Weighted veya resource-level limit burada uygulanabilir. Risk score domain context ile birleştirilebilir. Gateway'deki coarse limit tamamlanır. Duplicate policy drift önlenmelidir.

Database/Downstream Layer

Database connection pool ve statement timeout kendi kapasitesini korur. Third-party client library concurrency limit uygulayabilir. Queue downstream iş sayısını sınırlar. Bu katman son savunma olarak önemlidir. Upstream rate limiter tek başına yeterli değildir.

Katmanlar Arası Sorumluluk

Edge volume, gateway consumer, application business ve downstream resource seviyesini korur. Her katmanın amacı açık yazılmalıdır. Aynı limit gereksiz tekrar edilmemelidir. Metric reason code katmanı göstermelidir. Incident sırasında hangi control'ün devreye girdiği anlaşılmalıdır.

Edge Rate Limiting

Edge rate limiting kötü trafiği backend'e ulaşmadan kesmek için kullanılır. IP, ASN ve geo signal burada hızlı uygulanabilir. DDoS ve bot traffic origin resource tüketmeden azaltılır. Ancak user veya tenant identity her zaman edge'de güvenilir biçimde bulunmayabilir. Bu nedenle edge limit ile application-level limit birbirini tamamlar.

Kötü Trafiği Backend'e Ulaşmadan Kesmek

Origin CPU ve connection kapasitesi korunur. Bandwidth maliyeti düşer. Malicious request gateway'e ulaşmaz. Detection latency düşük olur. False positive geniş kullanıcı kitlesini etkileyebileceği için policy dikkatli olmalıdır.

IP/ASN/Geo Signals

IP reputation veya network provider bilgisi risk signal sağlar. Belirli region business gereği allow veya deny olabilir. Residential proxy detection yardımcı olabilir. Tek signal kesin karar olmamalıdır. Privacy ve compliance dikkate alınmalıdır.

DDoS

Volumetric DDoS için edge kapasitesi kritik önemdedir. Application server bu traffic'i taşımamalıdır. Layer 3 ve 4 attack farklı araçlar gerektirir. HTTP flood ayrıca rate-based rule kullanabilir. Incident mode otomatik scale ve block içerebilir.

Bot Traffic

Bot request'leri browser benzeri görünmeye çalışabilir. Fingerprint ve behavior analizi kullanılabilir. IP rate limit tek başına zayıftır. Challenge veya risk-based action uygulanabilir. Legitimate crawler allow policy'si ayrı tutulabilir.

Edge ile User-Level Limit Arasındaki Fark

Edge çoğu zaman connection ve IP context görür. Gateway user identity ve tenant bilgisini doğrular. Authenticated abuse user-level limiter ile daha doğru yönetilir. İki control farklı threat model taşır. Aynı threshold kullanmaları gerekmez.

Application-Level Rate Limiting Ne Zaman Gereklidir?

Gateway business context'i bilmiyorsa application-level limiting gerekir. Tenant subscription tier veya feature-level quota buna örnektir. İşlem maliyeti request payload'ından hesaplanabilir. Kullanıcı risk skoru da application decision'ına dahil edilebilir. Gateway coarse control, backend ise domain-aware control uygular.

Gateway'nin Bilmediği Business Context

Request'in hangi plan veya resource'u etkilediği backend'de ortaya çıkabilir. Database'den tenant state okunabilir. Operation cost domain logic'e bağlı olabilir. Application bu bilgiyi policy engine'e gönderir. Gateway'deki generic limit devam eder.

Tenant Subscription Tier

Free ve enterprise tenant farklı quota alabilir. Plan bilgisi subscription service'den gelir. Cache stale kalırsa limit kısa süre yanlış olabilir. Policy versionlanmalıdır. Upgrade sonrası quota hızlı güncellenmelidir.

İşlem Maliyeti

Search filter veya export size gerçek cost'u belirleyebilir. Backend request'i parse ettikten sonra cost unit hesaplar. Weighted limiter uygulanır. Excessive operation erken reddedilir. Cost estimation ucuz olmalıdır.

Feature-Level Quota

Belirli premium feature aylık kullanım sayısına sahip olabilir. Endpoint bazlı quota yeterli olmayabilir. Aynı feature farklı route'lardan çağrılabilir. Domain-level counter doğru abstraction sağlar. Billing meter ayrı tutulur.

Kullanıcı Risk Skoru

Application fraud veya abuse score alabilir. High-risk user daha düşük limit kullanabilir. Step-up authentication tetiklenebilir. Score stale olduğunda güvenli default uygulanmalıdır. Decision açıklanabilir olmalıdır.

GraphQL API'lerde Rate Limiting

GraphQL tek HTTP endpoint kullandığı için klasik endpoint bazlı rate limiting yetersiz kalabilir. Bir query yüzlerce field ve nested relation isteyebilir. Query depth ve complexity ölçülmelidir. Alias ve batch request tek HTTP çağrısı içinde maliyeti büyütebilir. Persisted query ve field cost budget kontrolü kolaylaştırır.

Tek Endpoint Problemi

Tüm GraphQL operation `/graphql` route'una gelir. Endpoint başına yüz RPS demek query maliyetini açıklamaz. Cheap query ile expensive query aynı sayılır. Operation name ve complexity kullanılmalıdır. Anonymous introspection ayrıca sınırlandırılabilir.

Query Depth

Çok derin nested query exponential backend işine dönüşebilir. Maximum depth tanımlanmalıdır. Recursive relation abuse engellenir. Legitimate deep query gözden geçirilir. Depth tek başına total field count'u göstermeyebilir.

Query Complexity

Her field belirli cost taşıyabilir. List field page size ile çarpılabilir. Total complexity threshold aşılırsa request reddedilir. Tenant quota complexity unit tüketebilir. Cost model schema değiştikçe güncellenmelidir.

Aliases

Client aynı field'ı birçok alias ile tek query içinde tekrar çağırabilir. Request count bir olmasına rağmen backend işi büyür. Alias sayısı sınırlanabilir. Complexity calculator bunu hesaba katmalıdır. Resolver caching yardımcı olabilir.

Batch Requests

Tek HTTP body içinde birden fazla GraphQL operation gönderilebilir. Gateway request sayısı yalnız bir görür. Operation sayısı ve total complexity ayrı sınırlandırılmalıdır. Maximum batch size belirlenmelidir. Batching gerekmezse kapatılabilir.

Field Cost

Basit scalar field düşük cost olabilir. Search veya recommendation field yüksek cost alabilir. Resolver telemetry gerçek maliyeti gösterir. Cost static veya dynamic olabilir. Client docs complexity davranışını açıklayabilir.

Persisted Queries

Önceden onaylanmış query hash üzerinden çağrılabilir. Unknown arbitrary query production'da sınırlandırılabilir. Cost önceden hesaplanır. Mobile client güvenli ve predictable API kullanır. Version ve deprecation yönetimi gerekir.

GraphQL Batching Rate Limit'i Nasıl Bypass Edebilir?

GraphQL batching tek network request içinde çok sayıda operation taşıyabilir. Gateway yalnız HTTP request sayısını sayarsa limit kolayca aşılır. Operation başına sayaç veya complexity budget kullanılmalıdır. Maximum batch size güvenli üst sınır sağlar. Batching business ihtiyacı yoksa tamamen kapatılabilir.

Tek HTTP Request İçinde Çoklu Operation

Client body içinde onlarca query gönderebilir. Gateway bir request olarak görür. Backend onlarca resolver tree çalıştırır. CPU ve database load büyür. Parser batch yapısını anlamalıdır.

Operation Başına Sayım

Rate limiter her GraphQL operation'ı ayrı cost olarak değerlendirebilir. Batch içindeki toplam tüketim hesaplanır. Limit aşılırsa tamamı veya bir kısmı reddedilebilir. Partial response semantics açık olmalıdır. Atomic batch gerekliyse farklı policy uygulanır.

Maximum Batch Size

Batch içine en fazla belirli operation sayısı konulabilir. Bu hard safety limit'tir. Normal client behavior üzerinden seçilir. Büyük batch daha iyi network efficiency sağlasa bile backend risk yaratabilir. Shadow mode false positive'i ölçer.

Complexity Budget

Operation sayısı aynı olsa bile cost değişebilir. Total complexity budget daha doğru koruma sağlar. Tenant ve user bazlı uygulanabilir. Persisted query cost önceden bilinebilir. Dynamic field cost query variables üzerinden hesaplanabilir.

Batching'i Devre Dışı Bırakmak

Product ihtiyacı yoksa en basit çözüm batch request'i kabul etmemektir. Attack surface azalır. Client SDK tek operation gönderir. Network request sayısı artabilir. Performance etkisi ölçülmelidir.

gRPC API'lerde Rate Limiting

gRPC farklı call türleri nedeniyle yalnız request count üzerinden sınırlandırılamaz. Unary request klasik HTTP çağrısına benzer. Streaming çağrılar uzun süre connection ve memory tutabilir. Stream count, message rate ve duration ayrı kontrol edilmelidir. Service method bazlı policy gateway veya interceptor içinde uygulanabilir.

Unary Requests

Tek request ve tek response vardır. Token bucket veya sliding window kolay uygulanır. Client identity metadata'dan alınabilir. Deadline zorunlu tutulmalıdır. Method cost farklı olabilir.

Server Streaming

Client tek request gönderir, server çok sayıda message döner. Request rate düşük görünür. Response message rate ve stream duration önemlidir. Concurrent stream limit uygulanabilir. Client cancellation desteklenmelidir.

Client Streaming

Client tek stream içinde çok sayıda message gönderebilir. Connection count tek olsa da ingestion load yüksek olabilir. Message rate sınırı gerekir. Payload size ayrıca kontrol edilir. Backpressure protocol-level uygulanmalıdır.

Bidirectional Streaming

İki taraf sürekli message gönderebilir. Connection ve message rate birlikte sınırlandırılmalıdır. Long-lived resource kullanımı yüksektir. Idle timeout önemlidir. Abuse detection stream behavior'u izlemelidir.

Stream Count

User veya client başına concurrent stream sayısı sınırlandırılır. Connection multiplexing nedeniyle transport connection count yeterli değildir. Service method bazlı ayrı değer kullanılabilir. Slot leak recovery gerekir. Disconnect slot'u serbest bırakmalıdır.

Message Rate

Stream içindeki saniyelik message sayısı ölçülür. Token bucket kullanılabilir. Burst capacity protocol buffer size ile birlikte düşünülmelidir. Backpressure client'a uygulanabilir. Excessive rate stream'in kapatılmasına yol açabilir.

Maximum Stream Duration

Sonsuz stream resource leak yaratabilir. Belirli maksimum süre veya idle timeout kullanılabilir. Long-lived legitimate subscription refresh edilebilir. Drain deployment sırasında kolaylaşır. Policy client docs içinde belirtilmelidir.

WebSocket API'lerde Rate Limiting

WebSocket uzun süreli connection kullandığı için HTTP request rate tek başına yeterli değildir. Connection creation rate ve concurrent connection sayısı sınırlandırılmalıdır. Message rate ayrı policy gerektirir. Subscription sayısı backend fan-out maliyetini etkileyebilir. Idle timeout kullanılmayan connection'ları temizler.

Connection Rate

Client kısa sürede çok sayıda yeni WebSocket açabilir. Handshake CPU ve auth yükü oluşturur. IP ve user bazlı connection rate limit uygulanabilir. Failed handshake ayrıca izlenir. Reconnect storm için backoff gerekir.

Concurrent Connections

User veya tenant başına aktif connection sayısı sınırlandırılır. Multiple device ihtiyacı düşünülmelidir. Zombie connection heartbeat ile temizlenir. Enterprise use case özel quota alabilir. Global cap service kapasitesini korur.

Message Rate

Open connection saniyede binlerce message gönderebilir. Message rate user ve connection bazında limitlenir. Payload cost ayrıca hesaplanabilir. Violation warning veya disconnect üretebilir. Server-to-client push ayrı budget kullanabilir.

Subscription Count

Tek connection yüzlerce topic'e subscribe olabilir. Backend fan-out state'i büyür. Subscription sayısı sınırlandırılmalıdır. Expensive topic farklı cost alabilir. Access authorization her topic için kontrol edilir.

Idle Timeout

Uzun süre mesaj göndermeyen connection kapatılabilir. Resource slot serbest kalır. Heartbeat legitimate idle session'ı koruyabilir. Timeout client behavior'a göre seçilmelidir. Reconnect storm yaratmamalıdır.

Webhook Güvenliği

Webhook endpoint dış sistemden gelen server-to-server request'i kabul eder. Signature verification kaynağın doğrulanmasına yardım eder. Timestamp ve replay protection aynı request'in tekrar kullanılmasını engeller. Idempotency duplicate delivery'yi güvenli kılar. Inbound rate limiting ve source allowlist ek koruma sağlar.

Signature Verification

Provider request body'yi shared secret veya private key ile imzalar. Receiver raw body üzerinden signature doğrular. Body parse sonrası serialization farkı sorun yaratabilir. Secret rotation desteklenmelidir. Signature failure 401 veya uygun error üretir.

Timestamp

Signed timestamp request freshness kontrolü sağlar. Çok eski request reddedilir. Clock skew için küçük tolerans verilir. Timestamp signature içine dahil edilmelidir. Tek başına replay'i tamamen önlemez.

Replay Protection

Event ID veya nonce kısa süre cache'de tutulabilir. Aynı request ikinci kez işlenmez. Timestamp window attack süresini sınırlar. Storage TTL belirlenmelidir. High-volume webhook için memory planı yapılır.

Idempotency

Provider normal operasyon nedeniyle event'i tekrar gönderebilir. Consumer aynı event'i güvenli işleyebilmelidir. Event ID unique constraint kullanılabilir. Side effect yalnız bir kez uygulanır. Retry success response ile sona erer.

Source Allowlist

Provider sabit IP yayınlıyorsa allowlist ek savunma sağlayabilir. Cloud provider IP değişiklikleri yönetilmelidir. Signature verification yine zorunlu tutulmalıdır. NAT veya proxy behavior bilinmelidir. Allowlist tek identity kontrolü değildir.

Inbound Rate Limiting

Compromised provider veya replay flood backend'i aşırı yükleyebilir. Source ve event type bazlı rate limit uygulanabilir. Burst legitimate incident durumunda yüksek olabilir. Queue webhook processing'i request path'ten ayırabilir. 429 provider retry davranışını etkiler.

API Schema Validation Neden Rate Limiting Kadar Önemlidir?

Rate limiting request sayısını sınırlar ancak tek request'in aşırı büyük veya karmaşık olmasını engellemez. Schema validation payload formatı ve boyutunu kontrol eder. OpenAPI ve JSON Schema kuralların merkezi tanımını sağlayabilir. Array size, string length ve nesting depth sınırlandırılmalıdır. Bu yaklaşım parser, memory ve database kaynaklarını korur.

OpenAPI

REST API request ve response schema'sı OpenAPI ile tanımlanabilir. Gateway validation policy üretebilir. Unknown parameter reddedilebilir. API docs ve test aynı contract'ı kullanır. Spec drift CI tarafından yakalanmalıdır.

JSON Schema

JSON payload için type, required field ve size constraint tanımlanabilir. Nested object yapısı sınırlandırılabilir. Validation backend'e ulaşmadan yapılabilir. Custom business validation yine application'da kalır. Error mesajı fazla iç yapı sızdırmamalıdır.

Payload Size

Maximum body size gateway veya server tarafından uygulanır. Huge body memory exhaustion yaratabilir. Streaming upload farklı route kullanmalıdır. Compression bomb riski değerlendirilmelidir. Limit endpoint ihtiyacına göre değişebilir.

Array Size

Client tek request'te on bin object gönderebilir. RPS düşük olsa bile backend işi büyür. Maximum array length tanımlanmalıdır. Bulk API ayrı endpoint olabilir. Batch içi operation count rate quota tüketebilir.

Maximum String Length

Kontrolsüz string memory ve log boyutunu büyütür. Search pattern expensive regex riskini artırabilir. Field-level max length schema içinde tanımlanmalıdır. Unicode length semantics test edilmelidir. Validation normalize işleminden önce veya sonra açıkça belirlenmelidir.

Unknown Fields

Unknown field kabulü mass assignment riskini artırabilir. Strict schema güvenliği güçlendirir. Forward compatibility ihtiyacı değerlendirilmelidir. Sensitive property application mapping'de explicit tutulmalıdır. Client typo erken fark edilir.

Nested Object Depth

Çok derin JSON parser stack ve CPU tüketebilir. Maximum depth uygulanabilir. Recursive schema sınırlandırılmalıdır. GraphQL depth kontrolüne benzer risk taşır. Parser library secure limitleri kullanılmalıdır.

Pagination Abuse Nasıl Önlenir?

Pagination kontrol edilmezse client tek request'te çok büyük veri çekebilir. Maximum page size en temel korumadır. Deep offset query database üzerinde pahalı hale gelebilir. Bulk export normal pagination yolundan ayrılmalıdır. Search complexity ve pagination rate birlikte sınırlandırılmalıdır.

Maximum Page Size

Server client'ın istediği page size için üst sınır koyar. Default güvenli küçük değer kullanılır. Response size predictable kalır. Database query daha kontrollü olur. Enterprise export ihtiyacı ayrı endpoint'e taşınabilir.

Deep Pagination

Offset büyüdükçe database çok fazla row tarayabilir. Cursor pagination daha verimli olabilir. Client rastgele çok derin sayfaya gitmek isteyebilir. Search engine farklı strategy kullanabilir. Query execution time limit uygulanmalıdır.

Bulk Export

Milyonlarca row pagination endpoint üzerinden çekilmemelidir. Async export job daha kontrollüdür. Concurrency ve weighted quota uygulanabilir. Result file object storage'a yazılır. Audit büyük data export'u kaydetmelidir.

Search Complexity

Filter kombinasyonu query plan'ı pahalı hale getirebilir. Supported filter allowlist kullanılabilir. Maximum sort ve join seçenekleri sınırlandırılır. Cost-based quota uygulanabilir. Slow query telemetry policy tuning'e yardım eder.

Pagination Rate Limit

Client tüm dataset'i hızlıca sayfa sayfa tarayabilir. User veya API key bazlı rate limit scraping'i yavaşlatır. Cursor reuse ve sequence pattern behavior signal olabilir. Bot detection yardımcı olur. Public data için business policy belirleyicidir.

Third-Party API Kullanımında Güvenlik ve Quota

Kurumsal API yalnız inbound traffic değil outbound dependency'ler açısından da korunmalıdır. Third-party API key secret manager içinde tutulmalıdır. Timeout ve circuit breaker provider failure'ın kendi sistemimize yayılmasını azaltır. Retry budget gereksiz maliyeti önler. Provider quota ve spending limit sürekli izlenmelidir.

Outbound API Key

Provider credential source code içine yazılmamalıdır. Environment bazlı ayrı key kullanılmalıdır. Permission mümkünse scope ile daraltılır. Rotation otomatik yapılır. Usage anomaly key compromise signal olabilir.

Secret Management

Secret manager runtime credential dağıtımı sağlar. Access audit edilebilir. Application yalnız gerekli secret'a erişir. CI loglarına secret düşmemelidir. Rotation sırasında old ve new credential kısa süre overlap edebilir.

Timeout

Third-party call sonsuza kadar beklememelidir. Connection ve request timeout belirlenir. Deadline upstream request'ten propagate edilebilir. Timeout düşük olursa false failure artabilir. Provider p99 behavior ölçülmelidir.

Circuit Breaker

Provider sürekli hata veriyorsa yeni çağrılar geçici kesilir. Local fallback kullanılabilir. Retry storm önlenir. Half-open probe recovery'yi kontrol eder. Breaker metric vendor reliability'yi gösterir.

Retry Budget

Her failed request sınırsız retry edilmemelidir. Provider maliyeti katlanabilir. Operation idempotent olmalıdır. Retry percentage global budget ile sınırlandırılır. 429 provider response'una özellikle uyulmalıdır.

Provider Quota

Provider günlük veya saniyelik quota uygulayabilir. Internal client usage bu sınır altında dağıtılmalıdır. Shared quota tenant'lar arasında adil bölünebilir. Remaining quota monitoring gerekir. Quota exhaustion incident olmadan önce alert üretilmelidir.

Spending Limit

Usage ücretli ise hard veya soft spending cap belirlenebilir. Unexpected traffic denial-of-wallet riski yaratır. Budget tenant veya feature bazında uygulanabilir. Finance alert teknik dashboard'a bağlanabilir. Critical service için emergency override sıkı kontrol edilmelidir.

API Quota ile Billing Aynı Şey midir?

API quota operasyonel kullanım sınırıdır. Metering gerçek kullanım miktarını ölçer. Billing bu kullanımı finansal kayda dönüştürür. Aynı sayaç üç amaç için kullanılırsa retry veya failure durumunda yanlış ücretlendirme oluşabilir. Bu yüzden operational rate limit ve billing ledger ayrı tasarlanmalıdır.

Rate Limiting Operasyonel Kontroldür

Limiter backend ve fair usage'ı korur. Sayaç approximate olabilir. Fail-open durumunda geçici overshoot kabul edilebilir. Billing için bu doğruluk yeterli olmayabilir. Policy runtime safety hedeflidir.

Metering Kullanım Ölçümüdür

Metering event bazında kullanım kaydı üretir. Durable ve replayable olmalıdır. Event duplication deduplication gerektirir. Audit mümkün olmalıdır. Billing bu veriyi daha sonra kullanır.

Billing Finansal Kayıttır

Billing invoice veya balance üretir. Financial accuracy gerektirir. Retry duplicate charge olmamalıdır. Adjustment ve dispute süreci bulunmalıdır. Rate limiter counter silinse bile billing history kaybolmamalıdır.

Retry'ların Double Billing Riski

Client timeout nedeniyle aynı operation'ı tekrar gönderebilir. Backend ilk request'i tamamlamış olabilir. Idempotency key duplicate operation'ı tanır. Billing event business transaction ID ile deduplicate edilir. Network retry finansal işlem sayısını artırmamalıdır.

Billing ve Rate-Limit Sayaçlarını Ayırmak

Limiter hızlı ephemeral store kullanabilir. Billing durable event ledger kullanmalıdır. İki sistem aynı usage identity'sini paylaşabilir. Reconciliation yapılabilir. Birindeki failure diğerinin doğruluğunu bozmamalıdır.

API Planlarına Göre Quota Yönetimi

API planları farklı müşteri segmentlerine farklı quota sağlayabilir. Free tier düşük limit ve sınırlı burst kullanabilir. Standard tier daha yüksek throughput sunar. Enterprise plan contractual quota veya özel değer alabilir. Backend capacity her plan değişikliğinde göz önünde bulundurulmalıdır.

Free Tier

Free tier düşük kullanım hakkı sağlar. Abuse ve bot riskine karşı sıkı limit uygulanabilir. Burst capacity sınırlı tutulabilir. Upgrade path açık olmalıdır. Free quota billing sistemiyle karıştırılmamalıdır.

Standard Tier

Standard müşteri daha yüksek RPS ve aylık quota alır. Normal business workload desteklenir. Support docs rate policy'yi açıklar. Excess usage 429 veya plan upgrade yönlendirmesi üretebilir. Burst normal peak ihtiyacına göre belirlenir.

Enterprise Tier

Enterprise müşteri yüksek throughput veya dedicated capacity isteyebilir. Tenant SLA ayrıca tanımlanır. Custom limit capacity review sonrası verilir. Abuse protection tamamen kaldırılmaz. Contract ve runtime safety limit ayrı tutulabilir.

Burst Capacity

Plan yalnız steady RPS değil burst hakkı da tanımlayabilir. Token bucket capacity bunun için uygundur. Büyük batch job kısa süre yüksek traffic üretebilir. Backend safety margin korunmalıdır. Burst reset davranışı dokümante edilmelidir.

Contractual Quota

Sözleşmede günlük veya aylık usage hakkı bulunabilir. Runtime quota enforcement bu değere yaklaşabilir. Ancak security emergency cap daha düşük olabilir. Reporting müşteriye görünür olmalıdır. Dispute için metering data saklanmalıdır.

Custom Enterprise Limit

Özel limit manuel config olarak dağılmamalıdır. Policy store içinde versionlanmalıdır. Expiration ve owner bilgisi bulunmalıdır. Capacity ve security review yapılmalıdır. Periyodik yeniden değerlendirme gerekir.

API Güvenlik Politikaları Kod Olarak Yönetilebilir mi?

Evet, policy as code kurumsal ölçekte tutarlılığı ciddi biçimde artırır. Gateway configuration repository içinde tutulabilir. Git versioning değişiklik geçmişi sağlar. Pull request review yanlış geniş permission veya aşırı quota riskini azaltır. Automated test ve environment promotion production değişikliğini kontrollü hale getirir.

Policy as Code

Authorization ve rate limit kuralları declarative dosyalarda tutulabilir. İnsan tarafından review edilir. CI syntax ve semantic test çalıştırır. Runtime policy engine bu tanımı uygular. Manual dashboard değişiklikleri drift yaratmamalıdır.

Gateway Configuration as Code

Route, auth plugin ve limiter config repository içinde bulunur. Environment değerleri ayrı parametre olabilir. Change diff açık görünür. Rollback eski version'a dönmekle yapılabilir. Secret config dosyasında tutulmamalıdır.

Git Versioning

Her policy değişikliği commit history bırakır. Kim, ne zaman ve neden değiştirdi görülür. Incident sırasında eski configuration bulunabilir. Tag veya release kullanılabilir. Compliance audit kolaylaşır.

Pull Request Review

Security ve platform owner değişikliği inceleyebilir. Çok yüksek quota veya auth bypass fark edilebilir. Automated policy test sonucu PR'da görünür. Emergency change yine sonradan review edilmelidir. Approval rule risk seviyesine göre değişebilir.

Automated Tests

Policy unit test belirli principal'ın allow veya deny sonucunu doğrular. Rate limit test boundary davranışını kontrol eder. Negative test zorunlu olmalıdır. Regression production'a gitmeden yakalanır. Test data gerçek PII içermemelidir.

Environment Promotion

Aynı policy önce development ve staging'de çalıştırılır. Shadow mode production threshold etkisini gösterebilir. Canary rollout küçük trafik grubuna uygulanır. Başarı sonrası full promotion yapılır. Environment drift minimize edilir.

Rate Limiting Policy CI/CD Süreci

Rate limiting policy doğrudan production dashboard'da değiştirilmemelidir. Policy definition repository'de hazırlanır. Static validation ve unit test temel hataları yakalar. Load test threshold'un backend kapasitesiyle uyumunu gösterir. Shadow ve canary aşamaları gerçek kullanıcı etkisini ölçer.

Policy Definition

Limit key, algorithm ve threshold açık biçimde tanımlanır. Endpoint veya consumer scope belirtilir. Fail behavior yazılır. Owner ve reason metadata'sı eklenebilir. Policy readable tutulmalıdır.

Static Validation

Schema yanlış config'i reddeder. Negative threshold veya eksik key yakalanır. Unknown endpoint reference tespit edilir. Security rule minimum değer uygulayabilir. CI burada hızlı fail eder.

Unit Tests

Request sequence simüle edilir. Boundary ve burst davranışı doğrulanır. 429 response test edilir. Fail-open veya fail-closed scenario eklenir. Policy change regression oluşturmaz.

Load Tests

Backend saturation ve limiter throughput birlikte ölçülür. Shared store latency izlenir. Burst scenario test edilir. Hot consumer key denenir. Safety margin veriye göre belirlenir.

Staging

Policy production'a benzer gateway topology'de çalışır. Multiple node distributed counter doğrulanır. Redis failure test edilebilir. Client SDK 429 handling kontrol edilir. Environment data scale farkı not edilir.

Shadow Mode

Policy request'i bloke etmeden karar üretir. Kaç gerçek request'in reddedileceği görülür. False positive segment'leri bulunur. Threshold ayarlanır. Shadow result user response'u etkilemez.

Canary Rollout

Küçük consumer veya trafik yüzdesi enforcement altına alınır. 429 ve business success izlenir. Unexpected client bug görünür olabilir. Problemde policy hızla geri alınır. Stability süresi sonrası oran artırılır.

Production Promotion

Policy tüm hedef traffic'e uygulanır. Dashboard ve alert hazır olmalıdır. Change window boyunca owner izler. Client support communication gerekebilir. Son config version audit edilir.

Shadow Mode Rate Limiting Nedir?

Shadow mode rate limiting request'i engellemeden policy'nin nasıl karar vereceğini hesaplar. Production traffic üzerinde threshold kalibrasyonu sağlar. Kaç gerçek kullanıcının etkileneceği ölçülür. False positive segment'leri enforcement öncesi bulunur. Özellikle yeni kurumsal limit rollout'unda risk azaltır.

Request'i Bloklamadan Limit Kararı Üretmek

Limiter normal counter state'ini hesaplar. Limit aşılırsa yalnız metric veya log üretir. Request backend'e geçmeye devam eder. Gerçek traffic shape görülür. Performance overhead yine ölçülmelidir.

Kaç Gerçek Kullanıcı Etkilenirdi?

Shadow denied count user ve tenant bazında ölçülür. High-value customer etkisi görülebilir. Endpoint dağılımı incelenir. Unexpected client retry loop bulunabilir. Policy business owner ile gözden geçirilir.

False Positive Analizi

Legitimate automation limit aşabilir. Enterprise batch job yanlış abuse olarak görülebilir. Segment behavior karşılaştırılır. Threshold veya key dimension düzeltilir. Anti-abuse ve fair-use policy ayrılabilir.

Production Öncesi Threshold Kalibrasyonu

Average ve peak traffic üzerinden safe threshold belirlenir. Backend capacity safety margin eklenir. Shadow mode uzun enough farklı gün ve saatleri kapsamalıdır. Attack traffic baseline'ı bozmamalıdır. Enforcement gradual yapılır.

Rate Limit Threshold Nasıl Belirlenir?

Rate limit değeri tahminle seçilmemelidir. Ortalama trafik, p95/p99 ve peak RPS birlikte incelenmelidir. Backend kapasitesi gerçek load test ile ölçülmelidir. Request cost ve business SLA threshold'u etkiler. Security risk sensitive endpoint'lerde normal kullanımın çok altında farklı anti-abuse limit gerektirebilir.

Ortalama Trafik

Average RPS normal kullanım baseline'ını verir. Tek başına yeterli değildir. Burst ve peak behavior görünmez. Consumer dağılımı ayrıca incelenmelidir. Threshold average'ın hemen üstünde seçilmemelidir.

p95/p99 Trafik

Consumer usage distribution tail davranışı gösterir. Legitimate power user burada ortaya çıkar. p99 üzerine safety margin eklenebilir. Çok büyük outlier abuse olabilir. Tenant planı segmentlere ayrılabilir.

Peak RPS

Campaign veya batch döneminde kısa yüksek trafik görülebilir. Token bucket burst capacity bu davranışı destekler. Peak backend saturation'a yaklaşmamalıdır. Historical event analiz edilir. Future growth forecast eklenir.

Backend Kapasitesi

Service kaç RPS'de p99 SLO'yu bozuyor ölçülmelidir. Database pool ve downstream dependency dahil edilir. Rate limit saturation noktasının altında kalır. Global safety margin bırakılır. Autoscaling hızının instant olmadığı unutulmamalıdır.

Request Cost

Heavy search ve export aynı RPS limitini kullanmamalıdır. Weighted unit throughput ile ilişkilendirilir. Cost telemetry gerçek CPU ve database time'dan gelebilir. Policy sade kalmalıdır. Cost değiştiğinde recalibration yapılır.

Business SLA

Contract müşteri minimum throughput beklentisi taşıyabilir. Rate limit bu değerden düşük olmamalıdır. Emergency protection ayrı cap olabilir. Enterprise dedicated capacity gerekebilir. SLA ve security exception süreçleri koordineli yürütülür.

Security Risk

Login endpoint normal kullanımda çok düşük deneme hızına ihtiyaç duyar. Bu yüzden threshold capacity değil attack resistance üzerinden belirlenir. User + IP dimension uygulanabilir. Failed attempt farklı counter kullanabilir. Risk yüksekse progressive delay eklenir.

Load Test ile Rate Limit Kalibrasyonu

Load test backend'in gerçek saturation noktasını gösterir. Database connection pool, CPU, memory ve p99 latency birlikte izlenmelidir. Rate limit bu kırılma noktasının güvenli altında seçilir. Safety margin deploy veya dependency değişikliğine alan bırakır. Burst test token bucket capacity'nin backend'i boğmadığını doğrular.

Backend Saturation Noktası

Load adım adım artırılır. Error ve latency hızla bozulduğu nokta tespit edilir. CPU tek signal değildir. Queue ve downstream saturation görülebilir. Rate policy bu noktanın altında kalır.

Database Connection Pool

Pool wait request latency'sini yükseltebilir. Çok yüksek API concurrency database connection'larını tüketir. Pool size sonsuz artırılmamalıdır. Rate limit ve application concurrency birlikte ayarlanır. Query optimization ayrıca yapılmalıdır.

CPU ve Memory

CPU saturation throughput tavanını gösterebilir. Memory pressure GC veya OOM riskini artırır. Payload-heavy endpoint farklı profile sahiptir. Autoscaling reaction süresi ölçülür. Limit capacity step'leriyle uyumlu olmalıdır.

p99 Latency

Average normal görünürken tail kötüleşebilir. SLO p99 üzerinden tanımlanabilir. Rate limit threshold p99 bozulmadan önce devreye girmelidir. Different endpoint ayrı curve taşır. Load test production-like data kullanmalıdır.

Safety Margin

Backend maksimum kapasitesine kadar sürekli çalıştırılmamalıdır. Failure veya traffic burst için headroom gerekir. Yüzde değer workload'a göre belirlenir. Downstream dependency'nin daha düşük limit'i olabilir. Margin periyodik yeniden test edilmelidir.

Burst Test

Steady load yeterli değildir. Birkaç saniyelik yüksek burst simüle edilmelidir. Token bucket capacity test edilir. Connection storm ve cache miss etkisi görülür. Recovery süresi ölçülür.

Rate Limit Policy Drift Nasıl Önlenir?

Development, staging ve production ortamlarında farklı policy tanımları drift yaratabilir. Tek source of truth kullanılmalıdır. Environment-specific değerler parametre olarak ayrılabilir. CI expected ve actual configuration'ı karşılaştırabilir. Drift detection özellikle emergency manual değişikliklerden sonra önemlidir.

Development

Developer düşük test threshold kullanabilir. Policy structure production ile aynı kalmalıdır. Local bypass güvenlik davranışını tamamen gizlememelidir. Test utility quota reset sağlayabilir. Config repository'den gelmelidir.

Staging

Production topology'ye yakın distributed rate limit test edilir. Daha düşük traffic nedeniyle threshold farklı olabilir. Algorithm ve fail behavior aynı kalmalıdır. Chaos test burada yapılabilir. Gateway version production ile uyumlu olmalıdır.

Production

Enforcement gerçek müşteri trafiğini etkiler. Manual değişiklik minimum tutulur. Policy release version dashboard'da görünür. Alert ve rollback hazırdır. Exception kayıt altına alınır.

Tek Policy Definition

Core policy tek repository içinde tutulur. Ortama göre override yalnız value seviyesinde yapılır. Logic farklılaşmaz. Review kolaylaşır. Drift ihtimali azalır.

Environment-Specific Values

Production quota staging'den daha yüksek olabilir. Consumer IDs environment'a göre değişir. Secret veya credential policy definition içinde tutulmaz. Values schema ile doğrulanır. Default güvenli olmalıdır.

Drift Detection

Runtime gateway config repository expectation ile karşılaştırılır. Fark alert üretir. Authorized emergency change daha sonra Git'e geri yazılmalıdır. Unknown plugin veya route policy tespit edilebilir. Compliance report otomatik oluşturulabilir.

API Inventory ve Shadow API Problemi

API envanteri olmadan kurumsal güvenlik politikası eksik kalır. Shadow API merkezi platform tarafından bilinmeyen endpoint'tir. Zombie API artık kullanılmadığı halde açık kalan servis olabilir. Deprecated version eski auth veya rate limit policy taşıyabilir. İnternete açık staging API'leri de ciddi saldırı yüzeyi oluşturur.

API Inventory Nedir?

Tüm API'lerin endpoint, owner, version ve risk bilgisi tutulur. Public veya internal sınıflandırması yapılır. Authentication yöntemi kaydedilir. Lifecycle state görünür olur. Automated discovery inventory'yi güncel tutabilir.

Shadow API

Ekip merkezi gateway dışında endpoint yayınlayabilir. Standard auth veya logging uygulanmaz. Security team API'den habersiz olabilir. Network discovery ve traffic analysis shadow API bulmaya yardım eder. Owner atanmalıdır.

Zombie API

Eski servis kullanılmıyor gibi görünür ancak internete açık kalır. Dependency veya secret güncellemesi yapılmaz. Attack surface gereksiz büyür. Traffic zero olduğu doğrulandıktan sonra decommission edilir. Route inventory lifecycle policy taşımalıdır.

Deprecated Versions

v1 endpoint eski authentication kullanabilir. Client migration bitmediği için açık kalabilir. Rate policy v2 ile aynı güvenlik seviyesine çekilmelidir. Sunset date belirlenir. Usage metric remaining client'ları gösterir.

İnternete Açık Staging API'leri

Staging environment production data veya weak credential içerebilir. Search engine veya scanner tarafından bulunabilir. Network access sınırlandırılmalıdır. Production auth standardı mümkün olduğunca korunmalıdır. Test secret'ları düzenli rotate edilmelidir.

Owner Olmayan API'ler

Owner yoksa security patch ve incident response belirsiz kalır. Her API accountable team taşımalıdır. Inventory owner bilgisini zorunlu alan yapabilir. Organizasyon değişiminde ownership güncellenmelidir. Owner'sız API risk olarak işaretlenmelidir.

Eski API Versiyonları Rate Limit Bypass Yaratabilir mi?

Evet, eski API version farklı gateway veya policy kullanıyorsa bypass oluşabilir. v1 daha yüksek quota veya zayıf authentication taşıyabilir. Deprecated endpoint saldırgan tarafından özellikle hedeflenebilir. Merkezi gateway policy tüm version'ları kapsamalıdır. Sunset ve decommission süreci güvenlik programının parçasıdır.

v1 ve v2 Arasında Farklı Politikalar

Yeni version güvenlik standardı alırken eski route unutulabilir. Saldırgan v1'e yönelir. Inventory policy farkını göstermelidir. Minimum security baseline version'dan bağımsız uygulanır. Business quota gerekirse farklı olabilir.

Deprecated Endpoint

Deprecated route traffic almaya devam edebilir. Client migration süresi vardır. Security patch yine uygulanmalıdır. New feature eklenmese bile rate limit korunur. Sunset date açıkça duyurulur.

Eski Authentication

Legacy API basic auth veya uzun ömürlü token kullanabilir. Modern gateway arkasına alınabilir. Client migration planı hazırlanır. Weak auth decommission süresini hızlandırabilir. Exception risk kabulü gerektirir.

Merkezi Gateway Politikası

Tüm public version aynı gateway'den geçerse minimum control standardize edilir. Auth, WAF ve global rate limit uygulanır. Route-specific override versionlanır. Bypass direct backend access engellenmelidir. Network policy gateway dışı ingress'i kapatabilir.

Sunset ve Decommissioning

Deprecated API sonsuza kadar açık kalmamalıdır. Usage report kalan client'ları gösterir. Migration support sağlanır. Final date sonrası route kapatılır. Monitoring unexpected traffic'i kısa grace period boyunca izleyebilir.

North-South ve East-West API Güvenliği

North-south trafik external client ile internal sistem arasındaki akıştır. East-west trafik service-to-service iletişimdir. API gateway external traffic için doğal enforcement noktasıdır. Service mesh internal identity ve mTLS sağlayabilir. Internal rate limits compromised service'in blast radius'unu sınırlar.

External Client Trafiği

Internet client yüksek threat exposure taşır. Edge, WAF ve gateway üzerinden geçmelidir. OAuth veya API key doğrulanır. Rate limit ve bot signal uygulanır. Backend direct public erişim almamalıdır.

Internal Service Trafiği

Internal service güvenilir kabul edilmemelidir. Workload identity kullanılmalıdır. mTLS network identity sağlar. Service-level authorization minimum permission uygular. Internal abuse veya bug rate limit ile sınırlandırılır.

API Gateway

Gateway north-south policy standardizasyonu sağlar. External identity burada doğrulanır. Public endpoint inventory merkezi hale gelir. High availability kritik önemdedir. Internal service trafiği her zaman gateway'den geçmek zorunda değildir.

Service Mesh

Mesh east-west traffic policy için uygundur. Workload certificate otomatik dağıtılır. Service identity route authorization'a bağlanabilir. Telemetry merkezi hale gelir. Application-level user context gerektiğinde propagate edilmelidir.

mTLS

mTLS internal network interception riskini azaltır. Client ve server kimliği doğrulanır. Certificate rotation otomatik olmalıdır. Compromised workload kendi certificate'iyle hâlâ request gönderebilir. Authorization bu nedenle ayrıca gerekir.

Internal Rate Limits

Bug'lı service downstream'e milyonlarca request gönderebilir. Internal limiter cascade failure'ı azaltır. Service identity rate key olabilir. Critical dependency için concurrency limit uygulanabilir. Retry budget özellikle önemlidir.

“İç Ağdaki API Güvenlidir” Varsayımı Neden Yanlıştır?

Internal network tek güvenlik sınırı değildir. Compromised service saldırganın iç API'lere erişmesine yol açabilir. Service account abuse ve lateral movement blast radius'u büyütür. Zero Trust her request'in identity ve permission açısından doğrulanmasını hedefler. Internal rate limiting de hatalı veya kötü niyetli trafiği sınırlar.

Compromised Service

Bir service vulnerability nedeniyle ele geçirilebilir. Saldırgan o service'in network erişimini kullanır. Least privilege downstream permission etkisini azaltır. mTLS identity olayı görünür kılar. Secret rotation hızlı yapılmalıdır.

Lateral Movement

Saldırgan ilk service'ten başka internal sistemlere ilerleyebilir. Flat network bunu kolaylaştırır. Network segmentation ve service authorization sınır koyar. Audit unusual service call pattern'ini yakalayabilir. Blast radius tasarım hedefidir.

Service Account Abuse

Long-lived service credential sızabilir. Kullanılmayan yetkiler saldırgan için fırsattır. Workload identity statik secret ihtiyacını azaltır. Token kısa ömürlü olmalıdır. Service account usage behavior izlenmelidir.

Blast Radius

Tek compromised identity tüm platforma erişmemelidir. Permission service veya resource scope ile sınırlandırılır. Rate limit damage hızını azaltır. Network policy erişilebilir destination'ı sınırlar. Secret store da identity bazlı control uygular.

Zero Trust

Zero Trust network location yerine identity ve policy'ye dayanır. Internal request de authenticate edilir. Authorization her access'te uygulanır. Device veya workload posture ek signal olabilir. Continuous monitoring güven modelini destekler.

API Rate Limiting Observability

Rate limiting yalnız 429 sayısı üzerinden izlenmemelidir. Allowed ve denied request birlikte görülmelidir. Consumer başına request ve quota utilization fair-use pattern'ini gösterir. Limit decision latency request performansını etkiler. Shared store latency limiter altyapısının sağlık göstergesidir.

Allowed Requests

Policy'den geçen request sayısı throughput baseline'ını gösterir. Tenant ve endpoint dimension faydalıdır. Sudden drop limiter bug gösterebilir. Traffic seasonality analiz edilir. Allowed ile backend success birlikte karşılaştırılır.

Denied Requests

Limit nedeniyle reddedilen request count tutulur. Reason code hangi policy'nin tetiklendiğini gösterir. Consumer concentration attack signal olabilir. Legitimate client bug burada görünür. Shadow ve enforced decision ayrı etiketlenmelidir.

HTTP 429 Rate

Toplam traffic içindeki 429 oranı izlenir. Ani artış policy veya client problemine işaret eder. Endpoint bazında breakdown yapılır. Enterprise customer impact ayrıca görülür. 429 normal abuse protection sinyali olabilir.

Requests per Consumer

Top user, tenant veya API key listesi capacity planning sağlar. Sudden usage change credential compromise gösterebilir. Long tail distribution threshold tuning'e yardım eder. PII yerine internal ID kullanılabilir. Cardinality monitoring backend'i aşırı yüklememelidir.

Quota Utilization

Tenant'ın quota'nın yüzde kaçını kullandığı izlenir. Sürekli yüzde yüz usage plan ihtiyacını gösterebilir. Unexpected spike abuse olabilir. Customer-facing dashboard ile paylaşılabilir. Metering sistemiyle reconcile edilebilir.

Limit Decision Latency

Limiter'ın karar vermesi request path'e ek latency getirir. p95 ve p99 ölçülmelidir. Redis veya policy engine yavaşlığı görülebilir. Timeout threshold tuning gerekir. Local fallback performance ayrı izlenir.

Shared Store Latency

Counter store command latency limiter health'ini gösterir. Network veya CPU saturation p99'u artırabilir. Cluster failover spike oluşturabilir. Alert threshold request SLO ile bağlantılıdır. Capacity plan limiter traffic'ini hesaba katmalıdır.

API Security Dashboard'ında Hangi Metrikler Olmalı?

API security dashboard traffic, identity ve abuse sinyallerini aynı görünümde toplamalıdır. RPS ve top consumers normal kullanım davranışını gösterir. Authentication failure ve authorization denial saldırı veya config sorununa işaret edebilir. 429, 4xx ve 5xx oranları policy etkisini görünür yapar. Endpoint saturation ve abuse alert operasyon ekibine erken uyarı sağlar.

RPS

Global ve endpoint RPS temel traffic göstergesidir. Peak ve average ayrı görünmelidir. Region breakdown faydalıdır. Attack spike hızlı fark edilir. Capacity trend planning'e yardım eder.

Top Consumers

En fazla trafik üreten tenant, user veya API key listelenir. Normal enterprise consumer ile abnormal spike ayrıştırılır. Usage history karşılaştırılır. Sensitive identity maskelenebilir. Owner metadata investigation'ı hızlandırır.

Top Blocked Consumers

En fazla rate limit veya WAF block alan consumer görünür. Attack veya client bug olabilir. Reason code gösterilmelidir. Repeated violation security review tetikleyebilir. Customer support için context sağlar.

Authentication Failures

Invalid token, expired token ve credential failure ayrı sınıflandırılabilir. Password spraying pattern'i bulunabilir. Issuer outage da spike yaratabilir. Endpoint ve IP dimension önemlidir. Sensitive token detayları loglanmamalıdır.

Authorization Denials

403 veya policy deny sayısı izlenir. BOLA denemesi pattern oluşturabilir. Normal user UX bug'u da fazla deny üretebilir. Resource type breakdown faydalıdır. Policy change sonrası regression görülebilir.

429 Rate

Limiter enforcement yoğunluğunu gösterir. Shadow mode ile karşılaştırılabilir. Client SDK compliance değerlendirilebilir. Attack sırasında normal artış görülebilir. Uzun süre yüksek oran threshold sorunu olabilir.

4xx/5xx

4xx client veya policy kaynaklı sorunları gösterir. 5xx backend reliability sinyalidir. Rate limit nedeniyle backend 5xx düşebilir. Authentication outage 4xx spike oluşturabilir. Dashboard zaman korelasyonu sağlamalıdır.

Endpoint Saturation

CPU veya downstream pool belirli endpoint nedeniyle doygunlaşabilir. Request cost ile correlate edilir. Heavy route daha sıkı quota isteyebilir. p99 latency eklenir. Capacity remediation planlanır.

Abuse Alerts

Credential stuffing veya scraping detection ayrı alert üretir. Risk score threshold üzerinden çalışabilir. Alert rate çok yüksekse fatigue oluşur. Severity ve owner belirlenmelidir. Incident runbook linklenebilir.

Rate Limiting İçin SLO Tanımlanmalı mı?

Evet, rate limiter request path'in kritik dependency'siyse kendi SLO'suna sahip olmalıdır. Limiter availability uygulamanın erişilebilirliğini etkiler. Enforcement latency p99 request süresine eklenir. Policy accuracy ve false positive güvenlik kalitesini gösterir. Counter availability ve bypass rate ayrıca ölçülebilir.

Limiter Availability

Limiter decision service'in uptime oranıdır. Shared store outage dahil edilmelidir. Fail-open response availability'yi gizleyebilir. Degraded mode ayrıca metric olmalıdır. SLO endpoint riskine göre farklılaşabilir.

Enforcement Latency

Rate decision mümkün olduğunca düşük latency'de verilmelidir. p95 ve p99 ölçülür. Remote global store gecikme ekleyebilir. Cache hit ayrı izlenebilir. Threshold request SLO'yu bozmamalıdır.

Policy Accuracy

Gerçek limit aşımının doğru biçimde yakalanması hedeflenir. Distributed approximate model küçük overshoot yapabilir. Expected vs actual test traffic ile ölçülebilir. Critical policy daha yüksek doğruluk ister. Algorithm behavior dokümante edilmelidir.

False Positive Rate

Legitimate request yanlış biçimde bloke edilirse user impact oluşur. Shadow mode bunu ölçmeye yardım eder. Segment ve endpoint breakdown gerekir. Enterprise traffic ayrıca incelenir. Threshold tuning düzenli yapılmalıdır.

Counter Availability

Shared store read/write erişilebilirliği ayrı metric'tir. Timeout oranı izlenir. Failover event kaydedilir. Local fallback kullanım süresi görünür olur. Capacity saturation önceden alert üretmelidir.

Limit Bypass Rate

Policy gereği reddedilmesi gereken traffic'in geçtiği durumlar ölçülebilir. Race condition veya fail-open sebep olabilir. Attack simulation ile doğrulanabilir. Critical endpoint'te hedef çok düşük olmalıdır. Incident sonrası root cause incelenir.

API Abuse Nasıl Tespit Edilir?

API abuse yalnız yüksek RPS demek değildir. Credential stuffing birçok login kombinasyonu dener. Password spraying az sayıda parola ile çok user hedefler. Enumeration ve scraping düşük hızda da yapılabilir. Behavioral analytics user, IP, device ve tenant pattern'lerini birlikte değerlendirir.

Credential Stuffing

Sızmış username-password çiftleri otomatik denenir. Başarısız login sayısı yüksektir. IP rotation görülebilir. User + IP limit ve bot detection uygulanır. Successful unusual login risk score üretmelidir.

Password Spraying

Aynı birkaç parola birçok account'ta denenir. User-level failed count düşük kalabilir. IP veya device global pattern önemlidir. Identity provider davranış analizi yapabilir. MFA account takeover riskini azaltır.

Enumeration

Attacker valid username, card veya resource keşfetmeye çalışır. Response body ve timing bilgi sızdırabilir. Failed lookup velocity izlenir. Resource-level rate limit uygulanır. Error message normalize edilir.

Scraping

Client büyük miktarda public veya protected data toplar. Request rate normal görünebilir. Pagination sequence ve navigation pattern sinyal sağlar. Token ve device relationship analiz edilir. Business policy scraping'in ne kadar kabul edileceğini belirler.

Rotating IPs

Attacker birçok IP arasında traffic dağıtır. IP limiter etkisi azalır. User, client ve resource limit daha önemli hale gelir. Residential proxy signal kullanılabilir. Behavior correlation central system'de yapılır.

Unusual Tenant Usage

Tenant normalden on kat fazla API kullanmaya başlayabilir. Client bug veya credential compromise olabilir. Historical baseline karşılaştırılır. Alert tenant owner'a gider. Emergency quota geçici düşürülebilir.

Behavioral Analytics

Tek request yerine sequence ve pattern değerlendirilir. Login sonrası anormal export buna örnektir. Device, geography ve velocity sinyalleri birleştirilir. Risk score adaptive policy'ye aktarılabilir. False positive sürekli izlenmelidir.

Rate Limiting Tek Başına Botları Durdurur mu?

Hayır, gelişmiş botlar rate limit'i aşmak için IP ve identity dağıtabilir. Human-like automation normal request hızında çalışabilir. Device fingerprint ve behavior analizi ek signal sağlar. Bot management merkezi risk değerlendirmesi sunabilir. Risk-based authentication sensitive flow'larda ek doğrulama isteyebilir.

IP Rotation

Bot her request veya session için farklı IP kullanabilir. Per-IP threshold etkisizleşir. User veya device limit gerekir. Network reputation yine yardımcı olabilir. Global pattern correlation önemlidir.

Distributed Botnets

Binlerce gerçek cihaz saldırıya katılabilir. Her node çok düşük traffic üretir. Aggregate business flow abnormal görünür. Resource ve global limit işe yarar. Behavioral analytics cluster pattern'i yakalayabilir.

Human-Like Automation

Bot normal kullanıcı aralıklarında request gönderebilir. Hız tek signal değildir. Navigation sequence ve timing pattern analiz edilir. Challenge gerektiğinde uygulanır. Accessibility ve UX etkisi dikkate alınmalıdır.

Device Fingerprinting

Browser ve device özellikleri risk sinyali oluşturabilir. Fingerprint kesin identity değildir. Privacy ve regulation açısından dikkat gerekir. IP rotation ile birlikte correlation sağlar. Spoofing mümkün olduğu için tek başına kullanılmamalıdır.

Bot Management

Bot platformu behavior, reputation ve fingerprint signal birleştirir. Edge'de erken action alınabilir. Known good bot allowlist kullanılabilir. Risk score gateway'e iletilebilir. Rule tuning false positive'i azaltır.

Risk-Based Authentication

Normal traffic password veya token ile devam eder. Yüksek riskte MFA veya ek challenge istenir. Account takeover attack zorlaşır. Rate limit threshold risk skoruna göre düşebilir. User friction yalnız gerektiğinde artar.

API Güvenliği Nasıl Test Edilir?

API güvenlik testi authentication'tan başlayıp object authorization ve abuse kontrollerine kadar uzanmalıdır. Positive test tek başına yeterli değildir. BOLA ve negative authorization senaryoları özellikle önemlidir. Rate limit, payload ve schema boundary testleri yapılmalıdır. Fuzz ve penetration test daha geniş saldırı yüzeyini değerlendirir.

Authentication Tests

Missing, expired ve invalid token test edilir. Wrong issuer ve audience reddedilmelidir. Algorithm manipulation denenebilir. Revoked credential behavior doğrulanır. Error response hassas bilgi sızdırmamalıdır.

Authorization Negative Tests

Düşük role sahip user yüksek privilege operation denemelidir. Tenant A kullanıcısı Tenant B kaynağına erişememelidir. Method change test edilir. Property-level update kontrol edilir. CI içinde otomatik çalışmalıdır.

BOLA Tests

Resource ID sistematik değiştirilir. Başka user object'i target edilir. UUID kullanımı test gereksinimini ortadan kaldırmaz. Ownership ve relation policy doğrulanır. Error timing fazla bilgi sızdırmamalıdır.

Rate Limit Tests

Threshold'a kadar request kabul edilmelidir. Aşımda 429 dönmelidir. Window boundary ve burst scenario test edilir. Distributed node'larda total limit doğrulanır. Store failure behavior ayrıca test edilir.

Payload Limit Tests

Maximum body size üstü request reddedilir. Large array ve nested object denenir. Compression ve malformed body test edilir. File upload limit kontrol edilir. Backend memory etkilenmemelidir.

Schema Tests

Unknown field veya wrong type gönderilir. Required field eksikliği test edilir. Additional property behavior doğrulanır. Response schema sensitive field sızdırmamalıdır. Version compatibility ayrıca test edilir.

Fuzz Testing

Unexpected input ve edge case otomatik üretilir. Parser crash veya 5xx aranır. Rate limit fuzz traffic'i test ortamında kontrol eder. Sensitive production data kullanılmaz. Bulgu reproducible request olarak saklanır.

Penetration Testing

Deneyimli tester API'yi attacker perspective'ten değerlendirir. Authentication ve business logic birlikte incelenir. Chained vulnerability daha iyi görülebilir. Scope ve authorization önceden belirlenir. Bulgu remediation sonrası retest edilir.

Rate Limiter Chaos Testleri

Rate limiter normal load altında çalışmakla kalmamalı, dependency failure durumunda da beklenen davranışı göstermelidir. Redis veya gateway node kasıtlı olarak durdurulabilir. Network partition ve store latency simüle edilebilir. Clock drift zaman tabanlı algoritmaları etkileyebilir. Fail-open ve fail-closed kararı chaos test ile doğrulanmalıdır.

Redis'i Durdurmak

Shared counter store erişilemez hale getirilir. API'nin fail policy'si gözlenir. Local emergency limit devreye girmelidir. Latency spike ölçülür. Alert doğru ekibe ulaşmalıdır.

Gateway Node Kaybetmek

Bir gateway instance kapatılır. Load balancer traffic'i diğer node'lara verir. Distributed counter state korunmalıdır. Remaining node capacity yeterli olmalıdır. Client error spike oluşmamalıdır.

Network Partition

Gateway ile counter store arasındaki network kesilir. Timeout ve circuit breaker behavior test edilir. Multi-region counter divergence ölçülür. Recovery sonrası state normalize edilir. Split-brain counter effect değerlendirilir.

Counter Store Latency

Redis response yapay olarak yavaşlatılır. API p99 etkisi görülür. Timeout threshold doğrulanır. Local fallback devreye girebilir. Limiter request path'i kilitlememelidir.

Clock Drift

Token bucket veya GCRA time hesabı yanlış clock'tan etkilenebilir. Node clock'ları farklılaştırılır. Monotonic time kullanımı test edilir. Negative refill oluşmamalıdır. NTP failure runbook'a eklenebilir.

Fail-Open/Closed Davranışını Doğrulamak

Public ve sensitive endpoint farklı sonuç vermelidir. Policy config gerçekten runtime'da uygulanıyor mu görülür. Emergency override test edilir. Metric degraded mode'u göstermelidir. Recovery sonrası normal enforcement'a dönüş doğrulanır.

API Security Incident Runbook

API abuse incident sırasında hangi adımın kim tarafından uygulanacağı önceden yazılmalıdır. Saldırgan veya compromised client mümkün olduğunca hızlı tanımlanır. Token veya API key revoke edilebilir. Emergency rate limit ve endpoint disablement blast radius'u azaltır. Log preservation ve postmortem olaydan öğrenmeyi sağlar.

Saldırgan Client'ı Tanımlamak

IP tek signal olarak yeterli olmayabilir. User, API key, device ve tenant bilgisi korele edilir. Correlation ID örnek request'leri bulur. SIEM historical behavior gösterebilir. Yanlış consumer bloke edilmemelidir.

Token/API Key Revocation

Compromised credential mümkün olduğunca hızlı geçersiz yapılır. Cache revocation'ı geciktirmemelidir. Replacement credential secure channel ile verilir. Scope geçici daraltılabilir. Revocation event audit edilir.

Emergency Rate Limit

Attack mode daha düşük threshold uygulayabilir. Belirli consumer veya endpoint hedeflenebilir. Global customer impact minimum tutulur. Change audit trail bırakır. Incident sonrası normal policy kontrollü geri getirilir.

Endpoint Disablement

Çok riskli operation geçici kapatılabilir. Feature flag veya gateway route kullanılır. Business owner bilgilendirilir. Client uygun error alır. Recovery criteria önceden tanımlanmalıdır.

WAF/Bot Rule

Observed attack pattern edge'de bloke edilebilir. Rule çok geniş olmamalıdır. Shadow veya monitor mode mümkünse kullanılır. IP reputation ve fingerprint eklenebilir. Rule expiration date ile geçici olabilir.

Log Preservation

Incident logları retention cleanup'tan korunmalıdır. Token veya sensitive payload maskelenmiş olmalıdır. Audit ve legal requirement dikkate alınır. Time synchronization önemlidir. Evidence access sınırlanmalıdır.

Recovery

Attack durduktan sonra credential ve policy normalleştirilir. Backend backlog temizlenir. Customer impact ölçülür. Monitoring yakın takipte kalır. Root cause tamamen kapanmadan emergency control kaldırılmamalıdır.

Postmortem

Olay timeline ve teknik nedenlerle belgelenir. Hangi control çalıştı veya çalışmadı değerlendirilir. Action item owner ve deadline alır. Policy testleri güncellenir. Öğrenim blame yerine sistem iyileştirmesine odaklanır.

Kurumsal API Security Governance

Kurumsal API güvenliği yalnız platform ekibinin sorumluluğu değildir. API owner service davranışını ve riskini bilir. Application Security policy ve test standardını şekillendirir. IAM, SRE, product ve compliance farklı sorumluluk taşır. Net ownership olmadan policy exception ve incident yönetimi zayıflar.

API Owner

Service endpoint ve business riskinden sorumludur. Inventory bilgisini güncel tutar. Rate limit requirement tanımlar. Deprecated version migration'ını yönetir. Incident sırasında domain context sağlar.

Platform Team

Gateway, rate limiter ve shared policy altyapısını işletir. Common defaults sağlar. High availability ve observability sorumluluğu taşır. Developer self-service tooling geliştirebilir. Policy drift'i kontrol eder.

Application Security

Threat model ve security baseline oluşturur. BOLA ve auth test standardını belirler. High-risk policy change review edebilir. Penetration testing koordine eder. Incident sonrası güvenlik remediation'ını takip eder.

IAM Team

Identity provider ve OAuth client lifecycle'ını yönetir. Token policy ve MFA standardını belirler. Service account governance sağlar. Credential rotation süreçlerini kurar. Compromise durumunda revocation desteği verir.

SRE

Availability ve performance SLO'larını yönetir. Limiter latency ve store health izler. Chaos ve load test yürütür. Incident response içinde reliability kararlarını alır. Capacity planning threshold tuning'e girdi sağlar.

Product Owner

Business flow ve customer SLA hakkında karar verir. Fair-use quota ürün planıyla uyumlu olmalıdır. False positive user impact'ini değerlendirir. Enterprise exception business gerekçesi sağlar. Security friction ile UX dengesini kurar.

Compliance

Log retention ve personal data handling requirement'larını belirler. Audit trail ihtiyacını tanımlar. Payment veya regulated API için ek kontrol isteyebilir. Policy evidence'ını gözden geçirir. Data minimization programına katkı sağlar.

Rate Limit Policy Exception Süreci

Enterprise client bazen standart quota'nın üzerinde kapasite talep edebilir. Bu değişiklik yalnız business isteğiyle yapılmamalıdır. Capacity ve security review etkileri değerlendirmelidir. Approval owner ve expiration date ile kayıt altına alınmalıdır. Periyodik yeniden değerlendirme geçici istisnanın kalıcı zayıflığa dönüşmesini önler.

Enterprise Client Yüksek Quota Talebi

Müşteri workload pattern'ini açıklamalıdır. Peak ve steady traffic ayrılır. Endpoint listesi belirlenir. Dedicated capacity gerekip gerekmediği değerlendirilir. Talep sınırsız quota anlamına gelmez.

Business Gerekçesi

Revenue veya contractual ihtiyaç açıkça yazılır. Batch window veya campaign gibi süreli neden olabilir. Product owner onayı alınır. Kullanım tahmini eklenir. Gereksiz geniş istisna reddedilebilir.

Capacity Review

Backend ve database yeni yükü kaldırabilir mi test edilir. Downstream provider quota kontrol edilir. Safety margin korunur. Load test gerekebilir. Capacity yetersizse architecture değişikliği planlanır.

Security Review

Yüksek quota credential compromise blast radius'unu büyütür. mTLS veya stronger auth istenebilir. Abuse monitoring daha hassas ayarlanabilir. Emergency cap tutulur. Least privilege korunmalıdır.

Approval

Platform ve security owner ortak onay verebilir. Change policy repository'ye eklenir. Audit record tutulur. Customer communication yapılır. Emergency request için ayrı hızlı süreç olabilir.

Expiration Date

Geçici exception süresiz olmamalıdır. Config otomatik expire olabilir. Renewal için yeniden review gerekir. Campaign sonrası limit normale döner. Expired exception alert üretebilir.

Periyodik Yeniden Değerlendirme

Kalıcı enterprise limit de düzenli kontrol edilmelidir. Kullanım gerçekten yüksek mi görülür. Capacity ve risk değişmiş olabilir. Contract renewal iyi review noktasıdır. Kullanılmayan istisna kaldırılır.

API Güvenliği ve KVKK

API güvenlik logları kişisel veri içerebilir. IP adresi ve user identifier retention açısından değerlendirilmelidir. Authorization header ve token asla normal access log'a yazılmamalıdır. Request ve response body logging mümkün olduğunca sınırlandırılmalıdır. Data minimization ve audit trail arasında dengeli politika kurulmalıdır.

API Loglarında Kişisel Veri

User ID veya email log içinde bulunabilir. Gerçek ihtiyaç yoksa maskelenmelidir. Access role ile sınırlandırılır. Retention otomatik uygulanır. Security analysis için minimum gerekli data tutulur.

IP Adresi

IP güvenlik analizi için yararlı olabilir. Aynı zamanda kişisel veri değerlendirmesine girebilir. Hash veya truncation bazı kullanımda düşünülebilir. Retention gerekçesi açık olmalıdır. Abuse investigation ihtiyacıyla dengelenmelidir.

Authorization Header Redaction

Bearer token loglanırsa credential leak oluşur. Gateway header redaction yapmalıdır. Debug mode bile token'ı tam göstermemelidir. Secret scanner log pipeline'ı kontrol edebilir. Historical leak bulunursa token revoke edilir.

Token'ların Loglanmaması

JWT payload PII taşıyabilir. Tam token hiçbir standart logda bulunmamalıdır. Token fingerprint gerektiğinde hash kullanılabilir. Error handling library raw request dump etmemelidir. Tracing baggage içinde token taşınmamalıdır.

Request/Response Body Logging

Body payment veya personal data içerebilir. Default off tutulması daha güvenlidir. Sampling ve field redaction uygulanabilir. Incident debug için temporary controlled logging kullanılabilir. Retention çok kısa tutulmalıdır.

Data Minimization

Güvenlik analizi için gerçekten gerekli field'lar seçilmelidir. "İleride lazım olur" gerekçesiyle tüm payload saklanmamalıdır. Schema-level redaction standardı kullanılabilir. SIEM aynı minimum data'yı alır. Policy periyodik review edilir.

Log Retention

Security log uzun süre faydalı olabilir ancak risk ve maliyet yaratır. Farklı log türü farklı retention alabilir. Legal ve compliance gereksinimi dikkate alınır. Expiration otomatik olmalıdır. Immutable audit log ayrı tutulabilir.

Audit Trail

Privilege change ve sensitive operation ayrı audit event üretmelidir. Kim, ne zaman, hangi resource üzerinde işlem yaptı kaydedilir. Audit tam request body olmadan da faydalı olabilir. Integrity korunmalıdır. Access restricted olmalıdır.

Ödeme API'lerinde Ek Güvenlik

Ödeme API'leri finansal etki nedeniyle daha yüksek güvenlik standardı gerektirir. PCI DSS kapsamı kullanılan mimariye göre değerlendirilmelidir. Strong authentication ve mTLS partner entegrasyonunda kullanılabilir. Idempotency duplicate charge riskini azaltır. Payment rate limit fraud detection ve audit logging ile birlikte çalışmalıdır.

PCI DSS

Cardholder data işleniyorsa ilgili güvenlik gereksinimleri değerlendirilmelidir. Scope mümkün olduğunca küçültülmelidir. Tokenization faydalı olabilir. Loglarda card data bulunmamalıdır. Compliance teknik güvenliğin yerine geçmez.

Strong Authentication

User ve partner identity güçlü biçimde doğrulanmalıdır. Riskli işlem step-up authentication isteyebilir. Service credential kısa ömürlü olabilir. Admin payment operation daha sıkı policy alır. Failed auth behavior izlenir.

mTLS

B2B payment partner için client certificate güçlü identity sağlar. Certificate rotation otomatik olmalıdır. Revocation behavior test edilir. IP allowlist ek kontrol olabilir. Application-level permission yine gerekir.

Idempotency

Payment create request unique idempotency key taşır. Network retry aynı charge'ı tekrar oluşturmaz. Key response sonucu ile ilişkilendirilir. Retention business retry penceresini kapsar. Collision güvenli biçimde ele alınmalıdır.

Payment Rate Limits

User, account ve payment instrument bazlı limit uygulanabilir. Failed payment attempt ayrıca sayılabilir. Fraud attack hızını sınırlar. Legitimate bulk payment ayrı contract isteyebilir. Concurrency de kontrol edilmelidir.

Fraud Detection

Rate tek fraud sinyali değildir. Device, amount ve behavior birlikte değerlendirilir. Risk score payment'ı hold veya deny edebilir. Manual review pathway bulunabilir. Feedback modelin doğruluğunu artırır.

Audit Logging

Payment state değişiklikleri immutable audit trail üretmelidir. Sensitive card data maskelenir. Correlation ID transaction zincirini takip eder. Operator action ayrıca kaydedilir. Retention compliance ihtiyacına göre belirlenir.

AI ve LLM API'lerinde Rate Limiting

AI ve LLM API'lerinde request sayısı tek başına gerçek maliyeti göstermez. Bir request yüz token, diğeri yüz bin token kullanabilir. Input ve output token ayrı quota olabilir. Model bazlı cost units GPU ve fiyat farkını yansıtabilir. Tenant token budget denial-of-wallet saldırılarına karşı güçlü koruma sağlar.

Request Bazlı Limit Neden Yetersizdir?

İki request aynı sürede çok farklı compute tüketebilir. Long context model inference maliyetini yükseltir. Flat RPS heavy user'ı doğru sınırlandırmaz. Token ve concurrency metric gerekir. Endpoint model selection cost'u etkiler.

Input Token Limit

Prompt size maksimum token ile sınırlandırılabilir. Oversized request erken reddedilir. Parsing ve model context maliyeti korunur. Plan bazlı farklı limit olabilir. Tool context ayrıca dahil edilmelidir.

Output Token Limit

Generation maximum output budget ile sınırlandırılır. Runaway response cost engellenir. Client request ettiği limit üst sınıra clamp edilebilir. Streaming output quota tüketmeye devam eder. Cancellation kalan cost'u azaltır.

Model Bazlı Cost Units

Farklı model aynı token için farklı compute maliyeti taşıyabilir. Policy model multiplier kullanabilir. Premium model daha fazla unit tüketir. Customer plan buna göre quota alır. Cost table versionlanmalıdır.

GPU Concurrency

GPU aynı anda sınırlı inference çalıştırabilir. Request queue kontrol edilmezse latency hızla artar. Concurrency limiter model pool'u korur. Priority scheduling kullanılabilir. Tenant isolation fairness sağlar.

Tenant Token Budget

Tenant günlük veya aylık token bütçesi alabilir. Input ve output birlikte sayılır. Usage dashboard müşteri görünürlüğü sağlar. Hard ve soft limit ayrılabilir. Enterprise override capacity review gerektirir.

Denial-of-Wallet Koruması

Compromised key pahalı model çağrılarını sürekli yapabilir. Spending cap ve token budget maliyeti sınırlar. Anomaly detection unusual usage'ı tespit eder. Emergency revoke hızlı olmalıdır. Provider-level billing alert ayrıca kurulmalıdır.

Agent ve Tool API'lerinde Rate Limiting

Agent sistemlerinde tek kullanıcı isteği çok sayıda tool call üretebilir. Dışarıdan bir request görünürken içeride onlarca API çağrısı gerçekleşebilir. Tool-level quota gerçek resource tüketimini kontrol eder. Recursive loop ve pahalı tool abuse'u cost budget ile sınırlandırılmalıdır. Yüksek riskli operation insan onayı isteyebilir.

Tek Kullanıcı İsteğinin Çok Sayıda Tool Call Üretmesi

Agent planlama döngüsü aynı tool'u tekrar çağırabilir. External request RPS düşük görünür. Internal call count hızla büyür. Parent request budget tanımlanmalıdır. Trace tüm tool chain'i göstermelidir.

Tool-Level Quota

Her tool kendi rate ve cost limitine sahip olabilir. Search ve payment tool aynı policy'yi kullanmaz. Tenant quota tool usage'ı birleştirebilir. Tool identity enforcement point'te doğrulanır. Unknown tool call reddedilir.

Expensive Tool Limits

Database export veya external paid API yüksek cost taşır. Agent bu tool'u sınırlı sayıda kullanmalıdır. Weighted cost uygulanabilir. Approval veya cache eklenebilir. Retry aynı cost'u tekrar tüketebilir.

Recursive Agent Loop

Agent aynı sonucu alamadığında sonsuz tool döngüsüne girebilir. Maximum step count belirlenmelidir. Global time ve cost budget uygulanır. Loop detection pattern'i izlenebilir. Termination açık reason üretmelidir.

Cost Budget

Parent task toplam token ve tool unit budget alır. Her alt çağrı bu bütçeden düşer. Budget bitince agent durur. User planı üst sınırı belirleyebilir. Monitoring unusual budget consumption'ı gösterir.

Human Approval

Para transferi veya destructive operation agent tarafından otomatik çalıştırılmamalı olabilir. Human approval güvenlik kapısı sağlar. Approval token tek use olabilir. Time window sınırlı tutulur. Audit kim onay verdiğini kaydeder.

Açık Kaynak API Güvenliği ve İşbirliği Ekosistemi

Açık kaynak API gateway ve policy ekosistemi farklı mimari yaklaşımları incelemek için güçlü öğrenme alanı sunar. Kong, Apache APISIX, Envoy, Tyk, KrakenD ve NGINX farklı gateway veya proxy modelleri gösterir. Redis distributed counter için, Keycloak identity için, Open Policy Agent ise policy as code için değerlendirilebilir. Tool seçimi feature listesi kadar operasyon kapasitesine göre yapılmalıdır. Community katkıları güvenlik ve performans bilgisini uygulamalı biçimde geliştirebilir.

Kong

Kong gateway plugin yaklaşımıyla authentication ve rate limiting senaryoları sunabilir. Distributed deployment topology test edilmelidir. Plugin policy standardizasyonu sağlar. Configuration as code kullanılabilir. Gerçek ihtiyaca göre performans ve operasyon değerlendirilmelidir.

Apache APISIX

Apache APISIX dinamik gateway configuration yaklaşımı sunan açık kaynak projelerden biridir. Auth ve traffic plugin'leri değerlendirilebilir. Control plane ve data plane health önemlidir. Policy change rollout test edilmelidir. Community documentation öğrenme için kullanılabilir.

Envoy

Envoy proxy service mesh ve gateway mimarilerinde kullanılabilir. External rate limit service ile entegre olabilir. High-performance data plane yaklaşımı sunar. Configuration ve xDS control plane tasarımı önemlidir. Failure mode production'da test edilmelidir.

Tyk

Tyk API management ve gateway ihtiyaçlarında değerlendirilebilen platformlardan biridir. Authentication, quota ve developer access senaryoları bulunabilir. Deployment modelinin ekip operasyonuna uyumu incelenmelidir. Policy as code yaklaşımı tercih edilmelidir. Product-specific behavior benchmark ile doğrulanmalıdır.

KrakenD

KrakenD API gateway ve aggregation senaryolarında kullanılabilir. Backend fan-out ve response composition yapabilir. Rate limiting ve auth ihtiyacı architecture ile birlikte değerlendirilir. Stateless gateway scaling avantaj sağlayabilir. Business authorization backend'de kalmalıdır.

NGINX

NGINX reverse proxy ve traffic control için yaygın altyapı bileşenidir. Connection ve request rate limit uygulanabilir. Edge veya ingress katmanında kullanılabilir. User-level distributed quota için ek context gerekebilir. Configuration version control altında tutulmalıdır.

Redis

Redis distributed counter ve token bucket state için kullanılabilir. Low latency avantaj sağlar. HA ve fail behavior tasarlanmalıdır. Memory cardinality izlenmelidir. Counter store application cache ile aynı cluster olmak zorunda değildir.

Keycloak

Keycloak identity ve OAuth/OIDC laboratuvarları için kullanılabilir. Realm ve client configuration güvenlik modelini etkiler. Token lifetime ve key rotation test edilebilir. Production operation ayrı kapasite gerektirir. API authorization design identity provider'a tamamen bırakılmamalıdır.

Open Policy Agent

OPA policy as code öğrenmek için güçlü açık kaynak örnektir. Gateway veya service ile entegre edilebilir. Authorization input schema standardize edilmelidir. Policy tests repository'de tutulur. Decision latency ve caching ölçülmelidir.

Açık Kaynak Policy ve Gateway Ekosistemi

Açık kaynak projeler farklı design trade-off'larını görünür kılar. Plugin, external auth ve control plane modelleri karşılaştırılabilir. Lab ortamında failure test yapılabilir. Tek tool bütün kurumsal ihtiyacı çözmeyebilir. Architecture hedefi üründen önce belirlenmelidir.

Community Security Contributions

Issue ve pull request çalışmaları gerçek edge case'leri gösterir. Security fix release note'ları takip edilebilir. Documentation katkısı iyi başlangıçtır. Reproduction ve benchmark paylaşmak topluluk değerini artırır. Öğrenilenler internal platform standardına taşınabilir.

API Gateway Seçerken Hangi Güvenlik Özellikleri Aranmalı?

API gateway seçimi yalnız throughput benchmark'ına göre yapılmamalıdır. OAuth/OIDC, JWT validation ve mTLS temel identity yetenekleridir. Per-consumer ve distributed rate limiting kurumsal traffic control için önemlidir. Schema validation ve policy as code operasyon kalitesini artırır. Multi-region support ve observability gerçek production gereksinimlerini belirler.

OAuth/OIDC

Gateway trusted identity provider ile kolay entegre olmalıdır. Issuer ve audience validation desteklenmelidir. Multiple tenant veya issuer ihtiyacı düşünülmelidir. Token introspection gerekiyorsa performance test edilir. Auth failure metric standart olmalıdır.

JWT Validation

Signature ve claim validation native desteklenebilir. JWKS cache behavior güvenli olmalıdır. Algorithm allowlist bulunmalıdır. Key rotation outage oluşturmamalıdır. Custom claim policy sınırlı ve kontrollü kullanılmalıdır.

mTLS

Client certificate doğrulama partner API için gereklidir. CA rotation desteklenmelidir. Certificate identity backend context'e aktarılabilir. Revocation veya short-lived certificate modeline uyum önemlidir. TLS configuration güvenli default taşımalıdır.

Per-Consumer Rate Limiting

User, API key veya client ID anahtar olarak kullanılabilmelidir. Endpoint override desteklenmelidir. Quota ve burst ayrı ayarlanabilmelidir. 429 header standardizasyonu önemlidir. Consumer metadata merkezi yönetilmelidir.

Distributed Rate Limiting

Birden fazla gateway node ortak limit uygulamalıdır. Shared store veya native distributed model kullanılabilir. Race ve overshoot davranışı bilinmelidir. Multi-region semantics ayrıca değerlendirilir. Store failure policy ayarlanabilir olmalıdır.

Schema Validation

OpenAPI veya JSON Schema request validation faydalıdır. Payload size ve unknown field policy uygulanabilmelidir. Performance overhead ölçülür. Versioned schema rollout desteklenir. Validation error body standard olmalıdır.

Policy as Code

Gateway configuration Git üzerinden yönetilebilmelidir. Declarative config veya API automation sunmalıdır. Diff ve rollback kolay olmalıdır. Manual dashboard drift tespit edilmelidir. CI validation yapılabilmelidir.

Observability

Request, auth ve limiter metric dışarı aktarılabilmelidir. Trace context desteklenmelidir. Structured log redaction bulunmalıdır. Per-consumer usage görülebilmelidir. SIEM entegrasyonu operasyonu kolaylaştırır.

Multi-Region Support

Gateway region-local low latency sağlamalıdır. Policy ve route config tutarlı dağıtılmalıdır. Distributed rate limit semantics açık olmalıdır. Region failure sırasında traffic reroute edilmelidir. Control plane dependency'nin failure etkisi bilinmelidir.

Kurumsal API Güvenliği Olgunluk Modeli

API güvenliği çoğu kurumda bir anda ileri seviyeye çıkmaz. İlk aşamada API'ler dağınık ve policy'siz olabilir. Authentication standardı kurulduktan sonra gateway ve temel rate limits gelir. Daha ileri seviyede merkezi authorization, observability ve adaptive risk kontrolü uygulanır. Olgunluk modelinin amacı teknoloji sayısını değil kontrol kalitesini artırmaktır.

Seviye 0 - API'ler Dağınık ve Kuralsız

API envanteri eksiktir. Her ekip farklı auth yaklaşımı kullanır. Rate limit bulunmayabilir. Log formatları tutarsızdır. İlk hedef görünürlük ve ownership oluşturmaktır.

Seviye 1 - Authentication Standardı

OAuth, OIDC veya service identity için ortak standart belirlenir. Token validation merkezi hale gelir. Secret rotation policy uygulanır. API inventory identity yöntemini kaydeder. Authorization hâlâ ekipler arasında farklı olabilir.

Seviye 2 - Gateway ve Temel Rate Limits

Public traffic ortak gateway üzerinden geçer. Per-consumer ve endpoint limit uygulanır. 429 standardize edilir. Basic schema validation eklenir. Gateway HA ve observability kurulmalıdır.

Seviye 3 - Merkezi Authorization ve Policy as Code

RBAC veya ABAC politikaları ortak engine'e taşınır. Policy repository içinde versionlanır. Negative tests CI'de çalışır. BOLA kontrol standardı oluşur. Exception süreci yönetilir.

Seviye 4 - Runtime Observability ve Abuse Detection

Security dashboard consumer behavior'u gösterir. Bot ve anomaly signal eklenir. Rate limit hit ve authorization deny korele edilir. Incident runbook devrededir. Shadow API discovery yapılır.

Seviye 5 - Adaptive ve Risk-Based API Security

Risk score policy threshold'unu dinamik etkiler. System saturation adaptive load shedding tetikler. Behavioral analytics business abuse'u tanımlar. Automation controlled response üretir. Human review high-impact decision'larda korunur.

Kurumsal Rate Limiting Policy Örneği

Kurumsal policy her API türü için aynı limiter değerini kullanmamalıdır. Anonymous public API IP ve endpoint bazlı sınır alabilir. Authenticated customer API user ve tenant limitini birlikte kullanabilir. Partner API contractual quota ile OAuth client identity'yi birleştirebilir. Login, payment ve heavy export daha özel security ve resource control ister.

Anonymous Public API

Client identity doğrulanmadığı için IP temel sinyaldir. Edge ve gateway limit birlikte kullanılabilir. Scraping için bot detection gerekir. Endpoint cost farklı olabilir. Global emergency cap bulunmalıdır.

IP + Endpoint Limit

Her IP belirli endpoint için ayrı quota tüketir. Cheap ve expensive route ayrılır. NAT false positive nedeniyle limit çok düşük seçilmemelidir. Edge daha geniş network limit uygular. Attack mode threshold'u geçici düşürebilir.

Authenticated Customer API

User identity token üzerinden doğrulanır. Tenant shared quota ayrıca uygulanır. Token değişimi limit'i sıfırlamaz. Subscription tier threshold'u etkiler. Sensitive endpoint ek anti-abuse policy alır.

User + Tenant Limit

Request hem user hem tenant counter tüketir. User tek başına tenant kapasitesini kullanamaz. Tenant bütün user'ların toplamını sınırlar. Enterprise tenant özel override alabilir. Global platform cap yine korunur.

Partner API

Partner client OAuth client credentials veya API key ile tanımlanır. Contractual throughput açıkça belirlenir. Credential compromise riski monitoring ile izlenir. mTLS eklenebilir. Partner-specific dashboard yararlı olabilir.

OAuth Client + Contractual Quota

Client ID limit anahtarı olur. Saniyelik token bucket ve aylık quota birlikte uygulanabilir. Contract update policy store'a versionlu gider. Emergency security cap override edebilir. Retry-After client integration docs içinde açıklanır.

Login

Login normal authenticated API değildir. Kimlik henüz doğrulanmamıştır. Account ve IP saldırı boyutu birlikte düşünülür. Failed attempt ayrı signal olarak tutulabilir. Bot ve risk-based authentication eklenebilir.

User + IP Anti-Brute-Force Limit

User identifier tüm IP'lerden gelen denemeyi sınırlar. IP counter birçok user hedefleyen spraying'i yakalar. Sliding window hassas enforcement sağlar. Progressive cooldown kullanılabilir. Response account existence sızdırmamalıdır.

Payment

Payment finansal ve abuse-sensitive operation'dır. User, account ve business rule birlikte değerlendirilir. Idempotency zorunludur. Fraud score dynamic control sağlayabilir. Concurrency ve amount-based rule eklenebilir.

User + Account + Business Rule Limit

Same user çok sayıda account kullanamamalıdır. Account birçok user tarafından hedefleniyorsa resource limit çalışır. Business rule amount veya velocity kontrolü ekler. Fraud engine additional signal sağlar. Rate limiter finansal correctness yerine geçmez.

Heavy Export

Export request sayısı düşük ama maliyeti yüksektir. Async job tercih edilir. Tenant concurrent job sayısı sınırlandırılır. Weighted cost quota tüketir. Storage ve egress maliyeti izlenir.

Concurrency + Weighted Cost Limit

Tenant aynı anda sınırlı export çalıştırabilir. Her export data size'a göre cost unit tüketir. Queue fairness sağlar. Cancel edilen job slot serbest bırakır. Plan quota ile resource capacity birlikte korunur.

Kurumsal API Güvenliği İçin Adım Adım Yol Haritası

Kurumsal API güvenliği nasıl sağlanır sorusuna en iyi cevap, kontrolü aşamalı biçimde kurmaktır. Önce tüm API'ler envanterlenmeli ve risk seviyesine göre sınıflandırılmalıdır. Authentication ile authorization standardı birbirinden ayrı tanımlanmalıdır. Ardından gateway, rate limit, policy as code ve observability katmanları devreye alınmalıdır. Son aşamada abuse ve failure testleriyle sistem düzenli olarak doğrulanmalıdır.

1. Tüm API'leri Envanterleyin

Public, partner ve internal endpoint'ler bulunmalıdır. Owner ve version bilgisi kaydedilir. Authentication yöntemi görünür olur. Shadow ve zombie API işaretlenir. Inventory sürekli güncel tutulmalıdır.

2. API'leri Risk Seviyesine Göre Sınıflandırın

Payment ve login high-risk olabilir. Public catalog daha düşük risk taşıyabilir. Data sensitivity ve business impact değerlendirilir. Risk class default policy belirler. Compliance gereksinimi eklenir.

3. Authentication Standardı Belirleyin

User-facing API için OAuth/OIDC standardı seçilebilir. Service traffic workload identity kullanabilir. Partner için API key veya mTLS modeli belirlenir. Token validation merkezi hale gelir. Legacy auth migration planı oluşturulur.

4. Authorization Modelini Oluşturun

RBAC, ABAC veya ReBAC ihtiyaca göre seçilir. Object-level permission zorunlu hale getirilir. Policy as code değerlendirilebilir. Negative test standardı kurulur. BOLA riskleri sistematik taranır.

5. API Gateway Standardı Belirleyin

Public ingress ortak gateway üzerinden geçer. TLS, auth ve logging standardize edilir. Rate limit plugin veya service seçilir. HA topology hazırlanır. Direct backend ingress kapatılır.

6. Sensitive Business Flow'ları Tespit Edin

Login, reset, OTP ve payment listelenir. Ticket veya coupon abuse flow'ları eklenir. Normal API quota'dan farklı anti-abuse control tasarlanır. Risk score kaynakları belirlenir. Owner ve incident rule yazılır.

7. Rate Limit Dimension'larını Belirleyin

IP, user, tenant ve endpoint ihtiyacı çıkarılır. Composite dimension gerekli flow'lar belirlenir. Resource-level key tanımlanabilir. PII handling düşünülür. Key cardinality capacity planına eklenir.

8. Algoritmayı Seçin

Fixed window basit route için yeterli olabilir. Sliding window sensitive abuse controlünde kullanılır. Token bucket burst toleransı sağlar. Long-running operation concurrency ister. Karar matrisi dokümante edilir.

9. Weighted ve Concurrency Limitleri Ekleyin

Heavy operation flat RPS'den ayrılır. Cost unit gerçek kaynak kullanımına göre tanımlanır. Export ve AI workload concurrency alır. Tenant quota ile birleştirilir. Monitoring cost distribution gösterir.

10. Distributed Counter Altyapısını Kurun

Gateway node'ları ortak state kullanır. Redis veya benzeri store HA kurulmalıdır. Atomic script test edilir. Fail policy belirlenir. Multi-region semantics açıkça seçilir.

11. 429 ve Retry Politikası Tanımlayın

Standard error body hazırlanır. Retry-After kullanımı belirlenir. Client SDK backoff ve jitter uygular. Maximum retry ve budget tanımlanır. Docs consumer expectation'ını açıklar.

12. Policy as Code'a Geçin

Gateway ve limiter config repository'ye taşınır. PR review devreye girer. Automated test yazılır. Environment promotion standardize edilir. Manual drift detection yapılır.

13. Shadow Mode ile Test Edin

Yeni policy önce bloklama yapmadan çalışır. False positive ölçülür. Enterprise ve special client behavior görülür. Threshold gerçek traffic'e göre düzeltilir. Enforcement canary ile başlar.

14. Observability ve Alerting Kurun

Allowed, denied ve 429 metric toplanır. Auth failure ve authorization deny eklenir. Shared store latency izlenir. Consumer anomaly alert oluşturulur. Dashboard security ve reliability ekiplerince paylaşılır.

15. Abuse ve Failure Testleri Yapın

Credential stuffing ve scraping simulation yapılabilir. Redis outage chaos test edilir. Fail-open ve fail-closed doğrulanır. GraphQL batch bypass denenir. Retry storm senaryosu ölçülür.

16. Periyodik Security Review Uygulayın

API inventory düzenli gözden geçirilir. Deprecated route decommission edilir. Quota exception yeniden değerlendirilir. Policy ve dependency upgrade yapılır. Incident öğrenimleri standarda eklenir.

En Sık Yapılan API Güvenliği ve Rate Limiting Hataları

API güvenliğinde en pahalı hatalar genellikle basit varsayımlardan çıkar. Yalnız IP limit kullanmak distributed abuse'u kaçırır. Authentication'ı authorization sanmak BOLA açığı oluşturur. Gateway'i tek güvenlik katmanı kabul etmek internal bypass riskini büyütür. Ölçmeden belirlenen quota ise normal kullanıcıları engelleyebilir veya backend'i yeterince korumayabilir.

Yalnızca IP Bazlı Rate Limit Kullanmak

NAT legitimate user'ları aynı IP'ye toplar. Botnet saldırgana binlerce IP verir. Authenticated API'de user veya tenant daha iyi anahtardır. IP ek risk signal olarak kalabilir. Composite policy daha dayanıklıdır.

Bütün Endpoint'lere Aynı Limiti Vermek

Health read ile export aynı maliyetli değildir. Uniform policy cheap endpoint'i gereksiz sınırlar. Heavy endpoint backend'i yine doygunlaştırabilir. Cost ve risk sınıflandırması yapılmalıdır. Route-specific threshold kullanılmalıdır.

Login ve OTP Endpoint'lerini Normal API Gibi Limitlendirmek

Bu endpoint'ler brute force hedefidir. Failed attempt ve resource identity önemlidir. User + IP sliding limit gerekebilir. Progressive cooldown uygulanabilir. Normal fair-use policy yeterli değildir.

Authentication'ı Authorization Sanmak

Valid token yalnız kimliği kanıtlar. Resource permission ayrıca kontrol edilmelidir. Role veya ownership doğrulanmazsa veri sızıntısı olur. BOLA bunun tipik sonucudur. Negative test zorunludur.

BOLA Kontrolünü Unutmak

Object ID client tarafından değiştirilebilir. UUID güvenlik sağlamaz. Backend owner veya relation kontrolü yapmalıdır. Database query tenant koşulu taşıyabilir. Authorization denial loglanmalıdır.

API Gateway'i Tek Güvenlik Katmanı Sanmak

Internal service direct route kullanabilir. Gateway business object context'ini bilmeyebilir. Backend authorization tekrar yapılmalıdır. Edge ve service mesh ayrı riskleri yönetir. Defense-in-depth uygulanmalıdır.

Rate Limiting'i DDoS Çözümü Sanmak

Application limiter volume attack backend'e ulaşınca çalışır. Network kapasitesi daha önce tükenebilir. Edge DDoS protection gerekir. WAF ve bot management ek katmandır. Layered strategy kullanılmalıdır.

Tek HTTP Request İçindeki GraphQL Maliyetini Görmezden Gelmek

Tek query yüzlerce field içerebilir. Batch operation count request sayısını gizler. Complexity ve depth sınırlandırılmalıdır. Field cost quota tüketebilir. Persisted query riski azaltabilir.

Concurrency Limit Kullanmamak

Long-running report düşük RPS ile sistemi doygunlaştırabilir. Active work count izlenmelidir. Worker veya connection slot sınırı gerekir. Queue bounded olmalıdır. Timeout resource leak'i önler.

Third-Party API Maliyetlerini Limitlendirmemek

Compromised client ücretli provider'ı sürekli çağırabilir. Internal spending cap gerekir. Provider quota monitoring yapılmalıdır. Retry budget cost'u sınırlar. Cache gereksiz call'ları azaltır.

Local Counter ile Distributed Sistem Yönetmek

Her instance kendi quota'sını uygular. Autoscaling gerçek toplam limiti değiştirir. Restart state'i sıfırlar. Shared counter veya coordinated model gerekir. Approximate local mode yalnız bilinçli trade-off olmalıdır.

Rate Limiter Arızası İçin Fail-Open/Closed Politikası Olmaması

Store outage sırasında davranış belirsiz kalır. Bazı node'lar request geçirip diğerleri reddedebilir. Endpoint riskine göre policy tanımlanmalıdır. Local emergency limit kullanılabilir. Chaos test şarttır.

429 Döndürüp Retry-After Vermemek

Client ne zaman deneyeceğini bilemez. Immediate retry storm oluşabilir. Standard header behavior iyileştirir. SDK backoff yine uygulamalıdır. Anti-abuse hidden limit için approximate değer kullanılabilir.

Client Retry Storm'larını Hesaba Katmamak

Backend recovery anında binlerce retry gelebilir. Exponential backoff ve jitter gerekir. Server load shedding yapmalıdır. Retry budget uygulanır. Circuit breaker failure propagation'ı azaltır.

Rate Limit Değerlerini Ölçmeden Belirlemek

Tahmini düşük limit normal müşteri workflow'unu kırabilir. Çok yüksek limit backend'i korumaz. Traffic percentile ve load test kullanılmalıdır. Shadow mode gerçek etkiyi gösterir. Threshold periyodik recalibrate edilmelidir.

Policy Değişikliklerini Production'da Doğrudan Uygulamak

Manual config review olmadan hata riski taşır. Yanlış zero değeri tüm API'yi kapatabilir. Policy as code ve PR review kullanılmalıdır. Shadow ve canary rollout daha güvenlidir. Emergency change audit edilmelidir.

Shadow ve Deprecated API'leri Unutmak

Eski route yeni security baseline dışında kalabilir. Attack en zayıf version'a yönelir. Inventory otomatik tutulmalıdır. Sunset process uygulanır. Direct backend ingress taranmalıdır.

Token ve Secret'ları Access Log'a Yazmak

Log okuyabilen kişi credential ele geçirebilir. Authorization header redaction zorunludur. Request body içinde secret varsa maskelenmelidir. Debug logging kontrollü olmalıdır. Leak sonrası rotation hızlı yapılmalıdır.

Rate Limit Hit'lerini İzlememek

429 yalnız client hatası değildir. Attack veya client bug signal olabilir. Consumer ve endpoint breakdown gerekir. Threshold tuning bu veriye dayanır. Security incident detection için değerlidir.

Sık Sorulan Sorular

Kurumsal API güvenliği ve rate limiting konusunda sorular çoğunlukla kimlik doğrulama, yetkilendirme, algoritma seçimi ve quota belirleme etrafında toplanır. API rate limiting politikası nasıl oluşturulur sorusuna tek bir sayı ile cevap vermek doğru değildir. Consumer identity, endpoint cost ve backend capacity birlikte değerlendirilmelidir. Güvenlik katmanları gateway ile başlayıp backend ve observability sistemlerine kadar devam eder. Aşağıdaki cevaplar temel kararları üretim perspektifiyle özetler.

API güvenliği nedir?

API güvenliği identity, authorization ve data access'i koruyan kontrol bütünüdür. Authentication yalnız ilk adımdır. Schema validation ve rate limiting resource abuse'u sınırlar. Monitoring incident detection sağlar. Defense-in-depth birden fazla katmanı birlikte kullanır.

Kurumsal API'ler nasıl korunmalıdır?

API inventory ilk adımdır. Gateway, OAuth/OIDC ve object-level authorization birlikte kullanılmalıdır. Sensitive flow özel rate limit almalıdır. Internal API'ler mTLS ve service identity ile korunabilir. Security test ve observability sürekli olmalıdır.

API rate limiting nedir?

Rate limiting consumer'ın belirli zaman veya kaynak bütçesinde ne kadar request yapabileceğini sınırlar. IP, user veya tenant anahtar olabilir. Token bucket veya sliding window gibi algoritmalar kullanılabilir. Backend protection ve fair usage sağlar. Abuse kontrolünün yalnız bir parçasıdır.

Rate limiting neden gereklidir?

Client bug veya saldırı backend kapasitesini tüketebilir. Tek tenant diğer müşterileri etkileyebilir. Brute force ve enumeration yavaşlatılır. Third-party veya compute maliyeti kontrol edilir. Sistem daha predictable çalışır.

Rate limit ile quota arasındaki fark nedir?

Rate limit kısa zaman içindeki kullanım hızını sınırlar. Quota daha uzun dönemli toplam kullanım hakkıdır. Saniyede on request rate limit olabilir. Ayda yüz bin request quota olabilir. İki kontrol birlikte uygulanabilir.

Throttling ile rate limiting aynı şey midir?

Tam olarak aynı değildir. Rate limit belirli sınırı tanımlar. Throttling trafiği yavaşlatma veya pacing uygulama davranışıdır. Request doğrudan reddedilmeyebilir. Terminoloji ürünlere göre değişebileceği için policy semantics açık yazılmalıdır.

Token bucket nasıl çalışır?

Bucket belirli hızla token kazanır. Request token tüketir. Token birikimi kısa burst'e izin verir. Refill rate uzun dönemli ortalama hızı belirler. Capacity backend'in tolere edebileceği burst'e göre seçilir.

Sliding window nedir?

Sliding window request anından geriye doğru gerçek zaman aralığını değerlendirir. Sabit dakika sınırı kullanmaz. Boundary burst azalır. Log yaklaşımı daha hassastır. Counter yaklaşımı daha düşük state maliyeti sunabilir.

Hangi rate limiting algoritması daha iyidir?

Tek bir en iyi algoritma yoktur. Token bucket genel API için güçlü dengedir. Sliding window sensitive abuse controlünde daha hassastır. Fixed window basit düşük riskli endpoint'te yeterli olabilir. Long-running operation concurrency limiter ister.

Rate limit IP'ye mi kullanıcıya mı uygulanmalıdır?

Anonymous API için IP faydalıdır. Authenticated API'de user ID daha güvenilir anahtardır. B2B SaaS tenant limit ister. Sensitive flow user + IP composite kullanabilir. Tek dimension genellikle tüm riskleri kapsamaz.

Distributed rate limiting nedir?

Birden fazla gateway veya application instance'ın ortak quota uygulamasıdır. Local counter node sayısıyla gerçek limiti büyütebilir. Shared store kullanılır. Atomic update race condition'ı azaltır. Multi-region tasarım ayrıca trade-off taşır.

Redis neden rate limiter için kullanılır?

Redis düşük latency ve atomic counter operation sunar. TTL fixed window cleanup'ını kolaylaştırır. Sorted set sliding window için kullanılabilir. Lua token bucket state'ini atomic günceller. HA ve fail behavior ayrıca tasarlanmalıdır.

HTTP 429 ne anlama gelir?

Client mevcut rate policy sınırını aşmıştır. Request permission açısından tamamen yasak değildir. Daha sonra yeniden denenebilir. Retry-After yardımcı olur. 403 authorization denial ile karıştırılmamalıdır.

Retry-After nedir?

Client'ın yeni deneme öncesi ne kadar beklemesi gerektiğini belirtir. 429 response'ta kullanışlıdır. Client backoff ve jitter yine uygulamalıdır. Değer saniye veya tarih biçiminde olabilir. Exact anti-abuse threshold açıklanmak zorunda değildir.

GraphQL API nasıl rate limit edilir?

HTTP request count tek başına yeterli değildir. Query depth ve complexity ölçülmelidir. Batch operation sayısı sınırlandırılır. Field cost weighted quota tüketebilir. Persisted query kontrolü kolaylaştırabilir.

gRPC rate limiting nasıl yapılır?

Unary request klasik rate limiter kullanabilir. Streaming çağrıda concurrent stream ve message rate ölçülür. Maximum duration ve payload size sınırlandırılabilir. Client identity metadata'dan alınır. Service method farklı quota kullanabilir.

API Gateway rate limiting için gerekli midir?

Zorunlu değildir fakat merkezi enforcement için güçlü avantaj sağlar. Application içinde limiter uygulanabilir. Gateway per-consumer policy standardizasyonu sağlar. Distributed counter ve 429 response merkezi olur. Business context için backend limit yine gerekebilir.

Rate limiting DDoS saldırısını önler mi?

Application-level rate limit tek başına DDoS çözümü değildir. Büyük volume edge veya network katmanında durdurulmalıdır. WAF ve bot management eklenebilir. Gateway authenticated abuse'u sınırlar. Layered protection gerekir.

OAuth 2.0 ve OIDC arasındaki fark nedir?

OAuth delegated authorization için framework'tür. OIDC bunun üzerine identity authentication katmanı ekler. Access token API erişiminde kullanılır. ID token client login sonucunu temsil eder. İki kavram birbirinin yerine kullanılmamalıdır.

API Key ile OAuth arasındaki fark nedir?

API key basit statik client credential olabilir. OAuth short-lived token ve scope modeli sunar. User delegated access için OAuth daha uygundur. API key server-to-server basit entegrasyonda yeterli olabilir. Her iki yöntem rotation ve monitoring ister.

BOLA nedir?

BOLA kullanıcı geçerli authentication'a sahipken başka object'e yetkisiz erişmesidir. ID değiştirerek exploit edilebilir. Authentication bunu otomatik engellemez. Object ownership veya relation kontrolü gerekir. Negative authorization testleri önemli korumadır.

Kurumsal API rate limit değerleri nasıl belirlenir?

Average, p95, p99 ve peak traffic analiz edilir. Backend saturation load test ile bulunur. Request cost ve business SLA değerlendirilir. Security-sensitive endpoint ayrı threshold kullanır. Shadow mode gerçek kullanıcı etkisini enforcement öncesi gösterir.

Kurumsal API güvenliği nasıl sağlanır ve hangi güvenlik politikaları uygulanmalıdır?

Kurumsal API Güvenliği ve Rate Limiting Politikaları identity, authorization, validation, traffic control ve observability katmanlarının birlikte çalışmasını gerektirir. OAuth veya workload identity ile kimlik doğrulaması yapılırken object-level authorization backend'de ayrıca uygulanmalıdır. Gateway rate limiting, schema validation ve logging için merkezi nokta sağlayabilir. Sensitive business flow'lar user, IP, tenant ve resource bazlı özel anti-abuse kuralları taşımalıdır. Policy as code, negative security testleri ve düzenli incident tatbikatları bu yapıyı sürdürülebilir hale getirir.

API Rate Limiting nedir ve kullanıcı IP veya endpoint bazlı limitler nasıl belirlenmelidir?

Rate limiting API consumer'ın belirli zaman veya kaynak bütçesinde ne kadar kullanım yapabileceğini sınırlar. Anonymous trafik için IP kullanılabilir ancak authenticated API'de user veya tenant identity daha güçlü anahtar sağlar. Endpoint maliyeti farklı olduğu için tüm route'lara aynı eşik verilmemelidir. Limit değerleri gerçek traffic percentile'ları ve backend load test sonuçları üzerinden belirlenmelidir. Sensitive endpoint'lerde fair-use quota'dan bağımsız daha sıkı anti-abuse sınırı uygulanabilir.

Token Bucket Sliding Window ve Fixed Window gibi Rate Limiting yöntemleri arasındaki farklar nelerdir?

Fixed Window basit counter kullanır ancak pencere sınırında burst oluşturabilir. Sliding Window son gerçek zaman aralığını dikkate aldığı için daha hassas enforcement sağlar. Token Bucket zamanla token biriktirerek kontrollü burst'e izin verir ve uzun dönemli hızı refill rate ile sınırlar. Login ve OTP gibi abuse-sensitive endpoint'lerde Sliding Window daha uygun olabilir. Public veya partner API'lerinde Token Bucket çoğu zaman performans ile kullanım esnekliği arasında iyi denge sağlar.

API Gateway üzerinde authentication authorization throttling ve DDoS koruması nasıl yapılandırılmalıdır?

Gateway authentication ve coarse-grained authorization için merkezi policy uygulayabilir. Per-consumer throttling ve distributed rate limiting burada yürütülebilir. DDoS protection ise yalnız gateway'e bırakılmamalı, edge ve network katmanıyla desteklenmelidir. Object-level authorization ve business context isteyen kontroller backend servislerinde devam etmelidir. Gateway, WAF, service mesh ve backend policy'leri defense-in-depth yaklaşımıyla birbirini tamamlamalıdır.

Kurumsal API güvenliği ve Rate Limiting politikaları konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

API güvenliği ve backend danışmanlığı yakınımda şeklindeki aramalarda yalnız gateway kurulumu değil, authorization, abuse testleri, rate limit kalibrasyonu ve observability pratiği sunan teknik çalışmalar tercih edilebilir. Diyarbakır Yazılım Topluluğu'nun proje çalışmalarına https://www.diyarbakiryazilim.com.tr/projects üzerinden ulaşabilirsiniz. Topluluk hakkında ayrıntılı bilgi için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz. Kurumsal API güvenliği ve rate limiting entegrasyon hizmeti değerlendirilirken AuthN, AuthZ, distributed counters, fail-open/fail-closed ve incident response konularının birlikte ele alınmasına dikkat edilmelidir. Uygulamalı laboratuvar ve gerçek traffic simülasyonu teorik eğitimden çok daha hızlı operasyon deneyimi kazandırır.

Sonuç: Kurumsal API Güvenliği ve Rate Limiting Politikalarını Üretim Standardına Taşımak

Kurumsal API Güvenliği ve Rate Limiting Politikaları yalnız bir gateway plugin'i veya birkaç sabit RPS değerinden oluşmaz. Güvenli mimari identity, object-level authorization, schema control, layered rate limiting ve gözlemlenebilirliği aynı sistemde birleştirir. En iyi policy gerçek trafik, backend kapasitesi ve business risk üzerinden ölçülerek oluşturulur. Shadow mode, load test ve chaos test ile doğrulanmayan limitler production'da beklenmeyen müşteri etkisi yaratabilir. API güvenliği, backend mimarisi ve topluluk projeleri hakkında daha fazla çalışma için https://www.diyarbakiryazilim.com.tr adresini takip edebilirsiniz.