Kendi başına yapabilir misin?

Güvenliği bir özellik değil kısıt olarak ele alırım: garanti etmeye çalıştığım şey olumsuz bir cümledir ("yetkisiz kimse başkasının belgesini okuyamaz"), o yüzden kabul kriterlerine yazılmazsa var olmaz. Karar çerçevem risk = olasılık × etki, artı önlemin kendi maliyeti — geliştirme süresi, çalışma zamanı, kullanıcı sürtünmesi; aşırı sürtünme üreten önlem atlatılır ve atlatılan önlem yok hükmündedir. Somut olarak işe güven sınırlarını çizerek başlarım: tarayıcı → API, API → veritabanı, API → dış servis, yükleme → dosya sistemi, yapılandırma → süreç. Her sınırda veri doğrulanır. Sonra saldırı yüzeyini listelerim: tüm uçlar, özellikle giriş/kayıt/parola sıfırlama, dosya yükleme-indirme, yönetim panelleri, zamanlanmış işler, webhook alıcıları, bağımlılıklar ve sırlar. Ardından STRIDE ile her akışa altı tehdit türünü sorarım ve ekiplerin kendiliğinden atladığı R (inkâr) ile D (hizmet engelleme) satırlarını bilerek zorlarım. Her tehdide dört karardan biri: azalt, devret, kabul et, ortadan kaldır — hepsine "azalt" yazmam, bilinçli kabul kararı da bu işin parçasıdır. Uygulama tarafında dört ilkeye yaslanırım: en az yetki (saldırıyı önlemez, patlama yarıçapını küçültür), derinlemesine savunma (bir katmanın bir gün başarısız olacağını varsayarım), güvenli varsayılan (yeni uç aksi belirtilmedikçe kapalı) ve güvenli çökme (yetki değerlendirmesi hata verirse cevap "hayır"dır; catch { return true; } gördüğüm yerde durup düzeltirim). Değişmez kuralım şu: istemciden gelen hiçbir şeye güvenmem — Angular guard'ı, devre dışı buton, gizli menü kullanıcı deneyimidir; doğrulamayı sunucuda tekrarlarım, kimliği istekten değil doğrulanmış oturumdan okurum, gövdeyi alan beyaz listesiyle bağlarım. Ve en değerli tek pratik olarak negatif testi söylerim: "yetkisiz kullanıcı 403 alır" testi, o kontrolü altı ay sonra bir refactor'da silen kişiyi yakalayan tek şeydir.

Parola: geri döndürülebilir saklamam. SHA-256 yanlıştır, çünkü hızlı olmak için tasarlanmıştır ve GPU saniyede milyarlarcasını hesaplar. Argon2id ya da bcrypt kullanırım; tuz kullanıcı başına rastgeledir ve gizli olması gerekmez, işi her hesabı ayrı bir problem yapmak ve gökkuşağı tablolarını geçersiz kılmaktır; istersem veritabanı dışında duran bir biber eklerim. Maliyeti ezberden değil ölçerek seçerim: kendi üretim donanımımda tek doğrulama 100-250 ms. Parametre yapılandırmadan gelir ve kullanıcı girişinde özet yeni parametrelerle yeniden üretilir. Node'daysam bir ayrıntı daha söylerim: hash libuv iş parçacığı havuzunda çalışır, havuz varsayılan dörttür — giriş ucunu oran sınırsız bırakırsam CPU düşükken gecikme uçar, yani giriş ucu bir DoS yüzeyidir. Numaralandırma: "kullanıcı yok" ile "parola yanlış" ayrımını hiçbir kanaldan sızdırmam — aynı mesaj, aynı durum kodu ve aynı süre: kullanıcı bulunamadığında da önceden üretilmiş sahte bir özete karşı doğrulama çalıştırırım; sıfırlama ucu her zaman "eğer bu adres kayıtlıysa bağlantı gönderildi" der. Sınırı iki boyutlu koyarım — hesap başına ve IP başına — çünkü parola serpme saldırısını hesap bazlı sınır hiç görmez; hesap kilitleme yerine üstel gecikme ve kademeli sürtünme tercih ederim, kilitleme kendi kendine DoS'a döner. Oturum mu JWT mi: tek alan adlı klasik bir web uygulamasında sunucu tarafı oturum seçerim — daha küçük, anında iptal edilebilir, saklama yeri tartışması yok. Çerezi __Host- önekiyle, HttpOnly, Secure, SameSite=Lax veririm; Domain yazmam, yazarsam çerez tüm alt alanlara gider. Oturum kimliğini CSPRNG ile üretir, paylaşımlı bir depoda tutarım (bellek içi oturum cluster'da her kopyada ayrıdır) ve iki zaman aşımı koyarım — mutlak süre yoksa çalınan oturum sonsuz yaşar. Girişte oturum kimliğini yenilerim, yoksa oturum sabitleme olur. JWT'yi gerçek bir gerekçe varsa seçerim: çok sayıda bağımsız doğrulayıcı, mobil, çapraz alan, federasyon.

Doğrulama bir kontrol listesidir: imza — JWKS'ten alınan anahtarla ve sunucunun dayattığı algoritma beyaz listesiyle; iss; aud; exp/nbf saat kaymasıyla; jeton türü. Algoritmayı jetondan okuyan kod alg=none ve algoritma karıştırmaya açıktır — ikincisinde saldırgan başlığı HS256 yapıp jetonu herkese açık olan RSA anahtarını HMAC sırrı gibi kullanarak imzalar. aud'u atlayan kod başka bir API için verilmiş jetonu kabul eder; en sık atlanan kontrol budur. .NET'te ClockSkew varsayılanının 5 dakika olduğunu bilir, 30 saniyeye çekerim. Bir de decode ile verify'ı karıştırmam — ilki imzayı kontrol etmez. İptal problemi: JWT kendi kendini doğruladığı için verildikten sonra geri alınamaz; çıkış, hesap askıya alma, rol düşürme exp gelene kadar işlemez. Dört kalıbı sayarım: kısa ömür + sunucuda kayıtlı yenileme jetonu, kara liste, sürüm iddiası ve introspection. Pratikte dengeli bileşim kısa ömürlü erişim jetonu + kayıtlı yenileme + kritik olaylarda sürüm iddiasıdır; yenilemede dönüşüm ve yeniden kullanım tespiti uygularım — geçersiz bir yenileme jetonu tekrar sunulursa tüm aileyi iptal ederim. Saklama sorusunda tek doğru yoktur, risk yer değiştirir: localStorage'da XSS jetonu dışarı çıkarır, httpOnly çerezde CSRF gelir, BFF deseninde jeton tarayıcıya hiç inmez ve bugünün varsayılanı odur. OAuth2 ↔ OIDC: OAuth2 bir delegasyon protokolüdür — uygulamanın, parolamı görmeden, sınırlı kapsamda ve süreli olarak verime erişmesini sağlar; erişim jetonu taşıyıcı bir kimlik bilgisidir ve kimin verdiğinin kanıtı yoktur, dolayısıyla onunla oturum açmak jeton değiştirme saldırısına açıktır. OIDC bu boşluğu id_token ile kapatır: aud'u benim client_id'm olan, nonce ile isteğime bağlanmış imzalı bir kimlik belgesi. Akış: her istemci türü için authorization code + PKCE; ön kanaldan jeton değil kod taşınır, kodu code_verifier ile arka kanalda çeviririm. state CSRF'ye, PKCE kod ele geçirmeye, nonce jeton tekrarına bakar — üçü farklı saldırılardır. Implicit jetonu ön kanalda döndürdüğü için, ROPC parolayı uygulamaya yazdırdığı için terk edildi. Makineden makineye işlerde client credentials kullanırım ve o jetonda kullanıcı olmadığını unutmam. Son olarak kapsam yetkilendirme değildir: basvuru.oku jetonu gelse de kaynak sunucu "bu kullanıcı bu kaydın sahibi mi" sorusunu ayrıca sorar.

Yetkilendirme API'de yapılır. Arayüzdeki router guard'ı, gizli menü ve devre dışı buton kullanıcı deneyimidir; karar sunucudadır ve her servis kendi kararını verir — BFF kimliği taşısa da iç servisler "nasılsa kontrol etmiştir" demez. Modelden önce gelen şey nesne düzeyi kontroldür: en yaygın kritik zafiyet IDOR'dur ve sebebi rolün kontrol edilip sahipliğin unutulmasıdır. Üç kuralım var: kimliği istekten değil doğrulanmış oturumdan okurum; sahiplik koşulunu sorgunun kendisine yazarım (böylece unutulacak adım kalmaz); tahmin edilemez kimlik (UUID) yüzeyi küçültür ama tek başına önlem değildir. ASP.NET Core'da bunun çerçeve karşılığı kaynak tabanlı yetkilendirmedir: [Authorize] istek işlenmeden önce çalışır ve o anda ortada kaynak yoktur, bu yüzden IDOR'u kapatamaz; IAuthorizationService ile kaynağı yükledikten sonra karar veririm. Güvenli varsayılan için FallbackPolicy kurarım — nitelik yazmayı unutmak ucu açık değil kapalı bırakır; ara yazılım sırasını da bilirim, çünkü UseAuthorization unutulduğunda [Authorize] sessizce yok sayılır. SQL injection: kök sebep veri ile komutun aynı kanaldan gitmesidir; parametreli sorgu kanalları ayırır ve bu yüzden kaçış karakterinden kategorik olarak güçlüdür. "ORM kullanıyorum" cümlesi yetmez: ham SQL API'leri, dinamik sıralama ve saklı yordam içi dinamik SQL açık kapılardır — parametre olamayan şeyleri (tablo/sütun adı, ASC/DESC) beyaz listeyle koyarım. Hata mesajını gizlemek de yetmez, kör enjeksiyon boolean ve zaman farkıyla çalışır. XSS: asıl savunma bağlama göre çıktı kodlamasıdır ve çerçeveler bunu varsayılan yapar; açıklar dangerouslySetInnerHTML, bypassSecurityTrust, @Html.Raw, düz innerHTML gibi kaçış kapılarından girer — zengin metin gerekiyorsa sunucuda olgun bir temizleyici kullanırım, düzenli ifadeyle etiket temizlemem. İkinci hat CSP'dir: XSS'i önlemez ama işe yaramasını engeller; unsafe-inline yerine nonce kullanır, mevcut sisteme Report-Only ile sokarım. Sırlar: depoda tek bir sır bulunmaz; geliştirmede user secrets ya da .gitignore'lu .env, üretimde kasa + yönetilen kimlik — "kasaya bağlanmak için de sır gerekmez mi" paradoksunu bu çözer. Ortam değişkeninin kasa olmadığını bilirim: /proc/<pid>/environ, docker inspect, alt süreç mirası, hata izleme araçlarının çökme raporuna ortamı eklemesi. Bu yüzden üretimde sırrı dosya olarak bağlarım; hem ortamda görünmez hem döndürüldüğünde yeniden başlatmadan okunabilir. Döndürmeyi iki anahtar dönemiyle kesintisiz yaparım (JWT'de kid + JWKS, sertifikada ACME + reload). Ve sızıntıda ilk iş geçmişi temizlemek değil, sırrı iptal etmektir: sızmış bir sır artık sır değildir.