Yayına Almadan Önce Güvenlik Kontrol Listesi

Şifrelenmemiş HTTP trafiği, sunucunuz ile kullanıcılarınız arasındaki ağ yolu üzerindeki herhangi biri tarafından ele geçirilebilir, değiştirilebilir veya içine kod enjekte edilebilir. Her production uygulaması, tüm içeriği yalnızca geçerli ve güvenilir bir TLS sertifikasıyla HTTPS üzerinden sunmalıdır.

• Güvenilir bir Sertifika Otoritesinden (CA) geçerli bir TLS sertifikası edinin ve yükleyin — Let's Encrypt ücretsiz ve otomatik yenilenen sertifikalar sunar.
• Tüm HTTP isteklerini (port 80) kalıcı olarak 301 yönlendirmesiyle HTTPS'ye (port 443) yönlendirerek HTTPS'yi zorunlu kılın.
• Eski TLS sürümlerini (TLS 1.0 ve TLS 1.1) devre dışı bırakın; yalnızca TLS 1.2 ve TLS 1.3'ü kabul edin.
• Sunucu yapılandırmanızdan zayıf ve kullanımdan kaldırılmış şifre takımlarını kaldırın; AEAD şifrelerini (örn. AES-GCM, ChaCha20-Poly1305) tercih edin.
• Sertifika iptal kontrollerini hızlandırmak için web sunucunuzda OCSP zımbalamayı etkinleştirin.
• Sertifikanızın kullanımdaki tüm alt alan adlarını kapsadığını doğrulayın (gerektiğinde wildcard veya SAN sertifikası kullanın).
• Planlanmamış kesinti sürelerini önlemek için sertifika süresinin dolmasından en az 30 gün önce hatırlatıcı ayarlayın. Sensagraph, sertifika geçerliliğinizi sürekli izler ve süresi dolmadan önce sizi uyarır.

HTTP yanıt başlıkları, web güvenliğinde en hızlı kazanımlardan biridir. Doğru yapılandırılmış başlıklar, tarayıcıya; çoğunlukla tek bir satır sunucu yapılandırmasıyla cross-site scripting (XSS), clickjacking, MIME sniffing ve veri sızıntısını azaltan politikaları uygulamasını söyler. Sensagraph, her taramada tüm önemli güvenlik başlıklarını otomatik olarak kontrol eder.

• Strict-Transport-Security (HSTS): HTTPS'yi tarayıcı düzeyinde zorunlu kılmak için Strict-Transport-Security: max-age=31536000; includeSubDomains; preload ayarlayın.
• Content-Security-Policy (CSP): Uygulamanızın meşru olarak script, stil, resim ve yazı tipi yüklediği kaynakları kapsayan katı bir CSP tanımlayın. Mümkün olduğunda unsafe-inline ve unsafe-eval kullanmaktan kaçının.
• X-Frame-Options: Sayfalarınızın üçüncü taraf iframe'lere gömülmesini engelleyerek clickjacking saldırılarını önlemek için DENY veya SAMEORIGIN olarak ayarlayın.
• X-Content-Type-Options: Tarayıcıların yanıtları beyan edilen içerik türünden farklı MIME türlerine dönüştürmesini önlemek için nosniff olarak ayarlayın.
• Referrer-Policy: İsteklerle birlikte ne kadar referrer bilgisi gönderileceğini kontrol etmek için strict-origin-when-cross-origin veya daha katı bir değer ayarlayın.
• Permissions-Policy: Uygulamanızın kullanmadığı tarayıcı özelliklerine (kamera, mikrofon, konum) erişimi kısıtlayın.
• Web sunucunuzun yazılımını ve sürümünü açığa çıkaran sunucu banner başlıklarını (örn. Server, X-Powered-By) kaldırın veya gizleyin.

Zayıf kimlik doğrulama, saldırganlar için en yaygın giriş noktasıdır. Yayın öncesinde her kimlik doğrulama mekanizmasının doğru uygulandığını ve oturumların ele geçirilemez veya taklit edilemez olduğunu doğrulayın.

• Şifreleri güçlü, yavaş bir hashing algoritmasıyla saklayın: bcrypt, scrypt veya Argon2. Şifreler için MD5, SHA-1 veya tuzsuz SHA-256 asla kullanmayın.
• En az 12 karakter uzunluğunda bir minimum şifre uzunluğu belirleyin ve yeni şifreleri bilinen ihlal edilmiş şifre listeleriyle karşılaştırın (örn. Have I Been Pwned API kullanarak).
• Tüm yönetici hesapları için çok faktörlü kimlik doğrulamayı (MFA) zorunlu kılın ve normal kullanıcılara seçenek olarak sunun.
• Oturum çerezlerini HttpOnly, Secure ve SameSite=Lax (veya Strict) nitelikleriyle ayarlayın.
• Oturum sabitleme saldırılarını önlemek için başarılı girişten sonra oturum kimliğini yenileyin.
• Hassas uygulamalar için makul bir oturum zaman aşımı (örn. 15-30 dakika hareketsizlik) belirleyin ve sunucu tarafındaki oturumu tamamen geçersiz kılan bir çıkış işlevi sağlayın.
• Kaba kuvvet saldırılarına karşı direnmek için tekrarlanan başarısız giriş denemelerinden sonra hesap kilitleme veya aşamalı gecikmeler uygulayın.
• Şifre sıfırlama akışlarının güvenlik sorularına değil, doğrulanmış bir e-posta adresine gönderilen kısa ömürlü, tek kullanımlık tokenlar kullandığından emin olun.
• CSRF tokenları ile tüm kimlik doğrulama uç noktalarını koruyun veya birincil CSRF savunması olarak SameSite çerez niteliğini kullanın.

Injection açıkları — SQL injection, komut injection, XSS, XML injection ve diğerleri — web uygulamalarındaki en tehlikeli ve yaygın zayıflıklar arasında olmaya devam etmektedir. Uygulamanıza dışarıdan giren her veri güvenilmez olarak ele alınmalıdır.

• Her veritabanı etkileşimi için parametreli sorgular veya hazırlanmış ifadeler kullanın — kullanıcı girişini asla doğrudan SQL dizelerine birleştirmeyin.
• Mümkün olduğunda ham sorgu oluşturma yerine ORM'nin yerleşik sorgu oluşturma yöntemlerini kullanın.
• Sunucu tarafında tip, uzunluk, biçim ve aralık için girişleri doğrulayın — istemci tarafı doğrulama bir UX aracıdır, güvenlik kontrolü değil.
• XSS'yi önlemek için kullanıcı tarafından sağlanan tüm çıktıları HTML, JavaScript, CSS veya URL bağlamlarında render etmeden önce kodlayın.
• Kullanıcılardan zengin HTML kabul etmeniz gerekiyorsa blocklist yerine allowlist tabanlı bir HTML sanitizasyon kütüphanesi kullanın (örn. DOMPurify).
• Dosya yükleme türlerini, boyutlarını ve depolama konumlarını doğrulayıp kısıtlayın; yüklenen dosyaları asla çalıştırmayın veya web root içinde saklamayın.
• Kabuk komutlarında, LDAP sorgularında, XPath sorgularında ve diğer yapılandırılmış yorumlayıcılarda kullanılan verileri sanitize edin.

Bozuk erişim kontrolü, sürekli olarak en önemli web uygulaması güvenlik açığı olarak sıralanmaktadır. Uygulamanızdaki her işlem açık, sunucu tarafında uygulanan bir yetkilendirme kontrolüyle yönetilmelidir — asla yalnızca belirsizliğe veya istemci tarafı kontrollere güvenmeyin.

• En az ayrıcalık ilkesini uygulayın: kullanıcılar, servisler ve işlemler yalnızca gerçekten ihtiyaç duydukları izinlere sahip olmalıdır.
• API rotaları dahil her sunucu tarafı uç noktasında yetkilendirme kontrollerini uygulayın — bir rotanın UI'da bağlantısı olmadığı için güvenli olduğunu varsaymayın.
• Güvensiz Doğrudan Nesne Referansı (IDOR) saldırıları riskini azaltmak için sıralı veritabanı kimlikleri yerine dolaylı nesne referansları (örn. UUID'ler, opak tokenlar) kullanın.
• Yönetim arayüzlerini belirli IP aralıklarıyla veya bir VPN ile kısıtlayın ve bunları asla genel internette açıkta bırakmayın.
• Rol tabanlı erişim kontrolü (RBAC) veya nitelik tabanlı erişim kontrolü (ABAC) uygulayın ve yayın öncesinde her rolün izinlerini test edin.
• Varsayılan olarak erişimi reddedin: bir kullanıcının bir kaynağa yetkisi olumlu olarak doğrulanamıyorsa isteği reddedin.
• Web sunucunuzda dizin listelemenin devre dışı olduğunu doğrulayın, böylece dosya ve dizin yapıları kamuya açık olarak taranamaz.

Geliştirme ortamları; geliştirme sürecinde çok değerli olan ancak production'da yıkıcı olabilen gizli bilgiler, ayrıntılı hata mesajları ve debug araçları biriktirir. Tek bir açık yığın izleme veya hardcoded API anahtarı, saldırgana ihtiyaç duyduğu her şeyi verebilir.

• Uygulama framework'ünüzde debug modunu devre dışı bırakın (örn. Django'da DEBUG=False, Flask'ta app.debug = False).
• Production ortamında ayrıntılı hata sayfalarını genel, kullanıcı dostu hata mesajlarıyla değiştirin; tam yığın izlerini yalnızca sunucu tarafında loglayın.
• Kaynak kodundan tüm hardcoded kimlik bilgilerini, API anahtarlarını, tokenları ve gizli bilgileri kaldırın; bunları ortam değişkenlerinde veya bir gizli bilgi yöneticisinde (örn. HashiCorp Vault, AWS Secrets Manager) saklayın.
• Yanlışlıkla commit edilmiş gizli bilgiler için git-secrets veya truffleHog gibi araçları kullanarak depo geçmişinizi denetleyin ve ifşa olan kimlik bilgilerini hemen değiştirin.
• Yalnızca geliştirme ortamına ait rotaları, yönetici arka kapılarını ve test hesaplarını production'a dağıtmadan önce kaldırın.
• .env dosyalarınızın, yapılandırma dosyalarınızın ve gizli bilgi içeren dosyaların .gitignore aracılığıyla versiyon kontrolünden hariç tutulduğundan emin olun.
• Yedek dosyaların, kaynak arşivlerinin ve editör swap dosyalarının (örn. .bak, .swp, ~) web root'tan erişilebilir olmadığını kontrol edin.

Modern uygulamalar açık kaynak kütüphanelere ve paketlere yoğun biçimde dayanmaktadır. Dahil ettiğiniz her bağımlılık saldırı yüzeyinizi genişletir — tek bir bakımsız kütüphanedeki güvenlik açığı tüm uygulamanızı tehlikeye atabilir. Sensagraph, sitenizde tespit edilen teknolojilerdeki kamuya açık bilinen güvenlik açıklarını ortaya çıkarır.

• Paket yöneticinizin yerleşik aracını kullanarak bağımlılık denetimi gerçekleştirin (npm audit, pip-audit, bundler-audit, composer audit vb.) ve tüm kritik ve yüksek önem dereceli bulguları giderin.
• Tekrarlanabilir yapılar sağlamak için lockfile'daki bağımlılık sürümlerini sabitleyin ve lockfile'ı versiyon kontrolüne ekleyin.
• Kullanılmayan bağımlılıkları tamamen kaldırın — her ekstra paket ek saldırı yüzeyi ve bakım yükü demektir.
• Başlıca bağımlılıklarınız için güvenlik danışmalarına abone olun (GitHub Dependabot, OSS Index veya benzeri).
• Kriptografi, kimlik doğrulama ve girdi ayrıştırma gibi güvenlik açısından kritik işlevler için belirsiz kütüphaneler yerine iyi bakımlı ve yaygın olarak kullanılan kütüphaneleri tercih edin.
• Paket imzalama veya sağlama toplamı doğrulaması kullanarak mümkün olan yerlerde paketlerin bütünlüğünü doğrulayın.

Mükemmel yazılmış bir uygulama bile kötü yapılandırılmış bir sunucu nedeniyle ele geçirilebilir. Uygulamanız canlıya gitmeden önce temel altyapıyı sertleştirin ve her katmanda saldırı yüzeyini en aza indirin.

• Bir güvenlik duvarı (örn. UFW, iptables veya bir bulut güvenlik grubu) kullanarak uygulamanın çalışması için gerekli olmayan tüm portları kapatın. Yalnızca 80 ve 443 portlarını genel internete açın.
• SSH üzerinden uzak root girişini devre dışı bırakın; yalnızca anahtar tabanlı kimlik doğrulama kullanın ve şifre tabanlı SSH girişini devre dışı bırakın.
• İşletim sistemini ve yüklü tüm paketleri güvenlik yamaları ile güncel tutun; pratik olduğu yerlerde otomatik güvenlik güncellemelerini etkinleştirin.
• Web uygulaması sürecinizi hiçbir zaman root olarak değil, ayrılmış ve ayrıcalıksız bir kullanıcı olarak çalıştırın.
• Web sunucunuzu sürüm başlıklarını gizleyecek şekilde yapılandırın (örn. Apache'de ServerTokens Prod, Nginx'te server_tokens off).
• Saldırı yüzeyini azaltmak için kullanılmayan web sunucusu modüllerini ve özelliklerini devre dışı bırakın (örn. WebDAV, dizin listeleme, sunucu tarafı include'lar).
• Kaba kuvvet ve hizmet dışı bırakma girişimlerini azaltmak için tüm kamuya açık uç noktalarda hız sınırlaması uygulayın.
• Yaygın saldırı modellerini filtrelemek için uygulamanızın önüne bir Web Uygulama Güvenlik Duvarı (WAF) yerleştirin.
• Veritabanı sunucularının, önbelleklerin ve dahili servislerin genel internetten doğrudan erişilebilir olmadığından emin olun; bunları özel bir ağa yerleştirin.

Göremediğinize yanıt veremezsiniz. Kapsamlı loglama ve gerçek zamanlı izleme; devam eden saldırıları tespit etmek, olayları sonradan araştırmak ve uyumluluk yükümlülüklerini karşılamak için vazgeçilmezdir. Bunları ilk ihlalden sonra değil, canlıya gitmeden önce kurun.

• Tüm kimlik doğrulama olaylarını loglayın: başarılı girişler, başarısız girişler, şifre sıfırlamaları ve MFA denemeleri — zaman damgalarını ve kaynak IP adreslerini dahil edin.
• Tüm erişim kontrolü başarısızlıklarını (403 yanıtları) ve beklenmeyen uygulama hatalarını (500 yanıtları) loglayın.
• Logları, web sunucusunu ele geçiren bir saldırganın loglarla oynamasını önlemek için uygulama sunucusundan ayrı, merkezi ve yazma korumalı bir konumda saklayın.
• Anormal kalıplar için gerçek zamanlı uyarılar ayarlayın: tekrarlanan başarısız girişler, trafikteki olağandışı artışlar, hassas uç noktalara erişim veya beklenmeyen IP aralıklarından gelen hatalar.
• Şifreler, tam kredi kartı numaraları, oturum tokenları veya kişisel veriler gibi hassas verileri düz metin olarak loglamayın.
• Bir uyarı tetiklendiğinde ekibinizin ne yapacağını bilmesi için yayın öncesinde bir olay müdahale planı tanımlayın ve test edin.
• Yasal düzenleyici yükümlülüklerinizi karşılayan bir log saklama politikası belirleyin (örn. pek çok uyumluluk çerçevesi için minimum 90 gün).

Manuel kontrol listeleri çok şeyi yakalar; ancak otomatik tarama, tüm uygulama yüzeyinizde sistematik ve tekrarlanabilir bir kapsam sağlar — yayın öncesi baskı altında gözden kaçması kolay güvenlik açıklarını bulur. Bu, her production sürümünden önce son kapı olmalıdır.

• Son sürümü dağıtmadan önce, production'a mümkün olduğunca yakın olması gereken staging veya pre-production ortamınızı tarayın.
• Taramadan gelen tüm bulguları inceleyin, önem derecesine göre sıralayın ve kritik ile yüksek önem dereceli bulguları yayın öncesinde giderin — bunları "yayın sonrası teknik borç" olarak ertelemeyin.
• Uygulamanızın /.git, /.env, /admin, yedek arşivler veya yalnızca dahili kullanım için tasarlanmış API belgeleri gibi hassas yolları açığa çıkarmadığını kontrol edin.
• 404, 403 ve 500 yanıtları için hata sayfalarının teknoloji yığını bilgilerini sızdırmadığını doğrulayın.
• Tüm uç noktaların doğru HTTP yöntemlerini kullandığını ve beklenmedik olanları reddettiğini doğrulayın (örn. bir giriş uç noktası PUT veya DELETE kabul etmemelidir).
• Yayın sonrasında otomatik taramaların düzenli olarak çalışmasını planlayın — güvenlik tek seferlik bir olay değildir. Sensagraph, canlı sitenizi sürekli izler ve yeni sorunlar keşfedildikçe sizi uyarır.