Kısım II · İnşaat · Bölüm 41

Kimlik Doğrulama ve Güvenlik

Hesabı tanımak, erişimi sınırlamak, veriyi korumak (Authentication and security)

1. Kat 10Bizim uygulamamızGiriş, oturum, kaynak bazında erişim ve veri koruma kararları. Yeni bir donanım katı değil, mevcut katlar arasında güven sınırları kuruyoruz. Kat planına dön.
2. Kat 9Web ve tarayıcıWeb istemcisi sunucunun sözleşmesini kullanır.
3. Kat 8Ağ ve internetHTTP istekleri, DNS ve TLS; parçalar ayrı makinelerdeyken aradaki yol.
4. Kat 7İşletim sistemiSüreçler, dosyalar ve izinler; altta Kat 3'ün işlemcisi ve belleği.

Bölüm sonunda giriş yapmak ile izinli olmak arasındaki farkı, parolanın neden geri okunabilir saklanmadığını, oturumun nasıl sürdüğünü ve üç farklı saldırının neden üç farklı savunma gerektirdiğini anlatabileceksin. Sonunda teknik güvenlikle kişisel veri hukukunun neden birbirine indirgenemediğini göreceğiz.

41.1 Kimlik doğrulama ile yetkilendirme farkı

Bir kullanıcı, hukuk uygulamamızın sunucusuna “Ben Kerem'im; cevap geçmişimi getir” desin. Burada birbirinden ayrı iki talep var. İlki kimliğiyle ilgili bir iddia, ikincisi belirli veriye erişme isteği. Kimlik doğrulama (authentication, AuthN), sunulan kanıtın o hesaba ait olduğunu sınar. Yetkilendirme (authorization, AuthZ) ise bu kimliğin istenen kaynağa, istenen işlemi yapma izni olup olmadığını belirler. Giriş yapmak, bütün kapıları açan genel bir izin değildir.¹²

Hukuk benzetmesi burada işe yarıyor: kişinin kimliğini tespit etmek, o dosyanın tarafı ya da vekili olduğunu tespit etmekle aynı işlem değildir. Yazılımda da hesabın kimliğini doğruladık diye başka hesabın cevaplarını gösteremeyiz. Dahası, dijital bir hesaba giriş yapılması kişinin resmî kimliğinin doğrulandığı anlamına gelmez; e-posta ve parola ile çoğu zaman bir hesabın denetimi kanıtlanır. Bu uygulama için nüfus cüzdanı toplamaya kendiliğinden gerekçe doğmaz.¹

İstek üzerinde iki ayrı kontrol

Örnek uç nokta GET /users/42/answers olsun. Sunucu önce oturumun hangi kullanıcıya ait olduğunu bulur. Ardından “bu kullanıcı 42 numaralı hesabın geçmişini okuyabilir mi?” sorusunu sorar. Adresteki 42 değerini 43 yapmak, tek başına erişim sağlamamalıdır. Kaynak kimliğini tahmin etmeyi zorlaştırmak yardımcı olabilir ama nesneye erişim kontrolünün yerine geçmez. OWASP bu tür hataları kullanıcı denetimindeki nesne kimliği üzerinden yetki atlama bağlamında ele alır.²

Güvenli varsayım, açıkça izin verilmemiş erişimi reddetmektir. Kontrol, sadece kullanıcı arayüzünde değil sunucuda ve her ilgili istekte yapılır. “Düzenle” düğmesini gizlemek kullanıcının kafasını karıştırmamayı sağlar; saldırganın aynı HTTP isteğini kendisinin göndermesini engellemez. Bölüm 34: Arka Uç ve API içindeki güven sınırı burada bir kurala dönüşüyor: istemcinin gönderdiği userId ya da role değerini kimliğin kanıtı olarak kabul etme.²

41.2 Parolaları saklamak: özet fonksiyonu, tuz, bcrypt ve Argon2

Giriş formunda kullanıcı parolasını sunucuya gönderir; yol üzerindeki gizliliği Bölüm 20: İnternet ve Web: HTML'e Varış içindeki HTTPS sağlar. Ama HTTPS, veritabanındaki düz metin parolayı güvenli hale getirmez. Veritabanı ya da yedeği sızarsa ne olacağını da düşünmeliyiz. Sunucunun ihtiyacı kullanıcının parolasını geri okuyabilmek değil, sonraki girişte gönderilen parolanın doğru olup olmadığını sınamaktır. Bu nedenle parola, geri çözülebilen şifreleme yerine uygun bir özet fonksiyonuyla (hashing) işlenir.³

Bölüm 28: Git içinde özet değeri içeriğin kısa bir kimliği olarak görmüştün. Parola saklamada aynı genel aileden fakat farklı amaçla seçilmiş bir araç gerekir. SHA-256 gibi hızlı genel amaçlı özetler, saldırganın çok sayıda parola tahminini hızla sınamasını da kolaylaştırır. Parola için özellikle pahalılaştırılmış, maliyeti ayarlanabilen bir yöntem seçilir. “Tek yönlü” demek, saldırganın parolayı asla öğrenemeyeceği demek değildir: olası parolaları deneyip aynı sonucu arayabilir. Savunmanın amacı bu denemeleri pahalılaştırmaktır.³

Tuz neden gizli değildir?

Tuz (salt), her parola kaydı için ayrı üretilen rastgele bir girdidir. Aynı parolayı seçen iki kişinin saklanan sonuçlarının aynı olmasını önler; önceden hazırlanmış parola–özet tablolarının topluca işe yaramasını zorlaştırır. Tuzun kullanıcıya özgü olması gerekir, gizli olması gerekmez; özetin yanında saklanabilir. Bakımı yapılan yüksek seviyeli parola kütüphaneleri çoğu zaman tuzu kendileri üretip saklama biçimine dahil eder. Kütüphanenin bu işi gerçekten yaptığı belgelenmeden varsayılmaz.³

Kayıtta: parola + yeni rastgele tuz + maliyet ayarları → parola özeti
Saklanan: yöntem adı, maliyet ayarları, tuz, sonuç
Girişte: gelen parola + kayıtlı ayarlar → kütüphanenin doğrulama işlemi

Bu çizim gerçek bir kriptografik formül değil, sorumluluk haritasıdır. İlk satır her yeni parola kaydını ayırır. İkinci satır, gelecekte doğrulama için gereken bilgilerin kayıtta bulunmasını sağlar. Üçüncü satırda yeni tuz üreterek sonuç karşılaştırmıyoruz; kayıtla birlikte gelen ayarları kullanan doğrulama işlevini çağırıyoruz. Parolayı çözmeye de çalışmıyoruz. Kendi özet algoritmamızı ya da karşılaştırma düzenimizi icat etmek yerine uygun kütüphanenin belgelenmiş arayüzünü kullanıyoruz.³

bcrypt ile Argon2 arasındaki seçim

bcrypt, ayarlanabilir hesap maliyeti olan bir parola özetleme yöntemidir. Argon2 ailesinin Argon2id çeşidi, bellek kullanımını da maliyetin parçası yapar. Okuduğumuz OWASP rehberi yeni sistemler için Argon2id'i öne çıkarır; bcrypt'i daha çok eski sistemlerle uyumluluk bağlamında ele alır. Burada tek bir sabit maliyet sayısını “her sunucu için doğru” diye vermiyoruz. Ayarlar güncel rehberden seçilir, hedef sunucuda giriş yükü altında ölçülür ve zaman içinde yükseltilebilir biçimde saklanır.³

İki ayrıntı önemlidir. Birincisi, pahalı özetleme sınırsız giriş denemesi kabul etmek anlamına gelmez; sunucunun kendi işlemcisini tüketen saldırılara karşı da giriş denemelerini sınırlamak gerekir. İkincisi, bcrypt gerçeklemelerindeki girdi sınırları byte cinsindendir; Bölüm 2: Bit ve Byte içindeki karakter–byte ayrımı Türkçe parolalarda da geçerlidir. Sessizce kırpma yerine seçilen kütüphanenin sınırını açıkça ele almak gerekir. Kullanıcıya gösterilen genel hata mesajları da hangi hesapların var olduğunun kolayca öğrenilmesini önlemeye yardım eder.³¹

Bölüm 40: Önbellek ve Redis içindeki hız sınırlama, çevrimiçi denemeleri azaltır. Parola özetleme ise veri sızdıktan sonraki çevrimdışı denemeleri zorlaştırır. Bunlar aynı kapıya takılmış iki farklı kilit değil, iki farklı tehdide karşı iki ayrı savunmadır. Yönetici hesapları gibi etkisi büyük hesaplar için çok faktörlü kimlik doğrulama da düşünülür: birden fazla bağımsız kanıt türü kullanılır; aynı parolayı iki kez sormak ikinci faktör değildir.¹

41.3 Oturum, çerez, belirteç ve OAuth ile “Google ile giriş”

Parolayı her istekte yeniden göndermek istemeyiz. Oturum (session), birbiri ardına gelen istekleri aynı kullanıcı bağlamında ilişkilendiren düzendir. Giriş başarılı olduğunda sunucu tahmin edilmesi zor bir oturum kimliği üretir. Sonraki isteklerde bu kimlik taşınır; sunucu oturum deposundan kime ait olduğunu, süresinin dolup dolmadığını ve iptal edilip edilmediğini kontrol eder. Bölüm 40: Önbellek ve Redis deposunu anlattı; şimdi o depoya erişim sağlayan kimliği koruyoruz.⁴

Çerez bir taşıma ve saklama mekanizmasıdır

Çerez (cookie), tarayıcının saklayabildiği ve kapsamına uyan isteklere ekleyebildiği küçük bir değerdir. Kimliğin kendisini kanıtlayan sihirli bir dosya değildir. İçinde rastgele oturum kimliği de olabilir, başka biçimde bir belirteç de. Aşağıdaki başlık bir yapı örneğidir; ORNEK_DEGER gerçek bir oturum kimliği değildir.⁴

Set-Cookie: session=ORNEK_DEGER; Path=/; Secure; HttpOnly; SameSite=Lax

• session=... saklanacak ad–değer çiftidir; kimlik bilgilerini doğrudan içine doldurmak gerekmez.
• Path=/ yol kapsamını belirtir; uygulama içindeki yetki kontrolünün yerine geçmez.
• Secure çerezin HTTPS üzerinden gönderilmesini gerektirir.
• HttpOnly JavaScript'in çerez değerini doğrudan okumasını engeller; kötü amaçlı JavaScript'in kullanıcı adına istek göndermesini tek başına engellemez.
• SameSite=Lax bazı siteler arası isteklerde çerezin gönderilmesini sınırlar; birazdan göreceğimiz CSRF için ek savunmadır, genel ve eksiksiz çözüm değildir.

Bu nitelikler farklı tehditleri ele alır; birbirinin alternatifi değildir.⁴¹⁰

Oturum kimliği ele geçirilirse parola bilinmeden de kullanıcı adına erişim mümkün olabilir. Bu yüzden kimliği URL'ye, hata raporuna ya da kayıt çıktısına koymayız. Girişte ve yetki değişimlerinde kimliği yenileriz; süre sınırını sunucuda uygularız. Çıkışta tarayıcıdaki çerezi silmekle kalmaz, sunucudaki oturumu da geçersiz kılarız. Redis kaydının kaybolması kullanıcıyı yeniden girişe yöneltmeli; sistem “depo çalışmıyor, herkesi kabul edelim” dememelidir.⁴²

Belirteç ile JWT aynı şey değildir

Belirteç (token), erişim ya da kimlik bağlamında taşınan değerin genel adıdır. Anlamı sunucudaki kayıttan bulunabilen rastgele bir değer olabilir. JWT (JSON Web Token) ise iddiaları taşıyan standart bir biçimdir; bir oturum yönetim politikasının tamamı değildir. İmzalı JWT'de imza doğrulanması, içeriğin gizli olduğu anlamına gelmez. Okumak, doğrulamak ve yetkilendirmek ayrı işlemlerdir. JWT'nin standart metni RFC 7519'dur; burada yalnızca başvuru olarak veriyoruz, kendimiz JWT doğrulayıcısı yazmıyoruz.⁵⁶

Örneğin bir API, Authorization: Bearer ORNEK_DEGER başlığıyla erişim belirteci alabilir. “Bearer”, taşıyanın kullanabildiği düzeni anlatır; çalınan değer yeniden kullanılabilir. JWT biçimindeki bir değerde yalnızca JSON'u okumak yetmez: güvenilen sağlayıcı, imza, hedef alıcı ve süre gibi koşullar doğru kütüphaneyle doğrulanmalıdır. Bir kimlik belirtecini, farklı bir API için üretilmiş erişim belirteci yerine kullanmayız.⁷⁶

Sunucu kaydına her istekte bakmadan doğrulama yapmak mümkün olsa da iptal sorusu kaybolmaz. Kullanıcı çıkış yaptıysa, hesabı kapatıldıysa ya da yetkisi kaldırıldıysa daha önce verilmiş belirtecin ne zaman etkisizleşeceği tasarlanmalıdır. Kısa ömür, yenileme ve gerektiğinde sunucu tarafında iptal denetimi farklı bedeller taşır. “JWT kullandık, artık sunucuda hiçbir duruma gerek yok” yanlış bir sonuçtur. Tarayıcıdaki depolama seçimi de biçimden ayrı bir karardır; JavaScript'in okuyabildiği bir yerde tutulan değer XSS durumunda ele geçirilebilir.⁴⁷

Google'a parolayı vermek başka, Google parolasını almak başka

OAuth 2.0 (authorization framework), bir hizmete sınırlı erişim yetkisini başka bir istemciye devretme çerçevesidir; tek başına standart bir kullanıcı giriş protokolü değildir. OpenID Connect (OIDC), OAuth 2.0 üzerinde kimlik doğrulama katmanı ekler. Gündelik dilde “OAuth ile Google girişi” denilen işin kimlik tarafını bu ayrım üzerinden okumak gerekir.⁷⁶

Kavramsal yolculuk şöyle: uygulama kullanıcıyı kimlik sağlayıcısına yönlendirir; kullanıcı parolasını bizim forma değil sağlayıcıya verir; sağlayıcı izin verilen dönüş adresine bir yanıt gönderir; uygulama bu akışın kendi başlattığı akış olduğunu ve gelen kimlik kanıtının geçerliliğini doğrular; sonra kendi hesabıyla ilişkilendirip kendi oturumunu kurar. Yetkilendirme kodu akışında PKCE, kodu başlatan istemciyle bağlamaya yardım eden bir kanıttır. Dönüş adresi ve akış bağlama denetimleri de gerekir. Bunları elle birleştirmek yerine bakımı yapılan bir kütüphane ve sağlayıcının belgelenmiş akışı seçilir.⁷⁶

41.4 Yaygın saldırılar: SQL enjeksiyonu, XSS, CSRF ve OWASP Top 10

Üç saldırıyı aynı “kötü girdi” torbasına atarsak savunmayı da karıştırırız. SQL enjeksiyonunda hedef SQL yorumlayıcısıdır. XSS'te hedef tarayıcının metni etkin içerik olarak işlemesidir. CSRF'de ise zaten giriş yapmış tarayıcının yetkisini kötüye kullanan başka bir istek üretilir. Hangi sınırın aşıldığını bilmek, hangi önlemin işe yaradığını anlamayı sağlar.⁸⁹¹⁰

SQL enjeksiyonu: veri komutun içine kaçarsa

Bölüm 39: Postgres Pratikte içindeki parametreli sorgu örneğini yeniden uzun uzun kurmayalım. Oradaki sorun, kullanıcı adını sorgu metnine eklemekti. Çözüm, sorgunun yapısını sabit tutup değerleri ayrı parametreler olarak vermekti. Bu ayrım yalnız giriş ekranı için değil arama, raporlama ve yönetici uç noktaları için de geçerlidir. Kullanıcı zaten giriş yapmış diye girdisi SQL komutu olmaya hak kazanmaz.⁸

Bir sınır: parametreler değer içindir; tablo adı, sütun adı ya da ASC/DESC gibi SQL yapısını temsil etmez. Sıralama seçeneği gerekiyorsa kullanıcı seçimini uygulamanın sahip olduğu küçük bir izin listesindeki sabit SQL parçalarına eşleriz. “Tırnakları silmek” ya da kendimiz kaçışlama yazmak, parametreli sorgunun yerine geçmez.⁸

XSS: metin tarayıcıda etkin içeriğe dönüşürse

Siteler arası betik çalıştırma (cross-site scripting, XSS), güvenilmeyen içeriğin sayfaya tarayıcının çalıştırabileceği biçimde yerleştirilmesidir. Örnek olarak kullanıcının görünen adını sıralama tablosuna yazıyoruz. Adı düz metin olarak göstermek isterken HTML olarak ayrıştırırsak ad alanı, saldırganın belgeye etkin içerik soktuğu kapı olabilir. Verinin veritabanından gelmesi onu güvenilir yapmaz; oraya daha önce kullanıcı yazmış olabilir.⁹

// Sıradan bir <span> öğesine düz metin yerleştirme örneği:
adAlani.textContent = kullaniciAdi;

İlk satır örneğin bağlamını söyler: sıradan bir metin öğesi. İkinci satır Bölüm 26: JavaScript ile Sayfayı Canlandırmak içindeki DOM API'siyle metni atar, HTML olarak ayrıştırmaz. Bu, “her bağlamda textContent güvenlidir” kuralı değildir; bir script öğesinin içeriği başka davranır. Genel savunma, çıktıyı girdiği bağlama uygun kodlamak ve gerekmedikçe ham HTML kabul etmemektir. Zengin HTML içerik gerçekten gerekiyorsa bakımı yapılan bir temizleme aracı kullanılır. React'ın varsayılan metin işleme korumaları da ham HTML ekleme kaçışlarında kendiliğinden yeterli olmaz.⁹

CSRF: kullanıcının tarayıcısına istemediği işlem yaptırılırsa

Siteler arası istek sahteciliği (cross-site request forgery, CSRF), başka bir sitenin kullanıcının giriş yaptığı uygulamaya onun tarayıcısı üzerinden istenmeyen bir işlem göndertmesidir. Tarayıcı uygun kapsamdaki oturum çerezini kendisi ekleyebildiği için, “geçerli oturum çerezi geldi” tek başına “bu işlemi kullanıcı bizim ekranımızda istedi” anlamına gelmez. Saldırganın önce parolayı ya da çerezi okuması şart değildir.¹⁰

Çerezle kimlik doğrulanan durum değiştirici isteklerde sunucunun doğruladığı CSRF belirteci gibi uygun bir savunma kurulur. SameSite ve isteğin kaynağına yönelik denetimler bunu destekler. GET ile hesap silmek gibi durum değiştiren işler yapılmaz. Bölüm 35: HTTP, JSON ve REST içindeki CORS ise tarayıcı kökenleri arası erişim kurallarıyla ilgilidir; genel bir yetkilendirme ya da tek başına CSRF çözümü değildir. XSS, kullanıcının kendi kökeninde kod çalıştırabildiği için CSRF savunmalarını da aşındırabilir.¹⁰

OWASP Top 10 (web application security risks), önemli web güvenliği risklerine ilişkin farkındalık belgesidir. Okuma tarihinde ana proje sayfası 2025 sürümünü güncel yayımlanmış sürüm olarak gösteriyor. Burada on başlığı ezberlemiyoruz: kimlik ve erişim, enjeksiyon, yanlış yapılandırma ve bağımlılık riskleri gibi sınıfları tanımak için kullanıyoruz. Listeyi bitirmek güvenlik denetiminin bittiği anlamına gelmez; belirli savunmanın ayrıntısı ilgili Cheat Sheet'te okunur.¹¹

41.5 Sırların yönetimi ve en az yetki ilkesi

Bölüm 28: Git içinde sırların depoya girmemesini öğrendin. Şimdi bu kuralı çalışan sisteme taşıyoruz. Sırların yönetimi (secrets management), veritabanı parolası, imzalama anahtarı ve hizmet erişim anahtarı gibi değerlerin üretilmesi, gerektiği yere ulaştırılması, erişiminin sınırlandırılması, değiştirilmesi ve iptal edilmesidir. Yalnızca “bir dosyaya yazıp dosyayı gizlemek” değildir.¹²

En az yetki ilkesi (least privilege), bir kullanıcıya, sürece ya da agent'a yalnızca işi için gereken erişimi vermektir. Cevap kaydeden Go sürecinin bütün veritabanını silebilen yönetici hesabıyla çalışması gerekmez. Şema göçü için kullanılan yetkiyle gündelik isteklerin yetkisi ayrılabilir. Test ortamının anahtarı üretimi açmamalı, bir yayın görevinin izni bütün bulut hesabını yönetmemelidir.¹²²

Sır, sunucuya çalışma sırasında güvenli bir dağıtım düzeniyle verilir; Bölüm 43: Yayına Alma ve Bulut bunun yapılandırma tarafını ele alacak. Ortam değişkeni kullanmak kaynağa gömmeyi önler ama tek başına şifreli kasa değildir. Kayıt çıktısı, süreç erişimi ve hata raporları gibi başka sızma yolları da düşünülmelidir. Kullanıcının cihazına dağıttığın JavaScript ya da mobil paket ise sunucu sırrını saklayacak güven sınırı değildir.¹²

41.6 Kişisel veri ve KVKK/GDPR'ye kısa bakış

Kişisel veri (personal data), kimliği belirli veya belirlenebilir gerçek kişiye ilişkin bilgidir. Hesaba bağlı e-posta, cevap geçmişi ve öğrenme ilerlemesi bu değerlendirmeye girebilir; sadece ad ve kimlik numarası düşünme. KVKK m.3'te amaç ve vasıtaları belirleyen veri sorumlusu ile onun adına veri işleyen ayrılır. Bir bulut hizmetinden yararlanmak, veri sorumlusunun yükümlülüklerini kendiliğinden ortadan kaldırmaz.¹³

Yazılım kararlarına bağlayacağımız kısa çerçeve şu: KVKK m.4 amaçla bağlantılı, sınırlı, ölçülü işlemeyi ve gerekli süre kadar saklamayı gerektirir; m.5'te açık rıza dışında şartlar da vardır, dolayısıyla “bir onay kutusu ekle, her şeyi topla” doğru değildir. M.10'daki aydınlatma, m.5'teki işleme şartından ayrı bir yükümlülüktür. M.7 silme/yok etme/anonimleştirmeyi, m.11 ilgili kişi haklarını, m.12 uygun güvenlik tedbirlerini gündeme getirir. Somut tasarım sonucu: hangi veriyi neden topladığını, ne kadar tuttuğunu, kimin eriştiğini ve hak taleplerini nasıl karşılayacağını önceden belirlemek gerekir.¹³

GDPR'nin m.3 kapsamı yalnız “AB vatandaşı kullanıcı” ölçütüne indirgenmez: AB'deki kuruluş bağlamında işleme ile AB dışından Birlik içindeki kişilere mal/hizmet sunma veya onların Birlik içindeki davranışlarını izleme gibi ölçütler önemlidir. M.5 ilkeleri, m.6 hukuki sebepleri, m.13 bilgilendirmeyi ve m.32 riske uygun güvenliği düzenler. Silme hakkı m.17'de şart ve istisnalarıyla bulunur; her verinin her talepte anında silineceği şeklinde okunmaz. Kaynak, kabul edildiği şekliyle AB tüzüğünün resmî yayımlanmış metnidir; UK GDPR ile karıştırılmamalıdır.¹⁴

Bizim için başlangıç soruları yeterli: soru çözmek için gerçek ad zorunlu mu; sıralamada e-posta yerine görünen ad yeter mi; testte gerçek hesaplar yerine kurgu veriler kullanılabilir mi; yedekler ve kayıt çıktıları da saklama planında mı? Yurt dışındaki buluta kişisel veri aktarmak KVKK m.9 bakımından ayrıca incelenir; “bulut güvenli” veya “rıza aldık” cümlesi tek başına bu incelemenin yerine geçmez. Burada hukuki uygunluk reçetesi vermiyoruz; teknik planın veri envanteri ve somut hukuki değerlendirmeyle birlikte yapılması gerektiğini işaretliyoruz.¹³¹⁴

Bu bölümde neler kuruldu

Kimlik doğrulama hesap kanıtını, yetkilendirme işlem iznini sınar. Parolalar uygun maliyetli özet ve ayrı tuzlarla korunur; yeni sistemler için Argon2id güncel rehberle değerlendirilir. Oturum sunucuda süre ve iptal politikası gerektirir; çerez taşıma mekanizması, JWT bir biçim, OAuth yetki devri, OIDC kimlik katmanıdır. SQL enjeksiyonu, XSS ve CSRF farklı güven sınırlarını aşar. Sırlar yaşam döngüsü ve en az yetkiyle yönetilir. Kişisel veri ise güvenlik önlemlerine ek olarak amaç, hukuki sebep, aydınlatma, saklama ve haklar bakımından değerlendirilir.

Terimler sözlükte, Bölüm 41 başlığı altında.

Kaynaklar

1. OWASP, Authentication Cheat Sheet: hesap kimliği, genel hata yanıtı, giriş sınırlama ve çok faktörlü doğrulama.
2. OWASP, Authorization Cheat Sheet: varsayılan ret, her istekte ve nesne bazında sunucu kontrolü.
3. OWASP, Password Storage Cheat Sheet: özetleme, tuz, Argon2id ve eski sistemlerde bcrypt.
4. OWASP, Session Management Cheat Sheet: oturum kimliği, çerez nitelikleri, yenileme ve sona erdirme.
5. RFC 7519, JSON Web Token (JWT): yalnızca standart başvurusu; bu bölüm bir kriptografi gerçekleme rehberi değildir.
6. OpenID Foundation, OpenID Connect Core 1.0: Introduction, ID Token ve ID Token Validation.
7. OWASP, OAuth2 Cheat Sheet: PKCE, erişim belirteci yetkileri ve tekrar kullanım riski.
8. OWASP, SQL Injection Prevention Cheat Sheet: parametreler ve yapısal parçalar için izin listesi.
9. OWASP, Cross Site Scripting Prevention Cheat Sheet: bağlama uygun çıktı kodlama ve Safe Sinks.
10. OWASP, Cross-Site Request Forgery Prevention Cheat Sheet: CSRF belirteci, SameSite sınırları.
11. OWASP Top 10 ana proje sayfası: güncel yayımlanmış 2025 sürümü ve farkındalık amacı.
12. OWASP, Secrets Management Cheat Sheet: erişim kontrolü, dağıtım, döndürme ve sızmada iptal.
13. Mevzuat Bilgi Sistemi, 6698 sayılı Kişisel Verilerin Korunması Kanunu, resmî bütünleşik metin: m.3–5, 7, 9–12.
14. Regulation (EU) 2016/679, Avrupa Birliği Resmî Gazetesi metninin legislation.gov.uk üzerindeki adopted kopyası: m.3–6, 13, 17 ve 32; Birleşik Krallık değişikliklerini içeren revised metin değildir.