Gerçekten İşe Yarayan Bir E-posta Doğrulama Sistemi Nasıl Kurulur

E-posta doğrulaması neden düşündüğünüzden daha önemli

"Neden" ile başlayalım — çünkü e-posta doğrulamasının amacını anlamak, onu ne kadar dikkatli kurduğunuzu değiştirir. İlk neden temel doğruluktur: kullanıcının sağladığı adresi gerçekten kontrol ettiğini teyit eder. E-posta alanlarındaki yazım hataları dikkate değer ölçüde yaygındır. [email protected] yerine [email protected] yazan bir kullanıcı e-postalarınızı asla almayacak ve doğrulama olmadan, haftalar sonra bir destek talebi açana kadar bunu asla bilemeyeceksiniz. Hatalı adresleri kayıt anında yakalamak, onları sonradan kovalamaktan çok daha ucuzdur.

İkinci neden dolandırıcılığın önlenmesidir. Otomatik hesap oluşturan botlar tipik olarak tek kullanımlık veya uydurma adresler kullanır çünkü insanlar aslında o gelen kutularını kontrol etmeyecektir. Doğrulanmamış bir hesap bir yüktür — kaynakları işgal eder, kullanıcı sayılarınızı çöp verilerle şişirir ve e-posta etkileşimi gerektirmeyen özellikleri kötüye kullanmak için kullanılabilir. E-posta doğrulaması istemek, toplu hesap oluşturmanın maliyetini çoğu gündelik istismarı caydıracak kadar artırır.

Üçüncü neden, geliştiricilerin en sık hafife aldığı nedendir: doğrulanmış bir e-posta adresi, güvenli bir şifre sıfırlama akışının güvenlik ön koşuludur. Dikkatlice düşünün. Şifre sıfırlamalarına, o adresin hesap sahibine ait olduğunu önce doğrulamadan herhangi bir adrese izin verirseniz, bir saldırgan başkasının e-postasıyla kayıt olabilir, onu asla doğrulamaz ve yine de bir şifre sıfırlama akışını tetikleyebilir. Sıfırlama e-postası o adresin gerçek sahibine gider — bu da, bilgisi olmadan onun adına bir hesap oluşturulduğunu ortaya çıkarır. Bu en azından bir gizlilik sızıntısıdır ve potansiyel olarak daha fazla istismar için bir vektördür. OWASP Authentication Cheat Sheet bunu ve daha fazlasını kapsar — kimlik doğrulama akışları kuran herkes için zorunlu okumadır.

Ve son olarak, pratik teslimat sorusu var: kullanıcılara e-posta gönderiyorsanız — bildirimler, makbuzlar, güncellemeler — o adreslerin gerçek ve ulaşılabilir olduğunu bilmeniz gerekir. Geçersiz adreslere göndermek geri dönüş oranınızı artırır, bu da gönderen itibarınıza zarar verir, bu da gelecekteki e-postalarınızın listenizdeki herkes için spam'e düşmesi anlamına gelir. Doğrulama, tüm e-posta programınızı zaman içinde güvenilir şekilde çalıştıran temeldir.

Tam doğrulama akışı, adım adım

Doğru kurulmuş bir doğrulama sisteminin her adımını inceleyelim. Kavram basittir; değer, her adımı düzgün yapmaktadır. E-postanın kendisi iyi tanımlanmış bir aktarım protokolünü izler — RFC 5321, aktarım katmanında ne olduğunu anlamanız gerekirse SMTP'yi ayrıntılı olarak tanımlar — ancak uygulama katmanı kararları tamamen size aittir ve son derece önemlidir.

1. Kullanıcı kayıt formunu gönderir. E-posta adresini kabul edin. Temel format doğrulamasını sunucu tarafında yapın — yalnızca istemci tarafında değil. RFC 5321 aslında insanların kullandığı çoğu regex kalıbından daha esnektir, bu yüzden aşırı katı bir kalıpla geçerli adresleri reddetmeyin.
2. Kriptografik olarak rastgele bir token oluşturun. Bu bir UUID değil, sıralı bir ID değil, bir zaman damgası değil. En az 32 bayt entropi ile kriptografik bir rastgele kaynaktan gelmelidir. Bir sonraki bölümde bu konuda daha fazlası var.
3. Token hash'ini (ham token değil) veritabanınızda saklayın. Tokenin SHA-256 hash'ini, ait olduğu kullanıcı ID'sini, oluşturma zaman damgasını, sona erme zaman damgasını ve bir "kullanıldı" boolean bayrağını kaydedin.
4. Doğrulama e-postasını gönderin. Bağlantı, ham tokeni bir sorgu parametresi olarak içerir: https://yourapp.com/verify?token=abc123.... Her zaman HTTPS kullanın. Asla HTTP değil.
5. Kullanıcı bağlantıya tıklar. Sunucunuz, sorgu dizesinde ham token ile bir GET isteği alır.
6. Tokeni arayın ve doğrulayın. Gelen tokeni hash'leyin, veritabanında eşleşen kaydı bulun. Var olduğunu kontrol edin. Süresinin dolmadığını kontrol edin. "kullanıldı" bayrağının yanlış olduğunu kontrol edin.
7. Başarı durumunda: kullanıcı kaydında e-posta adresini doğrulanmış olarak işaretleyin, tokenin "kullanıldı" bayrağını doğru yapın (veya token satırını tamamen silin), ardından kullanıcının oturumunu açın veya net bir başarı mesajıyla girişe yönlendirin.
8. Hata durumunda: neyin yanlış gittiğini açıklayan belirli, eyleme geçirilebilir bir hata gösterin — süresi doldu, zaten kullanıldı veya bulunamadı — yeni bir doğrulama e-postası istemek için net bir yolla.

Her adım önemlidir. En yaygın kısayollar — sunucu tarafı doğrulamasını atlamak, zayıf token kullanmak, saklamadan önce hash'lememek, "kullanıldı" bayrağını atlamak — her biri bir saldırı sınıfı veya kullanıcı deneyimi hatası ortaya çıkarır. Her adımı doğru yapın ve üretimde gerçekten sağlam duran bir doğrulama sistemine sahip olursunuz.

Güvenli token oluşturma — doğru yol

Şaşırtıcı sayıda uygulamanın ters gittiği yer burasıdır. Gördüğüm en yaygın hata, doğrulama tokeni olarak bir UUID v4 kullanmaktır. UUID'ler veritabanı tanımlayıcıları için iyidir — benzersizdirler, çakışmaya dayanıklıdırlar — ama amaca özel güvenlik tokenleri değildirler. Bir UUID v4, iyi bilinen, kolayca tanınabilir bir formatta size 122 bit rastgelelik verir. Bu pratikte muhtemelen sorun değildir, ama neredeyse hiç ek çaba harcamadan daha iyisini yapabilirsiniz ve yapmamak için iyi bir neden yoktur.

Doğru yaklaşım, dilinizin veya çalışma zamanınızın kriptografik rastgele sayı üreticisini kullanmaktır. Node.js'te: crypto.randomBytes(32).toString('hex') — bu size 256 bit entropiyi temsil eden 64 onaltılık karakter verir. Python'da: secrets.token_urlsafe(32) — secrets modülü özellikle kriptografik token üretmek için tasarlanmıştır ve bu iş için doğru araçtır. .NET'te: System.Security.Cryptography içinden RandomNumberGenerator.GetBytes(32). Go'da: crypto/rand.Read(). OWASP Authentication Cheat Sheet, doğrulama tokenleri için en az 32 bayt (256 bit) entropi önerir. Bu seviyede, token uzayının kaba kuvvetle çözülmesi hesaplamalı olarak imkansızdır — kaç tokenin dolaşımda olduğunu görmek için doğrudan veritabanı erişimi olan iyi kaynaklara sahip bir saldırgan için bile.

Şimdi saklama sorusu: ham tokeni mi yoksa onun bir hash'ini mi saklamalısınız? Özellikle e-posta doğrulama tokenleri için tehdit modeli, bir saldırganın veritabanınıza salt okunur erişim elde etmesidir — SQL enjeksiyonu, bir yedek sızıntısı veya ele geçirilmiş bir veritabanı kimlik bilgisi yoluyla. Ham tokeni saklarsanız, token değerini okuyup herhangi bir doğrulanmamış hesap için geçerli bir doğrulama URL'si oluşturabilir. Tokenin bir SHA-256 hash'ini saklarsanız, bir veritabanı okuması kullanılabilir hiçbir şey ortaya çıkarmaz. Kalıp şudur: veritabanında SHA256(token) saklayın, e-posta bağlantısında ham tokeni gönderin. Doğrularken, gelen tokeni hash'leyin ve saklanan hash'lerle karşılaştırın. Bu, güvenlik duruşunuzu ihmal edilebilir bir performans maliyetiyle anlamlı biçimde iyileştiren küçük bir ek adımdır.

Dikkate değer bir ayrıntı daha: token karşılaştırmanızın sabit zamanlı olduğundan emin olun. Hash'lenmiş tokenleri karşılaştırırken naif bir dize eşitlik kontrolü kullanmak zamanlama saldırılarına izin verir — bir saldırgan, tahmininin kaç karakterinin eşleştiğini çıkarmak için yanıt sürelerini ölçebilir. Çoğu dil sabit zamanlı karşılaştırma işlevleri sağlar: Python'da hmac.compare_digest(), Node.js'te crypto.timingSafeEqual(). Bunları kullanın.

Token sona ermesi — ayrıntıları doğru yapmak

Yirmi dört ila kırk sekiz saat, doğrulama tokeni sona ermesi için standarttır ve çoğu uygulama için iyi bir standarttır. Gece geç saatte kayıt olan bir kullanıcının ertesi sabah e-postasını hiçbir sürtünme olmadan kontrol edebileceği kadar uzun. Çalınan veya sızdırılan bir tokenin sınırlı bir kullanışlılık penceresi olacağı kadar kısa. Bazı uygulamalar daha az sürtünmeli katılım için 72 saat kullanır — kayıt terkinin gerçek bir endişe olduğu B2C uygulamaları için makuldür. Bazı yüksek güvenlikli uygulamalar sadece bir saat kadar az kullanır. Kullanıcı bağlamınıza ve risk toleransınıza göre seçin.

Ne seçerseniz seçin, bunu e-postanın kendisinde açıkça belirtin. "Bu doğrulama bağlantısı 24 saat içinde sona erer." E-postayı hemen kontrol eden kullanıcılar fark etmeyebilir, ancak e-postayı kaydedip daha sonra geri dönen kullanıcılar fark edecektir. Bu beklentiyi e-posta gövdesinde belirlemek destek taleplerinden tasarruf sağlar. Ve bir token gerçekten süresi dolduğunda, hata mesajınızın belirli ve eyleme geçirilebilir olması gerekir — "geçersiz token" değil (bu kullanıcıya neyin yanlış gittiği hakkında hiçbir şey söylemez) ama "Bu doğrulama bağlantısının süresi dolmuş. Yenisini istemek için buraya tıklayın." O net yeniden gönderme yolu esastır.

"Zaten doğrulandı" durumunu da açıkça ele alın. Bir kullanıcı zaten kullandığı bir doğrulama bağlantısına tıklarsa, ona genel bir hata göstermeyin — bir başarı mesajı gösterin veya doğrudan uygulamaya yönlendirin. Çift tıklamış olabilir ya da adımı tamamlayıp tamamlamadığından gerçekten emin olmadan e-postayı tekrar açmış olabilir. Doğru UX, onu zarif bir şekilde içeri almaktır, hesabının gerçekten kurulup kurulmadığını merak etmesine yol açan kafa karıştırıcı bir hata sunmak değil.

Ayrıca eski doğrulanmamış hesaplara ne olduğunu düşünün. Birisi kayıt olur, asla doğrulamaz ve süreci terk ederse — o kayda ne olur? Süresiz olarak bırakmak depolama tüketir ve aynı e-posta adresinin yeniden kayıt olmasını engelleyebilir. Bekleyen doğrulanmamış hesapları yedi gün sonra kaldıran bir temizlik işi (altıncı günde bir bildirim e-postasıyla), UX ile veri hijyenini dengeleyen temiz bir çözümdür.

Doğrulama e-postasının kendisini yazmak

Doğrulama e-postası genellikle yeni bir kullanıcının hizmetinizden aldığı ilk şeydir. Ayrıntılı olması gerekmez — aslında basit ve net olmak, karmaşık ve markalanmış olmaktan önemli ölçüde daha iyidir. Konu satırı: "Lütfen e-posta adresinizi doğrulayın" veya "[App] için e-posta adresinizi onaylayın" — doğrudan, belirsizlik yok. "[App]'e Hoş Geldiniz!" değil (bu, doğrulama sonrası hoş geldin e-postasıdır). "Eylem gerekli!!!" değil (spam filtresi yemi ve kullanıcılar e-posta konularındaki agresif aciliyet diline güvenmemeye alıştırılmıştır).

Gövde yapısı: iki veya üç cümle bağlam ("Yakın zamanda [App]'te bir hesap oluşturdunuz. E-posta adresinizi doğrulamak ve kaydınızı tamamlamak için aşağıdaki düğmeye tıklayın."), büyük, açıkça etiketlenmiş bir eylem çağrısı düğmesi ("E-posta Adresini Doğrula") ve e-posta istemcileri HTML'yi işlemeyen veya güvenlik yazılımı düğmeleri kaldıran kullanıcılar için yedek olarak altında yazdırılan ham URL. Bu son nokta çoğu geliştiricinin fark ettiğinden daha önemlidir — kurumsal e-posta ortamları tıklanabilir öğeleri rutin olarak kaldırır ve kurumsal kullanıcılar mevcutsa ham URL'yi kopyalayıp yapıştırırlar.

Düz metin alternatifi isteğe bağlı değildir. Her zaman ekleyin. Bazı kurumsal e-posta sistemleri HTML'yi kaldırır ve spam filtreleri yalnızca HTML e-postalara şüpheyle bakar. Düz metin sürümünün yalnızca doğrulama URL'sinin kendi satırında olması gerekir — güzel olması gerekmez. Ayrıca: doğrulama e-postalarında URL kısaltıcıları kullanmayın. Alıcı posta sunucuları kısaltılmış bağlantıları olası kimlik avı vektörleri olarak işaretler ve kullanıcılar (haklı olarak) açıkça istemedikleri e-postalarda kısaltılmış URL'lere tıklamaya güvenmemeye alıştırılmıştır.

Gönderen yapılandırması da önemli ölçüde önemlidir. "Gönderen" adınız markanız veya uygulama adınız olmalı — ham bir e-posta adresi değil. Yanıt adresiniz destek ekibinize veya izlenen bir gelen kutusuna yönlendirmelidir. Hem gönderen hem de yanıt olarak no-reply@... kullanmaktan kaçının — bu, kullanıcılardan haber almak istemediğinizi iletir ve bazı e-posta istemcileri alıcıları no-reply adresleri konusunda uyarır. CAN-SPAM veya GDPR e-posta pazarlama düzenlemelerine tabiyseniz, fiziksel posta adresinizi de alt bilgiye ekleyin — işlemsel e-posta için bile birkaç yargı bölgesinde yasal olarak gereklidir.

Doğrulama akışınızı doğru şekilde test etme

Burası birçok geliştiricinin daha sonra kendilerine pahalıya patlayan bir kısayol aldığı yerdir. Tipik yaklaşım: doğrulama e-postasını kendi adresinize gönderin, ulaştığını onaylayın, bağlantıya bir kez tıklayın — bitti. Bu yalnızca mutlu yolu kapsar. Gerçek kullanıcıların gerçekten karşılaşacağı hata modlarının hiçbirini kapsamaz ve e-postalarınızın, tipik olarak gevşek spam filtrelemesine sahip olan ve Gmail, Outlook veya Yahoo'da ne olduğunu doğru yansıtmayabilecek kendi gelen kutunuzun dışında nasıl davrandığı hakkında hiçbir şeyi test etmez.

Doğrulama akışınızdaki her değişiklik gerçek bir gelen kutusuna gerçek bir e-posta ile test edilmelidir. Bir geçici e-posta adresi açın, kayıt formunuza kopyalayın, bir test hesabı kaydedin ve doğrulama e-postasının gerçek zamanlı olarak ulaşmasını izleyin. Bu size e-postanızın gerçekten teslim edildiğine dair kesin bir teyit verir — yalnızca sıraya alınmadığına, yalnızca gönderme sağlayıcınızın API'si tarafından kabul edilmediğine, ancak bir gelen kutusuna teslim edildiğine. Ayrıca ana gelen kutusuna mı yoksa spam'e mi ulaştığını kontrol etmenizi sağlar; bu, birim testlerinin ve API çağrı günlüklerinin size asla söyleyemeyeceği bir şeydir.

Mutlu yolun ötesinde, doğrulama akışınıza herhangi bir değişiklik göndermeden önce test etmeniz gereken belirli senaryolar şunlardır:

• Mutlu yol: yeni bir adresle kayıt olun, e-postayı birkaç saniye içinde alın, bağlantıya tıklayın, hesabın doğrulanmış olarak işaretlendiğini ve giriş yapabildiğinizi onaylayın
• Süresi dolmuş token: token sona erme zaman damgasını veritabanınızda manuel olarak geçmişe ayarlayın (veya yapılandırmada sona erme pencerenizi geçici olarak düşürün), ardından bağlantıya tıklayın — hata mesajının net, belirli olduğunu ve çalışan bir yeniden gönderme bağlantısı içerdiğini onaylayın
• Zaten kullanılmış token: doğrulamayı başarıyla tamamlayın, ardından aynı bağlantıya ikinci kez tıklayın — kafa karıştırıcı bir hata değil, zarif bir "zaten doğrulandı" mesajı gördüğünüzü veya uygulamaya yönlendirildiğinizi onaylayın
• Kurcalanmış token: URL'deki token değerini değiştirin (birkaç karakter değiştirin) — bir sunucu çökmesi veya yığın izi değil, net bir "geçersiz bağlantı" hatası gördüğünüzü onaylayın
• Var olmayan token: tamamen uydurma bir token ile bir URL oluşturun — düzgün bir "bulunamadı" hatası döndürdüğünü ve uygun şekilde günlüğe kaydettiğini onaylayın
• Yeniden gönderme akışı: yeni bir doğrulama e-postası isteyin, yeni e-postanın çalışan yeni bir bağlantıyla ulaştığını onaylayın, eski bağlantının artık çalışmadığını onaylayın (yeni bir token verildiğinde eski token geçersiz kılınmalıdır)
• Büyük/küçük harf duyarlılığı: tokenleriniz onaltılık veya base64 ise, doğrulamanızın karışık büyük/küçük harf girdisini zarifçe ele alıp almadığını test edin — bazı e-posta istemcileri URL büyük/küçük harfini değiştirir

Bir geçici e-posta gelen kutusu bu testi hızlandırır çünkü gerçek bir e-posta sağlayıcısında bir test hesabı havuzuna ihtiyaç duymadan her senaryo için yeni bir adres oluşturabilirsiniz. Ayrıca SPF ve DKIM geçti/kaldı durumunu kontrol etmek için gelen kutusundaki ham e-posta başlıklarını doğrudan inceleyebilirsiniz — teslimat sorunlarını üretim sorunları haline gelmeden önce teşhis etmek için son derece kullanışlı.

E-posta kimlik doğrulama: SPF, DKIM ve DMARC

Doğrulama e-postanız yalnızca gerçekten gelen kutusuna ulaşırsa yararlıdır. Birçok geliştirici mükemmel doğrulama mantığı yazar ve ardından e-posta kimlik doğrulamasını yapılandırmadıkları için e-postalarının doğrudan spam'e gittiğini keşfeder. Bu, uygulama düzeyinde değil, DNS düzeyinde bir yapılandırma adımıdır — ancak sistemi dağıtan geliştirici olarak kesinlikle sizin sorumluluğunuzdadır.

SPF (Sender Policy Framework), belirli posta sunucularının etki alanınız adına e-posta göndermesine yetki veren bir DNS TXT kaydıdır. Gmail, [email protected] adresinden bir e-posta aldığında, SPF kaydınızı arar ve gönderen sunucunun IP adresinin onaylı listede olup olmadığını kontrol eder. SPF olmadan, e-posta varsayılan olarak şüpheli görünür. Örnek kayıt: gönderme sağlayıcınız olarak SendGrid kullanıyorsanız v=spf1 include:sendgrid.net ~all. Her sağlayıcının belgeleri kullanılacak tam SPF include değerini belirtir.

DKIM (DomainKeys Identified Mail), giden her e-postaya kriptografik bir imza ekler ve etki alanınızdan geldiğini ve aktarım sırasında değiştirilmediğini kanıtlar. Gönderme sağlayıcınız bir anahtar çifti oluşturur ve size DNS TXT kaydı olarak eklemeniz için bir genel anahtar verir. İmzalama, yapılandırıldıktan sonra altyapılarında otomatik olarak gerçekleşir. DKIM olmadan, diğer gönderenlerin etki alanınızı taklit etmesi önemli ölçüde daha kolaydır. Yaygın sağlayıcılar için DKIM kurulumunun ayrıntılı bir açıklaması için e-posta kimlik doğrulama belgelerini kontrol edin.

DMARC ikisini birbirine bağlar ve bir e-posta SPF veya DKIM'de başarısız olduğunda alıcı sunucuların ne yapması gerektiğine dair bir politika tanımlar. p=none (yalnızca izleme) ile başlayın, alıcı sunucuların DMARC raporlama adresinize geri gönderdiği toplu raporları birkaç hafta boyunca inceleyin, ardından meşru e-postanızın her iki kontrolü de geçtiğinden emin olduğunuzda p=quarantine (spam klasörü) veya p=reject (doğrudan reddetme) durumuna geçin. SPF, DKIM ve DMARC kayıtlarınızın doğru yapılandırıldığını doğrulamak için MXToolbox kullanın — sorunları tam olarak işaretler ve neyi düzeltmeniz gerektiğini tam olarak söyler.

Yaygın hatalar — ve bunlardan nasıl kaçınılır

Üretim doğrulama sistemlerinde en sık gördüğüm hatalar, ne kadar zarar verdiklerine göre kabaca sıralanmış olarak şunlardır:

• Kullanımdan sonra tokenleri geçersiz kılmamak. Kullanılmış bir token ikinci kez tıklanabiliyor ve başarılı oluyorsa, bir mantık hatanız var demektir. Bir doğrulama URL'sini kısa süreliğine yakalayan bir saldırgan (diyelim ki, tarayıcı geçmişinden veya günlüğe kaydedilmiş bir istekten) bir hesabı farklı bir duruma yeniden doğrulayabilir. Token üzerinde her zaman bir "kullanıldı" bayrağı ayarlayın ve her doğrulama girişiminde kontrol edin.
• Doğrulama tamamlanmadan önce hoş geldiniz veya katılım e-postaları göndermek. Bir kullanıcı kayıt olur ama asla doğrulamazsa, oluşturmayı amaçlamadığı bir hesap için — ya da başkasının adresiyle oluşturmaya çalıştığı bir hesap için — katılım dizileri alacaktır. Doğrulama onaylanana kadar bu e-postaları sıraya alın.
• Yeniden gönderme uç noktasında yetersiz hız sınırlaması. Yeniden gönderme isteklerinde hız sınırlaması olmadan, herkes doğrulama yeniden gönderme uç noktanızı keyfi bir e-posta adresine spam göndermek için kullanabilir. E-posta adresi başına yeniden göndermeleri saatte üç gibi bir şeyle sınırlayın. Tüm yeniden gönderme isteklerini günlüğe kaydedin.
• Doğrulama bağlantılarını HTTP üzerinden göndermek. Her zaman HTTPS gerektirin. Bir HTTP doğrulama bağlantısı paylaşılan veya ele geçirilmiş bir ağda ele geçirilebilir ve bir saldırganın meşru kullanıcı tıklamadan önce tokeni yakalamasına izin verir. 2025'te üretim kimlik doğrulama akışlarını düz HTTP üzerinden çalıştırmak için geçerli bir neden yoktur.
• Doğrulama olaylarını günlüğe kaydetmemek. Bir üretim kullanıcısı doğrulama e-postasıyla ilgili bir sorun bildirdiğinde, günlüklere ihtiyacınız var: token ne zaman oluşturuldu, ne zaman gönderildi, e-posta teslim edildi mi, bağlantı ne zaman tıklandı (veya tıklanmadı) ve hangi IP'den. Bu veriler olmadan, üretim sorunlarını teşhis etmek tahminden ibarettir.
• E-posta sağlayıcınızın her zaman güvenilir olduğunu varsaymak. E-posta teslimi birçok nedenden dolayı başarısız olabilir — sağlayıcı kesintileri, geçici DNS sorunları, spam filtresi yanlış pozitifleri. Kullanıcıların destek ile iletişime geçmeden kendileri tetikleyebilecekleri manuel bir "doğrulama e-postasını yeniden gönder" seçeneğini her zaman sunun.
• Birden fazla amaç için aynı tokeni kullanmak. Doğrulama tokenleri, şifre sıfırlama tokenleri ve e-posta değişikliği onay tokenleri, farklı güven düzeyleri ve risk profilleri olan ayrı güvenlik bağlamlarıdır. Her amaç için ayrı sona erme politikalarıyla ayrı tokenler oluşturun.
• E-posta formatını sunucu tarafında doğrulamamak. İstemci tarafı doğrulaması bir UX kolaylığıdır. Bir güvenlik kontrolü değildir. Frontend JavaScript'inizi atlayan bir kullanıcı veya saldırgan, API'nize keyfi veri gönderebilir. Herhangi bir token oluşturmadan ve saklamadan önce e-posta formatını her zaman sunucu tarafında doğrulayın.

Gizlilik ve veri minimizasyonu üzerine bir not

E-posta doğrulaması hassas verileri saklamayı gerektirir — e-posta adresleri ve güvenlik tokenleri. Veri minimizasyonu ilkesini baştan sona uygulayın. Doğrulama tokenlerini kullanılır kullanılmaz silin — bunları saklamak için hiçbir neden yoktur. Süresi dolmuş kullanılmayan tokenleri birikmelerine izin vermek yerine düzenli bir temizlik programında silin. Bir kullanıcı kayıt olur ama asla doğrulamazsa, e-posta adresini süresiz olarak saklamak yerine bekleyen hesabını makul bir süre sonra (yedi gün yaygın bir seçimdir) kaldırın.

Electronic Frontier Foundation, veri minimizasyonu ilkeleri ve daha az veri tutmanın neden daha iyi bir güvenlik uygulaması olduğu konusunda yararlı bir bağlam sağlar — tutmadığınız veriler ihlal edilemez. Ve ihlaller konusunda: topladığınız e-posta adresi zaten bilinen bir veri ihlalinde mi? Have I Been Pwned API'si ticari olmayan kullanım için ücretsizdir ve dolandırıcılık tespitinde yararlı bir sinyal olarak hizmet edebilir — onlarca ihlalde görünen bir adres, kayıt sırasında ek incelemeyi hak edebilir.

Hepsini bir araya getirmek

E-posta doğrulaması, bir öğreticide önemsiz görünen ve onu üretim için kurduğunuzda gerçek bir derinliğe sahip olan özelliklerden biridir. Kriptografik olarak güvenli token oluşturma, hash tabanlı saklama, sabit zamanlı karşılaştırma, mantıklı sona erme, açık kullanıldı bayrağı geçersiz kılma, net ve belirli hata mesajları, kapsamlı çok senaryolu test ve doğru e-posta kimlik doğrulama yapılandırması — her biri ayrı bir konudur ve hepsini doğru yapmak, üretim kalitesinde bir sistemi kırılgan bir sistemden ayıran şeydir.

İyi haber şu ki, bir kez doğru şekilde kurduğunuzda, sağlam, yeniden kullanılabilir bir kalıbınız olur. Kriptografik token oluşturma, hash tabanlı saklama ve zamana bağlı doğrulama, şifre sıfırlama akışlarına, iki faktörlü kimlik doğrulama cihaz kaydına ve e-posta değişikliği onayına eşit ölçüde uygulanır. Doğrulama sistemini iyi kurun ve aynı kalıp, kimlik doğrulama uygulamanızın geri kalanı boyunca temiz bir şekilde taşınır. Uygulamanızı periyodik olarak OWASP yönergelerine karşı kontrol edin — tehdit ortamı gelişir, güvenlik önerileri güncellenir ve güncel kalmak, zaman içinde dayanan yazılım kurmanın bir parçasıdır.