Modern Framework'ler Kimlik Doğrulama ve Yetkilendirmeyi Nasıl Ele Alır

Kimlik Doğrulama vs Yetkilendirme: Frameworklerin Genelde Ayırdığı Şeyler

Kimlik doğrulama “sen kimsin?” sorusunu yanıtlar. Yetkilendirme “ne yapmana izin veriliyor?” sorusunu yanıtlar. Modern frameworkler bunları ilişkili ama ayrı kaygılar olarak ele alır; bu ayrım, bir uygulama büyüdükçe güvenliğin tutarlı kalmasının ana nedenlerinden biridir.

Kimlik Doğrulama: kimliği doğrulama

Kimlik doğrulama, bir kullanıcının (veya servisin) iddia ettiği kişi olduğunu kanıtlamaya yöneliktir. Frameworkler genellikle tek bir yöntemi sert kodlamaz; bunun yerine parola girişi, sosyal giriş, SSO, API anahtarları ve servis kimlik bilgileri gibi yaygın seçenekler için genişletme noktaları sunarlar.

Kimlik doğrulamanın çıktısı bir kimliktir: bir kullanıcı kimliği, hesap durumu ve bazen temel öznitelikler (ör. e-posta doğrulandı mı). Önemli: kimlik doğrulama bir işlemin izinli olup olmadığını belirlememelidir—sadece isteği kimin yaptığını belirler.

Yetkilendirme: erişimi kararlaştırma

Yetkilendirme, belirlenmiş kimliği ve istek bağlamını (rota, kaynak sahibi, tenant, kapsamlar, ortam vb.) kullanarak bir eylemin izinli olup olmayacağını karar verir. Roller, izinler, politikalar ve kaynak bazlı kurallar burada yaşar.

Frameworkler yetkilendirme kurallarını kimlik doğrulamadan ayırır, böylece:

• giriş yöntemlerini izin kurallarını yeniden yazmadan değiştirebilirsiniz
• web sayfaları, API'ler ve arka plan işlerinde tutarlı izin kontrolleri uygulayabilirsiniz
• “sen kimsin” mantığını “ne yapabilirsin” mantığından bağımsız tutabilirsiniz

Uygulama noktaları: framework kuralları nerede uygular

Çoğu framework isteğin yaşam döngüsünde merkezi noktalardan kuralları uygular:

• Middleware/filtreler/interceptorler kontrolör/handler'lardan önce çalışır
• Koruyucular (Guards) rotalara veya eylemlere erişimi engeller
• Politika kontrolleri kaynak-özgü kararlar için iş mantığı içinde çağrılır

Yaygın yapı taşları (framework bağımsız)

İsimler farklı olsa da yapı taşları tanıdıktır: bir kimlik deposu (kullanıcılar ve kimlik bilgileri), istekler arasında kimliği taşıyan bir oturum veya token, ve kimlik doğrulama + yetkilendirmeyi tutarlı şekilde zorlayan middleware/koruyucular.

Bu makaledeki örnekler kavramsaldır, böylece tercih ettiğiniz frameworke haritalayabilirsiniz.

Kimlik Depoları ve Kullanıcı Modelleri

Bir framework birini “oturum açmış” olarak işaretlemeden önce iki şeye ihtiyaç duyar: kimlik verilerini arayacağı bir yer (kimlik deposu) ve kodda o kimliği tutarlı şekilde temsil etme yöntemi (kullanıcı modeli). Modern frameworklerde birçok “kimlik doğrulama özelliği” aslında bu iki parçanın etrafındaki soyutlamalardır.

Tipik kimlik kaynakları

Frameworkler genelde birden fazla arka ucu destekler, ya yerleşik ya da eklentiler aracılığıyla:

• Uygulama veritabanı kullanıcıları: uygulamanız tarafından yönetilen klasik “users” tablosu/collection'ı.
• Harici kimlik sağlayıcıları (IdP): Google, Microsoft, GitHub veya Auth0/Okta gibi özel sağlayıcılar, genellikle OAuth 2.0 / OpenID Connect aracılığıyla.
• Kurumsal dizinler: LDAP/Active Directory, iç araçlar ve B2B uygulamaları için yaygın.

Ana fark gerçek bilginin kaynağıdır. Veritabanı kullanıcılarında uygulamanız kimlik bilgilerine ve profil verilerine sahiptir. Bir IdP veya dizin ile uygulamanız genellikle harici kimlikle ilişkilendirilmiş bir “yerel gölge kullanıcı” saklar.

Temel kullanıcı modeli alanları

Frameworkler varsayılan bir kullanıcı modeli oluştursa bile, çoğu ekip birkaç alanı standartlaştırır:

• id: değişmez bir birincil anahtar (tercihen e-posta olmayan)
• email/username: oturum açma tanımlayıcısı; genelde benzersiz ve normalleştirilmiş
• password_hash: sadece uygulamanız parolaları yönetiyorsa (parolayı asla ham olarak saklamayın)
• durum bayrakları: ör. is_verified, is_active, is_locked, deleted_at

Bu bayraklar önemlidir çünkü kimlik doğrulama sadece “parola doğru mu?” değil—aynı zamanda “bu hesap şu an oturum açmasına izin veriliyor mu?” sorusudur.

Hesap yaşam döngüsü: sadece kayıt değil

Pratik bir kimlik deposu kayıt, e-posta/telefon doğrulama, parola sıfırlama, hassas değişikliklerden sonra oturum geçersiz kılma ve devre dışı bırakma veya soft-delete gibi ortak yaşam döngüsü olaylarını destekler. Frameworkler genellikle tokenler, zaman damgaları, hook'lar gibi yapı taşları sağlar, ancak yine de kuralları siz tanımlarsınız: son kullanma pencereleri, oran sınırlamaları ve bir hesap devre dışı bırakıldığında mevcut oturumlara ne olacağı gibi.

Frameworklerin nerelere takıldığı

Çoğu modern framework user providerlar, adaptörler veya repository'ler gibi genişletme noktaları sunar. Bu bileşenler “bu oturum açma tanımlayıcısı verildiğinde kullanıcıyı getir” ve “bu kullanıcı ID'si verildiğinde mevcut kullanıcıyı yükle” mantığını seçtiğiniz depoya çevirir—ister SQL sorgusu, ister bir IdP çağrısı, ister kurumsal dizin sorgusu olsun.

Oturum Tabanlı Kimlik Doğrulama (Çerezler ve Sunucu Oturumları)

Oturum tabanlı kimlik doğrulama, birçok web framework'ünün hâlâ varsayılan olarak kullandığı “klasik” yaklaşımdır—özellikle sunucu tarafından render edilen uygulamalarda. Fikir basit: sunucu kim olduğunuzu hatırlar, tarayıcı bu hafızaya küçük bir işaretçi tutar.

Nasıl çalışır

Başarılı bir girişten sonra framework sunucu tarafında bir oturum kaydı oluşturur (genelde rasgele bir session ID ile kullanıcı arasında eşleme). Tarayıcı bu session ID'yi içeren bir çerez alır. Her istekte tarayıcı çerezi otomatik olarak geri gönderir ve sunucu kim oturum açmış kullanıcıyı bulmak için bunu kullanır.

Çerez sadece bir tanımlayıcı olduğundan (kendi içinde kullanıcı verisi taşımadığı için), hassas bilgiler sunucuda kalır.

Frameworklerin tipik olarak ayarladığı çerez bayrakları

Modern frameworkler oturum çerezlerini çalınmayı veya kötüye kullanılmayı zorlaştırmak için güvenli varsayılanlar koymaya çalışır:

• HttpOnly: JavaScript'in çerezi okumasını engeller (XSS hasarını azaltır).
• Secure: çerezi sadece HTTPS üzerinden gönderir.
• SameSite (Lax/Strict/None): çerezlerin çapraz sitede gönderimini kontrol eder (CSRF savunmaları ve üçüncü taraf kimlik akışları için önemli).

Bunlar genelde “session cookie settings” veya “security headers” altında yapılandırılır.

Oturumlar nerede saklanır

Frameworkler genellikle oturum deposu seçmenize izin verir:

• Bellek içi: hızlı ve kolay, ama yeniden başlatmada kaybolur ve birden çok sunucu arasında iyi ölçeklenmez.
• Veritabanı destekli: kalıcı ve denetlenebilir, ama sorgu yükü ekler.
• Cache/Redis tarzı store: hızlı ve sunucular arasında paylaşılan; ölçeklenme için iyi, ama ek bir servise bağımlısınız.

Genel olarak trade-off hız vs kalıcılık vs operasyonel karmaşıklıktır.

Çıkış ve geçersiz kılma

Çıkış (logout) iki anlama gelebilir:

• Tek cihaz çıkışı: mevcut oturumu silip çerezi temizlemek.
• Her yerde çıkış: kullanıcının tüm oturumlarını geçersiz kılmak (ör. parola değişikliğinden sonra).

Frameworkler genellikle “her yerde çıkış” için kullanıcıya bir “oturum versiyonu” tutarak, kullanıcı başına birden fazla session ID saklayıp bunları iptal ederek uygular. Anında geçersiz kılma gerekiyorsa, oturum tabanlı kimlik doğrulama genellikle tokenlere göre daha basittir çünkü sunucu bir oturumu hemen unutabilir.

Token Tabanlı Kimlik Doğrulama (JWT ve Opak Tokenler)

Token tabanlı kimlik doğrulama, sunucu tarafı oturum aramasını bir string ile değiştirme fikrine dayanır. Frameworkler genelde tokenleri API ağırlıklı sunucular, mobil uygulamalar, ayrı backend ile konuşan SPA'ler veya servislerin tarayıcı oturumuna ihtiyaç duymadan birbirlerini çağırdığı durumlar için önerir.

“Token” pratikte ne demektir

Token, oturum açmadan sonra (veya bir OAuth akışından sonra) verilen bir erişim yetkisidir. İstemci bunu sonraki isteklere gönderir, böylece sunucu çağıranı kimlik doğrulayıp sonra eylemi yetkilendirebilir. Çoğu framework bunu birinci sınıf desen olarak ele alır: bir “token ver” uç noktası, tokeni doğrulayan kimlik doğrulama middleware'i ve kimlik belirlendikten sonra çalışan koruyucular/politikalar.

Opak tokenler vs JWT'ler

Opak tokenler istemci için anlamı olmayan rastgele dizelerdir (ör. tX9...). Sunucu bunları bir veritabanı veya önbellek girdisiyle doğrular. Bu, iptal etmeyi kolaylaştırır ve token içeriğini gizli tutar.

JWT'ler (JSON Web Token) yapılandırılmış ve imzalıdır. Bir JWT tipik olarak sub, iss, aud, iat, exp gibi claimler ve bazen roller/kapsamlar içerir. Önemli: JWT'ler varsayılan olarak şifrelenmez—tokeni elinde tutan herhangi biri claimleri okuyabilir, imza doğrulama olmadan sahte oluşturamaz.

Depolama: Authorization header vs çerezler

Framework rehberliği genelde iki daha güvenli varsayılda birleşir:

• API'ler için erişim tokenlerini Authorization: Bearer <token> başlığıyla gönderin. Bu, otomatik gönderilen çerezlerin yol açtığı CSRF risklerini azaltır, ama JavaScript'in tokeni okuyup eklemesini gerektirdiği için XSS savunmalarını güçlendirir.
• Çerezleri yalnızca bunları HttpOnly, Secure ve SameSite yapabiliyorsanız kullanın ve CSRF'yi uygun şekilde ele almaya hazır olun (genellikle ayrı CSRF tokenleriyle eşleştirilir).

Yenileme tokenleri, rotasyon ve uç noktalar

Erişim tokenleri kısa ömürlü tutulur. Sürekli yeniden oturum açma zorunluluğunu önlemek için birçok framework yenileme tokenleri destekler: yalnızca yeni erişim tokenleri üretmek için kullanılan uzun ömürlü bir kimlik.

Yapı genellikle şöyledir:

• POST /auth/login → erişim tokeni (ve yenileme tokeni) döner
• POST /auth/refresh → yenileme tokenini döndürür ve yeni erişim tokeni verir
• POST /auth/logout → yenileme tokenlerini sunucu tarafında geçersiz kılar

Her istekte yeni bir yenileme tokeni vermek (rotation), bir yenileme tokeni ele geçirilirse zararı sınırlar; birçok framework token tanımlayıcılarını saklama, yeniden kullanım tespiti ve hızlı iptal için hook'lar sağlar.

OAuth 2.0 ve OpenID Connect Framework Ekosistemlerinde

OAuth 2.0 ve OpenID Connect (OIDC) sıkça birlikte anılır, ama frameworkler bunları farklı olarak ele alır çünkü farklı problemleri çözerler.

OAuth 2.0 vs OIDC: hangisini gerçekten ihtiyacınız var

OAuth 2.0'ı delege edilmiş erişim gerektiğinde kullanın: uygulamanız bir API'yi kullanıcının adına çağırmak istiyorsa.

OpenID Connect'i kimlik/login gerektiğinde kullanın: uygulamanız kullanıcının kim olduğunu bilmek ve ID token ile kimlik claimleri almak istiyorsa. Pratikte “X ile giriş” genelde OIDC'nin OAuth 2.0 üzerine konmuş halidir.

Frameworklerin yaygın olarak desteklediği akışlar

Çoğu modern framework ve kimlik kütüphanesi iki akışa odaklanır:

• Authorization Code akışı + PKCE: tarayıcı uygulamaları ve mobil istemciler için varsayılan. PKCE kod yakalama saldırılarını önlemeye yardımcı olur ve çoğu sağlayıcı tarafından beklenir.
• Client Credentials akışı: son kullanıcı olmayan servisler arası çağrılar için (işler, arka uç çalışanları, dahili mikroservisler).

Geri çağırma (callback) işleme: güvenlik detaylarının önemli olduğu yer

Framework entegrasyonları genellikle bir callback rotası ve yardımcı middleware sağlar, ama yine de temel yapılandırmaları doğru yapmak sizin sorumluluğunuzdur:

• redirect URI'yi tam olarak doğrulayın (scheme/host/path). Joker karakterli redirect URI'larından kaçının.
• state parametresini kullanın ve doğrulayın; CSRF tarzı giriş saldırılarını önler.
• OIDC için bir nonce oluşturun ve doğrulayın; token tekrar oynatma riskini azaltır.
• Geçici değerleri (state/nonce/verifier) güvenli bir oturumda veya şifrelenmiş çerezde saklayın, localStorage'ta değil.

Kapsamlar, claimler ve yerel kullanıcılara eşleme

Frameworkler genellikle sağlayıcı verisini yerel kullanıcı modeline normalleştirir. Tasarım kararı, yetkilendirmeyi gerçekten neyin yöneteceğidir:

• Kapsamlar (scopes) API için izinlerdir (erişim tokeninin ne yapabileceği).
• Claimler OIDC ID tokenindeki kimlik öznitelikleridir (kullanıcının kim olduğu).

Yaygın bir desen: kararlı tanımlayıcıları (sub gibi) yerel bir kullanıcıya eşleyin, sonra sağlayıcı rollerini/gruplarını/claimlerini uygulamanızın kontrol ettiği yerel roller veya politikalara çevirin.

Parolalar, Hashleme, MFA ve Hesap Kurtarma

Parolalar hâlâ birçok uygulamada varsayılan giriş yöntemidir, bu yüzden frameworkler genellikle daha güvenli depolama desenleri ve ortak korumalarla gelir. Temel kural değişmedi: parolayı (veya basit bir hash'ini) asla veritabanınızda saklamamalısınız.

Parola hashleme varsayılanları (ve neden düz hash güvensizdir)

Modern frameworkler genellikle bcrypt, Argon2 veya scrypt gibi amaça yönelik parola hashleyicilerini varsayılan olarak sunar. Bu algoritmalar kasıtlı olarak yavaştır ve salt içerir; bu, önceden hesaplanmış tablo saldırılarını önlemeye yardımcı olur ve büyük ölçekli kırmayı pahalı hale getirir.

SHA-256 gibi düz kriptografik hash'ler parolalar için güvensizdir çünkü hızlı olacak şekilde tasarlanmıştır. Bir veritabanı sızarsa, hızlı hash'ler saldırganların milyarlarca parolayı hızla denemesine izin verir. Parola hashleyiciler iş faktörleri (cost) içerir, böylece donanım geliştikçe güvenliği ayarlayabilirsiniz.

Genelde görülen parola politikaları

Frameworkler genellikle mantıklı kuralları her uç noktaya sert kodlamak yerine ara katman/eklenti şeklinde uygulamanıza olanak veren hook'lar sağlar:

• Uzunluk öncelikli politikalar (daha uzun parola/geçiş ifadeleri, kısa ama karmaşık kurallardan daha iyidir)
• Sızmış parola kontrolleri (bilinen sızdırılmış parola listelerine karşı kontrol)
• Oran sınırlama ve isteğe bağlı geçici kilitleme tekrar eden başarısız denemeler sonrası kaba kuvveti yavaşlatmak için

MFA seçenekleri ve takaslar

Çoğu ekosistem MFA'yı parola doğrulamasından sonra ikinci adım olarak eklemeyi destekler:

• TOTP doğrulayıcı uygulamalar: geniş destekli ve çevrimdışı çalışır; kullanıcı kandırılırsa kod girme yoluyla hala oltalanabilir.
• WebAuthn / passkey'ler: oltalama ve tekrar oynatmaya karşı güçlü koruma; kurulduğunda genelde en iyi UX'i sunar.
• SMS kodları: dağıtımı kolay, ama SIM-swap ve ele geçirme riskleri nedeniyle daha zayıf—hiç yoktan iyidir, yüksek riskli hesaplar için ideal değildir.

Güvenli hesap kurtarma

Parola sıfırlama yaygın bir saldırı yolu olduğundan, frameworkler genellikle şu desenleri teşvik eder:

• Sunucu tarafında saklanan (çoğunlukla parola gibi hashlenmiş) tek kullanımlık tokenlerle desteklenen sıfırlama linkleri
• Kısa süreli geçerlilik (dakikalar-saatler) ve tek kullanımlık zorunluluğu
• Başarılı sıfırlamadan sonra oturum geçersiz kılma veya token rotasyonu, böylece ele geçirilmiş oturumlar kalmasın

İyi bir kural: meşru kullanıcılar için kurtarmayı kolaylaştırın, ama saldırganların otomasyonunu maliyetli hale getirin.

Middleware, Koruyucular ve İstek Yaşam Döngüsü

Çoğu modern framework güvenliği istek hattının bir parçası olarak ele alır: kontrolör/handler'dan önce (ve bazen sonra) çalışan bir dizi adım. İsimler değişse de—middleware, filtreler, koruyucular, interceptorler—fikir aynıdır: her adım isteği okuyabilir, bağlam ekleyebilir veya işleme dur diyebilir.

Pratik bir pipeline zihinsel modeli

Tipik akış şu şekildedir:

1. Routing uç noktayı seçer (ör. /account/settings).
2. Ön işlem bileşenleri çalışır (middleware/filtreler/interceptorler).
3. Kimlik doğrulama çağıranı tanımlamaya çalışır.
4. Yetkilendirme tanımlanmış çağıranın uç noktaya erişip erişemeyeceğine karar verir.
5. Handler/controller iş mantığını çalıştırır.
6. Son işlem yanıtı dönüştürebilir veya loglayabilir.

Frameworkler güvenlik kontrollerini iş mantığından dışarda tutmanızı teşvik eder, böylece kontrolörler “ne yapmalı”ya odaklanır, “kimi izin verilmeli”ye değil.

Kimlik doğrulama nerede olur (önce kimlik)

Kimlik doğrulama, çerezlerden, session ID'lerden, API anahtarlarından veya bearer tokenlerden kullanıcı bağlamını çıkarma adımıdır. Başarılı olursa isteğe özgü bir kimlik oluşturur—genelde user, principal veya context.auth gibi bir nesne olarak erişilebilir.

Bu iliştirme önemlidir çünkü sonraki adımlar (ve uygulama kodu) başlıkları yeniden ayrıştırmamalı veya tokenleri yeniden doğrulamamalıdır. Zaten doldurulmuş kullanıcı nesnesini okumalıdır, bu nesne genelde şunları içerir:

• kararlı bir kullanıcı ID'si
• roller/claimler (bazen)
• kimlik doğrulama yöntemi veya oturum yaşı gibi metadata

Yetkilendirme nerede olur (izin kontrolleri)

Yetkilendirme genelde şunlar olarak uygulanır:

• rota düzeyinde koruyucular (ör. “oturum açılmış olmalı”)
• politikaya dayalı kontroller (ör. “bu belgeyi düzenleyebilir mi”) kaynağı yükledikten sonra değerlendirilir

İkinci tür, yetkilendirme kancalarının neden kontrolörler ve servislerin yakınında olduğunu açıklıyor: doğru karar vermek için rota parametrelerine veya veritabanından yüklenen nesnelere ihtiyaçları olabilir.

401 vs 403: hataları temiz ele alma

Frameworkler iki yaygın hata modunu ayırır:

• 401 Unauthorized (kimlik doğrulanmamış): geçerli bir kimlik kurulamamış. Tarayıcı uygulamalarında genelde oturum açma sayfasına yönlendirme, API'lerde JSON hata döndürme yapılır.
• 403 Forbidden (yetkisiz): kimlik biliniyor ama gerekli izne sahip değil.

İyi tasarlanmış sistemler 403 yanıtlarında hangi kuralın başarısız olduğunu ifşa etmez; erişimi reddeder ama detay vermez.

Yetkilendirme Modelleri: Roller, İzinler ve Politikalar

Yetkilendirme daha dar bir soruyu yanıtlar: “Bu oturum açmış kullanıcı şu anda bu belirli şeyi yapabilir mi?” Modern frameworkler genelde birkaç modeli destekler ve birçok ekip bunları birleştirir.

Rol tabanlı erişim kontrolü (RBAC)

RBAC kullanıcıları bir veya daha fazla role atar (admin, support, member) ve özellikleri bu rollere göre engeller.

Uygulaması kolaydır ve frameworkler genelde requireRole('admin') gibi yardımcılar sunar. Rol hiyerarşileri (“admin => manager => member”) çoğaltmayı azaltabilir, ama bir üst rolde yapılan küçük bir değişiklik uygulama genelinde gizli ayrıcalıklar verebilir.

RBAC geniş, sabit ayrımlar için en iyi çalışır.

İzin bazlı erişim (ince taneli)

İzin bazlı yetkilendirme bir eylemi bir kaynağa karşı kontrol eder, genelde şöyle ifade edilir:

• Eylem: read, create, update, delete, invite
• Kaynak: invoice, project, user, bazen bir ID veya sahiplik bilgisi ile

Bu model RBAC'den daha kesinlik sağlar. Örneğin, “projeleri güncelleyebilir” ile “sadece kendine ait projeleri güncelleyebilir” farklıdır; ikincisi hem izin hem de veri koşulu kontrolü gerektirir.

Frameworkler genelde kontrolörlerde, resolver'larda, worker'larda veya şablonlarda çağrılmak üzere merkezi bir “can?” fonksiyonu (veya servisi) uygular.

Politika tabanlı yetkilendirme (koşullarla kurallar)

Politikalar yetkilendirme mantığını yeniden kullanılabilir değerlendiricilere paketler: “Bir kullanıcı bir yorumu silerse eğer onu yazdıysa ya da moderatörse” gibi. Politikalar bağlam kabul eder (kullanıcı, kaynak, istek) ve şu durumlar için idealdir:

• sahiplik kontrolleri
• abonelik seviye kuralları
• zamana veya organizasyona dayalı kısıtlar

Frameworkler politikaları routing ve middleware ile entegre ettiğinde, kuralları uç noktalar arasında tutarlı şekilde uygulayabilirsiniz.

Notasyon/annotasyon vs kod tabanlı kontroller

Annotasyonlar (ör. @RequireRole('admin')) niyeti handler'a yakın tutar, ama kurallar karmaşıklaşınca parçalanabilir.

Kod tabanlı kontroller (yetkilendiriciye açıkça yapılan çağrılar) daha uzundur ama test etmesi ve refaktörlemesi genelde daha kolaydır. Ortak bir uzlaşma: kaba kapı filtreleri için annotasyonlar, ayrıntılı mantık için politikalar kullanmak.

Yerleşik Korumalardan Bazıları: CSRF, CORS ve Güvenlik Başlıkları

Modern frameworkler sadece kullanıcı girişine yardımcı olmaz—aynı zamanda kimlik etrafında ortaya çıkan en yaygın “web bağlantı” saldırılarına karşı savunmalarla gelir.

CSRF: çerez tabanlı tarayıcı uygulamalarını koruma

Uygulamanız oturum çerezleri kullanıyorsa, tarayıcı istekler sırasında bunları otomatik olarak iliştirir—bazen başka bir site tarafından tetiklenmiş isteklerde bile. Framework CSRF koruması genelde durum-değiştiren isteklerle birlikte gönderilmesi gereken per-oturum (veya per-istek) bir CSRF tokeni ekler.

Yaygın desenler:

• Synchronizer token: sunucu formlara bir token gömer ve POST/PUT/PATCH/DELETE isteklerinde doğrular.
• Double-submit cookie: CSRF tokeni bir çerezde saklanır ve ayrıca bir başlık/gövde alanında gönderilir; sunucu bunların eşleştiğini kontrol eder.

CSRF tokenlerini SameSite çerezleri (genelde varsayılan olarak Lax) ile eşleştirip, oturum çerezinizin HttpOnly ve Secure olmasını sağlamalısınız.

CORS: API'lerin açık kurallara ihtiyacı var

CORS bir kimlik mekanizması değildir; tarayıcı izin sistemi üzerinedir. Frameworkler genelde güvenilen kökenlerin API'nizi çağırmasına izin vermek için middleware/konfigürasyon sağlar.

Kaçınılması gereken yanlış yapılandırmalar:

• Access-Control-Allow-Origin: * ile birlikte Access-Control-Allow-Credentials: true kullanmak (tarayıcı bunu reddeder ve kafa karışıklığını gösterir).
• Gelen herhangi bir Origin başlığını yansıtmak yerine katı bir izin listesi kullanmamak.
• Gerekli başlıkları (ör. Authorization) veya metotları izin listesine eklemeyi unutmak; bu durum curl ile çalışan ama tarayıcıda başarısız olan istemcilere yol açar.

Clickjacking ve güvenlik başlıkları

Çoğu framework güvenli varsayılanlar ayarlayabilir veya şu başlıkları eklemeyi kolaylaştırır:

• Clickjacking'i önlemek için X-Frame-Options veya Content-Security-Policy: frame-ancestors.
• Geniş kapsamlı kaynak/script kontrolleri için Content-Security-Policy.
• Daha güvenli tarayıcı davranışı için Referrer-Policy ve X-Content-Type-Options: nosniff.

Girdi doğrulama vs yetkilendirme

Doğrulama verinin biçimsel olarak doğru olmasını sağlar; yetkilendirme kullanıcının bunu yapmaya yetkili olup olmadığını sağlar. Geçerli bir istek yine de yasaklanabilir—frameworkler her iki katmanı da erken uyguladığınızda en iyi çalışır: önce girdileri doğrulayın, sonra erişimi ilgili kaynağa göre zorlayın.

Uygulama Türüne Göre Desenler: SSR, SPA, Mobil ve Mikroservisler

“Doğru” kimlik deseni, kodunuzun nerede çalıştığına ve isteklerin arka uca nasıl ulaştığına bağlıdır. Frameworkler birden fazla seçeneği destekleyebilir, ama bir uygulama türünde doğal gelen varsayılanlar başka bir türde garip veya riskli olabilir.

Sunucu tarafı renderlanan uygulamalar (SSR)

SSR frameworkleri genelde çerez tabanlı oturumlarla iyi eşleşir. Tarayıcı çerezi otomatik olarak gönderir, sunucu oturumu bulur ve sayfalar kullanıcı bağlamıyla render edilebilir.

Pratik bir kural: oturum çerezlerini HttpOnly, Secure ve uygun bir SameSite ile tutun ve özel veri render eden her istekte sunucu tarafı yetkilendirme kontrollerine güvenin.

Tek sayfa uygulamalar (SPA)

SPAlar genellikle JavaScript'ten API çağrısı yaptığı için token seçimleri daha görünür olur. Birçok ekip kısa ömürlü erişim tokenleri üreten OAuth/OIDC akışını tercih eder.

Uzun ömürlü tokenleri localStorage'da saklamaktan kaçının; bu XSS patlama alanını artırır. Yaygın bir alternatif backend-for-frontend (BFF) desenidir: SPA kendi sunucunuza bir oturum çerezi ile konuşur ve sunucu yukarı akış API'ler için tokenleri değiş tokuş/ saklar.

Mobil istemciler

Mobil uygulamalar tarayıcı çerez kurallarına güvenemez. Genelde PKCE ile OAuth/OIDC kullanır ve yenileme tokenlerini platformun güvenli depolama alanında (Keychain/Keystore) saklarlar.

“Kayıp cihaz” kurtarması planlayın: yenileme tokenlerini iptal edin, kimlik bilgilerini döndürün ve MFA etkinse yeniden kimlik doğrulamayı pürüzsüz yapın.

Mikroservisler ve API ağ geçitleri

Birden çok servisle, merkezi kimlik ile servis düzeyi uygulama arasında seçim yaparsınız:

• Ağ geçidi merkezli: gateway tokenleri doğrular ve kimlik bağlamını iletir.
• Savunma derinliği: her servis tokenleri doğrular ve kendi kaynakları için yetkilendirme uygular.

Servisler arası kimlik doğrulama için frameworkler genelde mTLS (güçlü kanal kimliği) veya OAuth client credentials (servis hesapları) ile entegrasyon sunar. Anahtar nokta hem çağıranı kimlik doğrulamak hem de ne yapabileceğini yetkilendirmektir.

Taklit etme (Impersonation) ve yönetici erişimi

Yönetici “kullanıcı taklidi” özellikleri güçlü ama tehlikelidir. Açık taklit oturumlarını tercih edin, yöneticiler için yeniden kimlik doğrulama/MFA isteyin ve her zaman denetim kayıtları yazın (kim kimi taklit etti, ne zaman ve hangi eylemler yapıldı).

Test, Gözlemlenebilirlik ve Kaçınılması Gereken Tuzaklar

Güvenlik özellikleri kod değiştiğinde çalışmaya devam etmelidir. Modern frameworkler kimlik doğrulama ve yetkilendirmeyi test etmeyi kolaylaştırır, ama gerçek kullanıcı davranışını ve gerçek saldırgan davranışını yansıtan testlere ihtiyacınız var.

Kırılgan kurulumlar olmadan kimlik akışlarını test etmek

Ne test ettiğinizi ayırarak başlayın:

• Yetkilendirme kuralları için birim testleri (politika, koruyucu, izin kontrolleri). Bunlar hızlı olmalı ve “kullanıcı kaynağın sahibi mi” vs “admin geçersiz kılma” gibi kenar durumları kapsamalı.
• Korumalı rotalar için entegrasyon testleri (başarılı veya reddedilen istekler). Bunlar yanlış yerleştirilmiş middleware, eksik dekoratörler ve kırık yönlendirmeleri yakalar.

Çoğu framework test yardımcılarıyla gelir, böylece her seferinde oturum veya token elle oluşturmaya gerek kalmaz. Yaygın desenler:

• Çerezleri istekler arasında tutabilen bir test istemcisi (oturum tabanlı auth için kullanışlı).
• UI üzerinden geçmeden sahte kullanıcıyla oturum açma veya bir JWT/opaque token iliştirme yardımcıları.
• Kullanıcılar, roller ve kaynaklar için fixture/factory yardımları, testlerin okunur kalmasını sağlar.

Pratik bir kural: her “mutlu yol” testine bir de “reddedilmeli” testi ekleyin ki yetkilendirme kontrolünün gerçekten çalıştığını doğrulayın.

Koda hızlı iterasyon yaparken, geri alma destekli hızlı prototipleme araçları yardımcı olabilir. Örneğin, Koder.ai (bir vibe-coding platformu) React frontend ve Go + PostgreSQL backend oluşturup anlık görüntüler ve geri alma ile middleware/koruyucu ve politika denemelerinde değişiklikleri denetlemenizi sağlar—oturum vs token yaklaşımlarını denerken değişiklikleri denetlenebilir tutmak için kullanışlıdır.

Gözlemlenebilirlik: ne olduğuna değil, ne olduğunun kanıtına sahip olun

Bir şey ters gittiğinde hızlı ve emin cevaplar almak istersiniz.

Aşağıdaki olayları loglayın/denetleyin:

• Kimlik doğrulama olayları: oturum açma başarı/başarısızlık, MFA zorlama, parola sıfırlama, token yenilemeleri.
• Yetkilendirme reddleri: hangi politika başarısız oldu, hangi kaynakta, hangi kullanıcı için (sırları loglamaktan kaçının).
• Korelasyon ID'leri: bir istek ID'si loglar ve izler boyunca taşınsın, böylece bir oturum açma denemesini servisler arası takip edebilirsiniz.

Hafif metrikler de ekleyin: 401/403 oranları, başarısız oturum açma patlamaları ve alışılmadık token yenileme desenleri.

Frameworklerin tam kurtarmayacağı yaygın tuzaklar

• İstemci iddialarına güvenmek: UI bayraklarına veya istemci tarafı “roller”ine asla güvenmeyin. Her şeyi sunucuda zorlayın.
• İkincil uç noktalarda eksik kontroller: dışa aktarmalar, arka plan işleri, yönetici araçları ve “dahili” API'ler de yetkilendirmeye ihtiyaç duyar.
• Aşırı geniş kapsamlar/roller: “şimdilik yeterli” izinler kalıcı hale gelmeye meyillidir.
• Token sızıntısı: tokenleri loglarda, URL'lerde, kolay kopyalanan yerlerde saklamak veya üçüncü taraflara göndermek.

Yetki hatalarını test edilebilir davranışlar olarak ele alın: eğer gerileyebiliyorsa, bir teste değerdir.