API Güvenliği İçin Hosting Mimarisi: JWT, CORS, Rate Limiting ve WAF

API Güvenliği İçin Doğru Hosting Mimarisi Neden Kritik?

API geliştirmeye odaklanan ekiplerin çoğu, ilk sprintlerde iş kurallarına ve veritabanı modeline yoğunlaşır; güvenlik ve hosting mimarisi genellikle “sonradan toparlarız” klasörüne atılır. Sahada gördüğümüz tablo ise tam tersini söylüyor: API güvenliğini tasarlarken hosting mimariniz, en az kodunuz kadar belirleyici. JWT ile kimlik doğrulama yapsanız da, CORS kurallarını düzgün yazsanız da, zayıf bir ağ segmentasyonu, eksik rate limiting veya iyi ayarlanmamış bir WAF, bütün emeklerinizi boşa çıkarabiliyor.

Özellikle SaaS, mobil backend ve üçüncü taraf entegrasyonlar sunan projelerde API’leriniz, şirket altyapınızın dışa açılan ana kapısı haline geliyor. Bu kapıyı sadece uygulama kodunda değil; hosting mimarisi, ağ katmanı, ters proxy, WAF, rate limiting ve loglama seviyelerinde birlikte tasarlamak gerekiyor. DCHost olarak; onlarca API odaklı projede, tek VPS üzerinde basit kurulumlardan çok bölgeli, WAF ve CDN katmanlı karmaşık yapılara kadar pek çok mimariyi birlikte tasarladık. Bu yazıda, sahada gerçekten işe yarayan, pratik ve adım adım uygulanabilir bir rehber sunacağız: JWT tasarımından CORS mimarisine, Nginx tabanlı rate limiting’den WAF kurallarının ince ayarına kadar.

Amacımız; geliştirme ekibinizin kolay adapte olabileceği, aynı zamanda güvenlik ve performans dengesini koruyan bir API hosting mimarisi kurmanız için net bir yol haritası bırakmak.

Mimari Temel: API Sunucusu, Reverse Proxy, WAF ve Ağ Segmentasyonu

Sağlam bir API güvenliği için önce hosting tarafındaki katmanları netleştirmek gerekir. Basit bir projede bile minimum şu bileşenleri ayırmanızı öneriyoruz:

• İnternet katmanı (kullanıcıların geldiği dış ağ)
• Reverse proxy / API gateway katmanı (Nginx, HAProxy vb.)
• Uygulama katmanı (Node.js, Laravel, .NET API sunucuları)
• Veritabanı ve cache (MySQL/PostgreSQL, Redis vb.)
• Opsiyonel WAF ve CDN katmanı

Bu katmanların aynı VPS’te olup olmaması projenizin ölçeğine bağlı, ancak mantıksal ayrımı mimari tasarım aşamasında netleştirmek önemli. Küçük projelerde dahi, en azından:

• Nginx’i reverse proxy katmanı olarak konumlandırmak,
• Uygulamayı ayrı bir portta (ör. 127.0.0.1:3000) çalıştırmak,
• Veritabanını dış dünyaya değil, sadece yerel ağ veya private network üzerinden açmak

gibi basit adımlar bile saldırı yüzeyini ciddi şekilde daraltır.

Ağ erişimi tarafında ise Zero Trust yaklaşımını hosting ve sunucu erişiminde nasıl uygulayabileceğinizi anlattığımız rehberde detaylandırdığımız prensipleri API mimarisine de taşımanız gerekir: her isteği kanıtlanana kadar şüpheli kabul etmek, sunucular arası trafiği bile mümkün olduğunca yetkilendirmek ve loglamak.

TLS Zorunluluğu ve HTTP Güvenlik Başlıkları

API’ler için her zaman HTTPS zorunlu olmalı; sadece dış kullanıcılar için değil, mobil uygulamalar, üçüncü taraf entegrasyonlar ve hatta dahili paneller için de. TLS 1.2 altı protokolleri kapatmak ve modern şifre paketlerini etkinleştirmek, artık lüks değil asgari gereklilik. Üzerine bir de doğru HTTP başlıklarını eklediğinizde (HSTS, X-Content-Type-Options, Referrer-Policy, X-Frame-Options vb.) saldırı yüzeyiniz daha da daralır.

Bu başlıkların API’ler için nasıl uygulanacağı, hangi ortamda hangi seviyede sıkılaştırma yapmanız gerektiği konusunda detaylı bilgi için HTTP güvenlik başlıkları rehberimizi mutlaka gözden geçirmenizi öneririz.

Kimlik Doğrulama ve Yetkilendirme Katmanı: JWT Tasarımını Doğru Kurmak

API güvenliğinde JWT, çoğu ekibin ilk tercih ettiği mekanizma. Ancak sahada gördüğümüz en yaygın problemler, JWT’nin nasıl imzalandığı, nerede saklandığı ve hangi öznitelikleri taşıdığı ile ilgili. Hosting mimarisini tasarlarken JWT stratejinizi de birlikte ele almalısınız.

JWT Yapısı: Hangi Alanlar, Hangi Süreler?

Tipik bir access token’da en azından şu claim’lerin net tasarlanması gerekir:

• sub: Kullanıcı ID’si (mümkünse dahili, tahmin edilemez bir kimlik)
• iss: Token’ı üreten servis veya domain
• aud: Hedef API veya servis adı (multi-tenant mimarilerde kritik)
• exp: Bitiş zamanı (kısa tutulmalı; 5–30 dakika pratik bir aralık)
• iat: Oluşturulma zamanı
• Roller veya yetki kümeleri (role, scope vb.)

Hosting mimarisi tarafında, bu claim’leri reverse proxy katmanında doğrulamak büyük avantaj sağlar. Örneğin Nginx veya bir API gateway ile:

• Token’ın imzasını ve süresini kontrol edip,
• Bloke edilmiş veya iptal edilmiş kullanıcılar için merkezi bir deny list mekanizması kurup,
• Uygulama katmanına gereksiz isteği hiç iletmeden 401/403 dönebilirsiniz.

Access Token – Refresh Token Ayrımı

Güvenli bir mimari için access ve refresh token’ları net ayırmak gerekir:

• Access token: Kısa ömürlü, API çağrılarında kullanılan, her isteğe gönderilen token.
• Refresh token: Çok daha uzun ömürlü, sadece yeni access token almak için kullanılan, sık çağrılmayan token.

Hosting tarafında önerdiğimiz yaklaşım:

• Access token’ları çoğunlukla Authorization: Bearer başlığında taşımak,
• Refresh token’ı ise HttpOnly, Secure, SameSite özellikli bir cookie içinde saklamak,
• Refresh endpoint’i için ayrı rate limiting ve WAF kuralları tanımlamak (aşağıda detaylandıracağız).

Böylece access token sızsa bile süresi kısa olduğu için zararı sınırlı olur; refresh token ise tarayıcı JavaScript’inden erişilemediği için XSS riskini azaltırsınız.

JWT Anahtar Yönetimi ve Rotasyon

JWT’yi imzalayan gizli anahtar(lar), çoğu zaman en zayıf halka. Sık yaptığımız denetimlerde şunlara çok sık rastlıyoruz:

• Anahtarın kodun içine gömülmesi
• Repository’ye push edilmiş .env dosyaları
• Üretim ve test ortamında aynı imzalama anahtarının kullanılması

DCHost üzerindeki VPS veya dedicated sunucularınızda, JWT imza anahtarlarını ayrı bir secrets mekanizmasında (örneğin sadece root’un okuyabildiği dosyalar, şifreli vault çözümleri veya environment değişkenlerini CI/CD ile enjekte ederek) tutmanızı öneriyoruz. Anahtar rotasyonunu planlarken:

• Anahtarlara key id (kid) atayın,
• Yeni anahtarı üretip doğrulayıcı tarafını önce güncelleyin,
• Bir süre hem eski hem yeni anahtarla imzalanmış token’ları doğrulayın,
• Geçiş süresi sonunda eskisini devre dışı bırakın.

CORS Mimarisi: Frontend, API ve Domain Stratejisi

CORS, birçok ekip için “tarayıcıdan gelen can sıkıcı hata” gibi görünse de, aslında frontend – API – domain mimarisini şekillendiren önemli bir güvenlik katmanı. Özellikle SPA (React, Vue, Angular) + ayrı API backend modelinde, CORS stratejisini en başta doğru kurduğunuzda, hem güvenlik hem de geliştirici deneyimi tarafında rahat edersiniz.

Domain ve Origin Stratejisi

En sorunsuz senaryo, frontend ve API’nin aynı kök alan adında veya en azından tahmin edilebilir bir pattern ile barınmasıdır. Örneğin:

• Frontend: app.ornek.com
• API: api.ornek.com

Bu tür senaryolarda, Nginx veya API gateway üzerinden yalnızca belirli subdomain’leri CORS Access-Control-Allow-Origin başlığına ekleyebilir, wildcard (*) kullanımından kaçınabilirsiniz. Çok domain’li, çok dilli veya white-label SaaS senaryolarında ise, izin verilen origin listesini veritabanından veya yapılandırma dosyasından dinamik üreten bir katman kullanmak daha sağlıklı olur.

Frontend ve API’yi aynı alan adında host etmek, SSL ve yönlendirme tarafında nasıl bir mimari gerektiriyor merak ediyorsanız, SPA + API’yi aynı alan adında barındırmaya yönelik detaylı Nginx ve SSL rehberimizi inceleyebilirsiniz.

CORS İçin Güvenli Varsayılanlar

Hosting tarafında CORS kurallarını Nginx veya bir API gateway üzerinde uygularken şu prensipleri öneriyoruz:

• Allow-Origin: Sadece gerçekten ihtiyaç duyulan origin’leri (production, staging vb.) açıkça listeleyin.
• Allow-Methods: Sadece kullandığınız HTTP metodlarını (GET, POST, PUT, DELETE…) izin verin, OPTIONS otomatik gelecektir.
• Allow-Headers: Content-Type, Authorization gibi gerçekten gerekli başlıklarla sınırlı tutun.
• Allow-Credentials: Sadece cookie veya HTTP auth bilgisi taşımak zorundaysanız true yapın; aksi halde false bırakın.
• Max-Age: Preflight istek sayısını azaltmak için, makul bir süre (örneğin 3600 sn) tanımlayın.

Bu başlıkların hepsini Nginx seviyesinde set etmek; uygulama kodunuzu sadeleştirir ve farklı dil/çerçeve kombinasyonlarında tutarlılık sağlar. Aynı zamanda WAF ve rate limiting kurallarıyla birlikte daha deterministik bir davranış elde edersiniz.

Rate Limiting: API’yi Hem Güvenli Hem Kullanılabilir Tutmak

Rate limiting, yalnızca DDoS veya brute-force saldırılarını engellemek için değil, aynı zamanda SaaS projelerinizde müşteri başına adil kaynak kullanımı sağlamak için de kritik. İyi tasarlanmamış limitler, bir yandan saldırganları engellerken, diğer yandan gerçek kullanıcıları da haksız yere bloklayabilir.

Temel Tasarım Kararları: Neye Göre Limit?

Önce “neyi sınırlayacağınızı” netleştirin. En yaygın pattern’ler:

• IP bazlı limit: Basit ve ilk savunma hattı için ideal, ancak NAT arkasındaki çoklu kullanıcı senaryolarında sorun yaratabilir.
• Kullanıcı ID / API key bazlı limit: SaaS projelerinde en sağlıklı yaklaşım; IP değişse bile kullanıcı başına limit kontrolü sağlanır.
• Endpoint bazlı limit: Özellikle login, password reset, token refresh, kritik rapor gibi ağır veya hassas endpoint’ler için ayrı limitler gerekir.

Örnek bir mimari yaklaşım:

• Genel API trafiği için IP + kullanıcı bazlı global limit (ör. 1000 istek / 5 dakika),
• /auth/login, /auth/refresh, /password/reset gibi endpoint’ler için çok daha sıkı limit (ör. 5–10 istek / dakika),
• Raporlama veya ağır sorgular için (ör. /reports/*) ayrı, daha düşük limitler.

Nginx ve Redis ile Rate Limiting Örneği

DCHost VPS veya dedicated sunucularınızda pratik bir çözüm, Nginx’in limit_req direktiflerini kullanmak. Küçük ve orta ölçekli projelerde Nginx’in in-memory limitleri genellikle yeterli olur; daha gelişmiş senaryolarda Redis tabanlı bir sayaç mekanizmasıyla birleşik kullanabilirsiniz.

Rate limiting konusunu, farklı pencereler (fixed window, sliding window), burst tanımları ve Nginx + Redis örnekleriyle ayrıntılı incelediğimiz API ve mikroservisler için rate limiting stratejileri rehberimize göz atarak daha derin bir mimari tasarlayabilirsiniz.

Rate Limit Yanıtları ve Geliştirici Deneyimi

Rate limiting sadece güvenlik değil, aynı zamanda API tasarımının bir parçası. İyi bir deneyim için:

• Limit aşıldığında her zaman 429 Too Many Requests döndürün,
• Yanıtta Retry-After başlığıyla, ne kadar süre sonra tekrar denenebileceğini belirtin,
• Dokümantasyonda, kullanıcı veya plan başına limitleri açıkça yazın.

Bunların hepsi reverse proxy / API gateway katmanında uygulanabilir. Böylece uygulama kodu, limit ihlallerini hiç görmeden, sadece gerçekten iş mantığıyla ilgili isteklerle ilgilenir.

WAF Kuralları: OWASP CRS’ten İş Kurallarına

Web Application Firewall (WAF), doğru kurgulandığında API’ler için adeta ikinci bir güvenlik ekibi gibi çalışır. Yanlış kurgulandığında ise saatlerce neden 403 aldığınızı anlamaya çalıştığınız bir baş ağrısına dönüşebilir. Buradaki kritik nokta: WAF’i “her şeyi yasaklayan duvar” yerine, “iyi tanımlanmış kurallarla çalışan, gözlemci ve koruyucu bir katman” haline getirmek.

Temel WAF Stratejisi

API’ler için WAF kurarken aşağıdaki yolu öneriyoruz:

1. Önce gözlem modunda çalıştırın (detect/learning mode). Hangi kurallar sık tetikleniyor, hangileri yanlış pozitif üretiyor görün.
2. Yanlış pozitifleri beyaz listeleyin: Özellikle JSON body’lerinde, arama alanlarında veya esnek filtrelerde OWASP CRS sık tetiklenebilir.
3. Login, token refresh, yönetim panelleri gibi kritik endpoint’ler için daha sıkı kurallar uygulayın.
4. Rate limiting ile entegre düşünün: Aynı IP veya kullanıcıdan gelen şüpheli pattern’leri WAF + rate limit birleşimiyle daha agresif engelleyebilirsiniz.

Cloud tabanlı WAF çözümleri veya ModSecurity + OWASP CRS ikilisiyle neler yapılabileceğini, hangi durumlarda hangi yaklaşımın mantıklı olduğunu WAF rehberimizde detaylıca ele almıştık. API’ler için de aynı prensipler geçerli, sadece body ve header yapılarınız daha öngörülebilir olduğu için kuralları daha rahat sıkılaştırabiliyorsunuz.

API Özelinde WAF Kuralları

API trafiği genellikle JSON ve belirli endpoint pattern’lerinden oluştuğu için WAF tarafında şu tür özelleştirmeler yapabilirsiniz:

• Sadece application/json içerik tipine izin verip, diğerlerini engellemek,
• Belirli parametreler için (ör. page, limit, id) regex tabanlı doğrulamalar yapmak,
• GraphQL gibi tek endpoint üzerinden gelen karmaşık sorgular için ayrı kurallar tanımlamak,
• Belirli IP bloklarından gelen yönetim veya dahili API çağrılarını daha serbest bırakmak.

Bunları doğrudan hosting tarafındaki WAF katmanında uyguladığınızda, uygulama kodunuz hem daha sade kalır hem de saldırı tespiti daha merkezi hale gelir.

Loglama, İzleme ve Olay Müdahalesi

JWT, CORS, rate limiting ve WAF kurallarını ne kadar iyi kurarsanız kurun, loglamadan ve izleme olmadan saldırı denemelerini, yavaş yavaş artan anomali trafiğini veya yanlış pozitifleri fark etmeniz zordur. Sağlam bir API hosting mimarisinde şu katmanlarda log toplamanızı öneriyoruz:

• Reverse proxy / API gateway logları (Nginx access/error logları)
• Uygulama logları (yetkilendirme hataları, iş kuralı ihlalleri)
• WAF logları (engellenen istekler, kurala göre gruplanmış)
• Veritabanı logları (yavaş sorgular, bağlantı hataları)

Bu logları tek bir yerde toplayıp, arama ve alarm kuralları tanımladığınızda, olası bir saldırı veya konfigürasyon hatasının etkisini dakikalar içinde görebilirsiniz. DCHost altyapısı üzerinde merkezi loglama için ELK veya Grafana Loki gibi çözümler sıkça tercih ediliyor; bunların pratik kurulum adımlarını VPS log yönetimi rehberimizde detaylandırmıştık.

Logların üzerine oturacak bir izleme ve alarm katmanı ise işin son halkası. CPU, RAM, disk IO, ağ trafiği gibi metriklerin yanı sıra; 401/403/429 oranlarındaki ani artışları da alarm kriteri haline getirdiğinizde, API güvenliği operasyonel olarak da sürdürülebilir olur. Bu mimariyi adım adım nasıl kurgulayabileceğinizi görmek için merkezi sunucu izleme ve alarm mimarisi yazımıza göz atabilirsiniz.

DCHost Üzerinde Örnek API Hosting Mimarileri

Teoriyi somutlaştırmak için, DCHost üzerinde sık gördüğümüz iki tip API mimarisini basitleştirilmiş haliyle özetleyelim.

Senaryo 1: Küçük SaaS veya Mobil Backend için Tek VPS Mimarisi

Başlangıç veya erken aşamadaki projelerde çoğu zaman iyi yapılandırılmış tek bir VPS yeterli oluyor. Bu senaryoda önerdiğimiz yapı:

• Nginx: 80/443 portunda reverse proxy, CORS ve temel rate limiting burada.
• WAF: Nginx ile entegre ModSecurity + OWASP CRS, gözlem modundan yavaş yavaş engelleme moduna geçiş.
• Uygulama: Node.js / PHP (Laravel) API servisi 127.0.0.1 üzerinde farklı portta.
• Veritabanı ve Redis: Aynı VPS üzerinde ama dış IP’ye kapalı, sadece localhost veya private interface üzerinden erişim.
• JWT anahtarları: /etc altında sadece uygulama kullanıcısının okuyabildiği bir dizinde, CI/CD ile dağıtılan secrets.

Bu yapı; başlangıç maliyetlerini düşük tutarken, büyüme aşamasında uygulama ve veritabanını ayrı VPS’lere taşımaya elverişli bir temel sağlar. DCHost olarak müşterilerimizin önemli bir kısmı, bu mimariden başlayıp, yük arttıkça sadece veritabanını veya cache katmanını ayırarak sorunsuz şekilde ölçekleniyor.

Senaryo 2: Orta Ölçekli API için WAF + CDN + Çoklu VPS

API trafiğiniz arttıkça veya güvenlik gereksinimleriniz sıkılaştıkça, mimariyi birkaç katman daha genişletmek mantıklı hale geliyor:

• Ön katmanda CDN + WAF: Statik içerik cache’i, temel DDoS koruması, IP reputasyon filtreleri.
• Arka planda DCHost üzerinde bir veya birden fazla API VPS kümesi: Nginx + uygulama katmanı.
• Veritabanı VPS’i: API sunucularından ayrı, güvenlik duvarıyla sadece belirli IP’lere açık, gerektiğinde replikasyonla ölçeklenebilir.
• Rate limiting: Hem CDN/WAF katmanında, hem de Nginx üzerinde, kritik endpoint’ler için çift katmanlı.
• Loglama: API katmanı, WAF ve veritabanı logları tek bir merkezi log sisteminde toplanıyor.

Böyle bir mimaride, bakım ve güncelleme süreçlerini kolaylaştırmak için staging ortamı kurmak da önem kazanıyor. API kodu ve ayarlarını önce staging’e alıp, JWT, CORS, rate limiting ve WAF kurallarını burada test ettikten sonra canlıya geçirmek, sürpriz kesintileri ciddi şekilde azaltıyor.

Özet ve Yol Haritası: Nereden Başlamalı?

API güvenliği; tek bir teknolojinin, tek bir ayarın çözeceği bir konu değil. JWT, CORS, rate limiting ve WAF, ancak doğru bir hosting mimarisi içinde birlikte tasarlandığında gerçekten işe yarıyor. Kısa bir özetle:

• Önce mimari katmanları netleştirin: reverse proxy, uygulama, veritabanı, WAF, CDN.
• JWT tasarımını güvenli hale getirin: kısa ömürlü access token, HttpOnly refresh token, sağlam anahtar yönetimi.
• CORS’u uygulama değil, mümkünse reverse proxy seviyesinde yönetin; wildcardsız, net origin listeleri oluşturun.
• Rate limiting’i IP + kullanıcı + endpoint kombinasyonu ile düşünün; 429 cevaplarını geliştirici dostu hale getirin.
• WAF’i önce gözlem modunda, sonra kademeli olarak engelleme moduna alın; API’ye özel kurallarla zenginleştirin.
• Loglama ve izleme olmadan hiçbir kuralın gerçek etkisini ölçemezsiniz; merkezi log ve alarm mimarisini mutlaka kurun.

Eğer yeni bir API projesine başlıyorsanız, DCHost üzerindeki VPS veya dedicated sunucu seçenekleriyle; tek VPS’ten başlayıp, zaman içinde WAF, CDN ve çoklu sunucuya doğru aşamalı olarak büyüyebilen bir mimari kurabilirsiniz. Mevcut bir projeniz varsa ve JWT, CORS ya da WAF ayarlarında sürekli sorun yaşıyorsanız, önce küçük bir staging ortamı açıp, bu yazıdaki adımları orada denemenizi; ardından canlıya kademeli geçiş yapmanızı öneriyoruz.

API güvenliği tarafında mimariyi birlikte gözden geçirmek, mevcut DCHost altyapınız üzerinde neler iyileştirilebileceğini konuşmak isterseniz, ekibimiz pratik öneriler ve gerçekçi bir yol haritası ile yanınızda olmaya hazır.