Web Geliştiriciler İçin Güvenli Kodlama Kontrol Listesi

SQL enjeksiyonu, XSS, komut enjeksiyonu gibi enjeksiyon saldırılarının büyük çoğunluğu, uygulamaların kullanıcı tarafından sağlanan verilere güvenmesi nedeniyle başarılı olur. Uygulamanıza giren her şeyi doğrulayın ve çıkan her şeyi kodlayın.

• Tüm kullanıcı girişlerini sunucu tarafında doğrulayın; yalnızca istemci tarafı doğrulamaya güvenmeyin.
• İzin listesi (allowlist) yaklaşımı kullanın: her giriş alanı için hangi karakterlerin, biçimlerin ve uzunlukların kabul edilebilir olduğunu tam olarak tanımlayın.
• Uyumsuz girişleri reddedin veya temizleyin; hatalı biçimlendirilmiş veriyi sessizce düzeltmeye çalışmayın.
• Her veritabanı işlemi için parametreli sorgular veya hazırlıklı ifadeler kullanın; kullanıcı girişini asla SQL dizelerine birleştirmeyin.
• Tüm çıkışları doğru bağlam için kodlayın: HTML çıkışı için HTML-encode, betik bağlamı için JavaScript-encode, sorgu parametreleri için URL-encode uygulayın.
• Şablon motorunuzda bağlama duyarlı çıkış kodlaması uygulayın; otomatik kaçışı yalnızca içeriği tam olarak kontrol ettiğinizde devre dışı bırakın.
• Sisteminizin dışından gelen veriler (örn. üçüncü taraf API'leri, webhook'lar) için dosya adlarını, MIME türlerini ve içeriği doğrulayın.
• Katı tür denetimi uygulayın — girişleri beklenen veri türüne mümkün olduğunca erken dönüştürün.

Zayıf kimlik doğrulama, veri ihlallerinin önde gelen nedenlerinden biridir. Hesap ele geçirme ve oturum kaçırma saldırılarını önlemek için güçlü kimlik bilgisi yönetimi ve oturum kontrolleri uygulayın.

• Güçlü bir parola politikası uygulayın: minimum 12 karakter, karakter türlerinin karışımı ve bilinen sızdırılmış parola listelerine karşı kontrol (örn. HaveIBeenPwned API kullanarak).
• Parolaları modern, yavaş bir hash algoritmasıyla saklayın: uygun bir maliyet faktörüyle bcrypt, Argon2id veya scrypt — asla MD5 veya SHA-1 kullanmayın.
• Çok Faktörlü Kimlik Doğrulama (MFA) uygulayın — en azından TOTP tabanlı MFA sunun; ayrıcalıklı hesaplar için zorunlu kılın.
• Kriptografik olarak güvenli bir rastgele sayı üreteci (CSPRNG) ile oturum belirteçleri oluşturun ve en az 128 bit uzunluğunda yapın.
• Başarılı bir girişin hemen ardından oturum kimliğini yenileyin (oturum sabitleme saldırısını önleyin).
• Oturum çerezlerini HttpOnly, Secure ve SameSite=Strict (veya Lax) bayraklarıyla ayarlayın.
• Mutlak ve boşta oturum zaman aşımları uygulayın; tanımlı bir hareketsizlik süresinin ardından kullanıcıları oturumdan çıkarın.
• Kaba kuvvet saldırılarını önlemek için giriş uç noktalarına hız sınırlama ve hesap kilitleme (veya CAPTCHA) uygulayın.
• Çıkışın, oturum belirtecini yalnızca istemci tarafında değil sunucu tarafında da geçersiz kıldığından emin olun.
• Zamanlama saldırılarını önlemek için belirteçleri, hash'leri veya sırları doğrularken sabit zamanlı karşılaştırma işlevleri kullanın.

Kimlik doğrulama bir kullanıcının kim olduğunu kanıtlar; yetkilendirme ise ne yapabileceklerini belirler. Bozuk erişim kontrolü, web uygulamalarında sürekli olarak en önemli güvenlik açıklarından biri olmaya devam etmektedir — her istekte titizlikle uygulayın.

• En az ayrıcalık ilkesini uygulayın: her kullanıcı, hizmet hesabı ve süreç yalnızca gereken minimum izinlere sahip olmalıdır.
• Hassas her eylem için sunucu tarafında yetkilendirme kontrolleri gerçekleştirin — istemci tarafındaki rol veya izin değerlerine asla güvenmeyin.
• Merkezi, denetlenebilir bir kütüphane veya modül kullanarak rol tabanlı erişim kontrolü (RBAC) veya öznitelik tabanlı erişim kontrolü (ABAC) uygulayın.
• Varsayılan olarak erişimi reddedin; açıkça reddedilmek yerine açıkça izin verin.
• Kullanıcıların yalnızca kendi kaynaklarına erişebildiğini doğrulayın (Güvensiz Doğrudan Nesne Referansını — IDOR'u önleyin): her veri alımında sahipliği kontrol edin.
• Yönetimsel uç noktaları ve sayfaları ayrı, daha katı erişim kontrolleriyle koruyun — gizliliğe güvenmeyin.
• Adli inceleme için yeterli bağlamla (kullanıcı kimliği, kaynak, zaman damgası) her başarısız yetkilendirme girişimini günlüğe kaydedin.
• Özellikler değiştirildiğinde veya yeni roller eklendiğinde her kod incelemesinde erişim kontrolü mantığını gözden geçirin.

Hassas veriler hem beklerken hem de iletim sırasında korunmalıdır. Zayıf veya güncelliğini yitirmiş kriptografik algoritmalar kullanmak, hiç kullanmamak kadar tehlikelidir.

• Uygulamanın tamamında HTTPS'yi (minimum TLS 1.2, tercihen TLS 1.3) zorunlu kılın — Sensagraph, TLS yapılandırmanızı ve sertifika geçerliliğinizi otomatik olarak denetler.
• Eski protokolleri devre dışı bırakın: SSL 2/3, TLS 1.0, TLS 1.1.
• Güçlü, modern şifre paketleri kullanın; RC4, DES, 3DES ve ihracat sınıfı şifreleri devre dışı bırakın.
• Bekleyen hassas verilerin simetrik şifrelemesi için AES-256-GCM veya ChaCha20-Poly1305 kullanın.
• Asla kendi kriptografinizi geliştirmeyin — iyi bakımlı, eş gözden geçirmeli kütüphaneler kullanın.
• Şifreleme anahtarlarını CSPRNG ile oluşturun ve korudukları verilerden ayrı yerlerde saklayın (örn. gizli yöneticisi veya donanım güvenlik modülü).
• Anahtar rotasyon politikaları uygulayın ve acil anahtar iptal sürecini belgeleyin.
• Hassas verileri (KBB, ödeme verileri, sağlık verileri) tanımlayıp sınıflandırın ve depolandığı veya iletildiği her yerde şifrelendiğinden emin olun.
• İhtiyaç duymadığınız hassas verileri depolamaktan kaçının — veri ayak izinizi minimumda tutun.
• Uzun bir max-age değeriyle HSTS (HTTP Strict Transport Security) kullanın; includeSubDomains ve preload yönergelerini ekleyin.

Yetersiz hata yönetimi, uygulamanızın iç yapısını saldırganlara ifşa eder. Yetersiz günlükleme ise bir saldırı gerçekleştiğini hasar oluşana kadar fark edemeyeceğiniz anlamına gelir.

• Son kullanıcılara genel, kullanıcı dostu hata mesajları gösterin — yığın izlerini, veritabanı hatalarını veya dahili yolları asla ifşa etmeyin.
• Ayrıntılı hata bilgilerini yalnızca yetkili personelin erişebildiği sunucu tarafında günlüğe kaydedin.
• İşlenmemiş hataları yakalamak ve yanlışlıkla bilgi ifşasını önlemek için genel bir istisna işleyicisi uygulayın.
• Tüm güvenlikle ilgili olayları günlüğe kaydedin: giriş denemeleri (başarılı ve başarısız), ayrıcalık yükseltme, parola değişiklikleri, erişim kontrolü hataları ve veri dışa aktarımları.
• Günlüklere bağlamsal veri ekleyin: zaman damgası (UTC), kullanıcı kimliği, IP adresi, istek yolu ve sonuç — ancak parolaları, belirteçleri veya tam kredi kartı numaralarını asla günlüğe kaydetmeyin.
• Günlük dosyalarını kurcalamaya karşı koruyun: salt ekleme depolama kullanın, günlükleri merkezi bir SIEM'e gönderin ve yazma erişimini kısıtlayın.
• Anormal örüntüler için gerçek zamanlı uyarı kurun (örn. yüksek hata oranları, olağandışı erişim süreleri, tekrarlanan yetkilendirme hataları).
• Uyumluluk gereksinimlerinizi karşılayan bir süre boyunca günlükleri saklayın (tipik olarak minimum 90 gün, genellikle 1 yıl).

Modern web uygulamaları onlarca veya yüzlerce üçüncü taraf pakete bağlıdır. Herhangi bir bağımlılıktaki güvenlik açığı, uygulamanızdaki bir güvenlik açığıdır.

• Tüm doğrudan ve geçişli bağımlılıkların doğru bir envanterini (Yazılım Malzeme Listesi — SBOM) tutun.
• Bir bağımlılık güvenlik açığı tarayıcısı (örn. npm audit, pip-audit, Dependabot, Snyk) kullanın ve bunu CI/CD boru hattınıza entegre edin.
• Bağımlılık sürümlerini kilit dosyalarında (package-lock.json, Pipfile.lock, composer.lock) sabitleyin ve bunları kaynak kontrolüne dahil edin.
• Kütüphaneleri benimsemeden önce güvenlik geçmişlerini ve bakım etkinliklerini inceleyin.
• Kullanılmayan bağımlılıkları hemen kaldırın — her kullanılmayan paket gereksiz saldırı yüzeyidir.
• Temel bağımlılıklarınız için güvenlik danışmalarına abone olun (GitHub Güvenlik Danışmaları, posta listeleri, CVE akışları).
• Paket kayıt defterinin desteklediği durumlarda paket bütünlüğünü sağlama toplamları veya imzalar kullanarak doğrulayın.
• Güvenilmeyen paketlerin paket yükleme betiklerini (postinstall kancaları) çalıştırmaktan kaçının.

HTTP güvenlik başlıkları, saldırı yüzeyinizi azaltmanın hızlı ve yüksek etkili bir yoludur. Yanlış yapılandırılmış veya eksik başlıklar, güvenlik değerlendirmelerinde yaygın bir bulgu olmaya devam etmektedir — Sensagraph her taramada tüm büyük güvenlik başlıklarını denetler.

• Betiklerin, stillerin, görüntülerin ve diğer kaynakların kaynaklarını kısıtlamak için Content-Security-Policy (CSP) belirleyin; 'unsafe-inline' yerine nonces veya hash'ler kullanın.
• MIME türü koklama saldırılarını önlemek için X-Content-Type-Options: nosniff ayarlayın.
• Clickjacking'i önlemek için X-Frame-Options: DENY ayarlayın (veya CSP'nin frame-ancestors yönergesini kullanın).
• Referrer veri sızıntısını kontrol etmek için Referrer-Policy: strict-origin-when-cross-origin (veya daha katı) belirleyin.
• Uygulamanızın kullanmadığı tarayıcı özelliklerini (kamera, mikrofon, coğrafi konum vb.) devre dışı bırakmak için Permissions-Policy belirleyin.
• En az 31536000 (bir yıl) max-age değeriyle HSTS'yi etkinleştirin, includeSubDomains ekleyin ve preload seçeneğini değerlendirin.
• Parmak izi maruziyetini azaltmak için sunucu sürüm başlıklarını (Server, X-Powered-By) kaldırın veya gizleyin.
• CORS'u (Çapraz Kaynak Kaynak Paylaşımı) yalnızca belirli, güvenilir kaynaklara izin verecek şekilde yapılandırın — kimliği doğrulanmış uç noktalar için asla joker karakter (*) kullanmayın.

API'ler genellikle web arayüzlerinden daha az görünürdür ancak aynı ölçüde — hatta daha fazla — saldırıya açıktır. Her API uç noktası potansiyel bir saldırı vektörü olarak ele alınmalıdır.

• Her API isteğini güvenli bir mekanizma kullanarak doğrulayın (kısa ömürlü belirteçlerle OAuth 2.0, katı kapsama sahip API anahtarları veya karşılıklı TLS).
• API anahtarlarını veya sırlarını asla istemci tarafı koduna, mobil uygulama ikili dosyalarına veya genel depolara yerleştirmeyin.
• Tüm API istek parametrelerini, başlıklarını ve gövdelerini doğrulayıp temizleyin — web formları için geçerli olan giriş doğrulama kurallarının aynısını uygulayın.
• İstismarı, kazımayı ve DoS saldırılarını önlemek için tüm API uç noktalarında hız sınırlama ve kısıtlama uygulayın.
• Yalnızca istemcinin ihtiyaç duyduğu verileri döndürün — gereksiz alanları ortaya çıkaran aşırı veri içeren yanıtlardan kaçının.
• API'nizi sürümlendirin ve eski sürümleri güvenli şekilde kullanım dışı bırakın; belgelenmemiş eski uç noktaların süresiz çalışmasına izin vermeyin.
• İstek ve yanıt yüklerini doğrulamak için JSON Schema veya eşdeğerini kullanın.
• Tüm API uç noktalarının yetkilendirme kontrolleriniz kapsamında olduğundan emin olun — toplu işlemlere ve yığın uç noktalarına özellikle dikkat edin.
• Nesne düzeyinde ve alan düzeyinde yetkilendirme uygulayın (API'lerde BOLA/IDOR'u önleyin).

Dosya yükleme işlevi, web kabuğu, kötü amaçlı yazılım veya uygulamanızı çökertecek büyük boyutlu yükler yüklemeye çalışan saldırganlar için yaygın bir hedef haline gelmiştir.

• Dosya türünü hem dosya içeriğinden MIME türü algılaması (magic bytes) hem de dosya uzantısı kullanarak doğrulayın — yalnızca Content-Type başlığına güvenmeyin.
• İzin verilen dosya uzantıları ve MIME türleri için bir izin listesi tutun; diğer her şeyi reddedin.
• Dosya boyutunu sunucu tarafında sınırlandırın ve limit aşıldığında açık bir hata döndürün.
• Yol geçişi ve dosya adı tabanlı saldırıları önlemek için yüklenen dosyaları depolamadan önce rastgele oluşturulmuş bir adla yeniden adlandırın.
• Yüklenen dosyaları URL aracılığıyla doğrudan erişilemeyen, web kökünün dışında bir konumda saklayın.
• Kullanıcı tarafından yüklenen dosyaları doğrudan sunmak yerine uygun başlıkları (Content-Disposition: attachment, doğru MIME türü) belirleyen özel bir işleyici aracılığıyla sunun.
• Yüklenen dosyaları işlemeden veya depolamadan önce antivirüs veya kötü amaçlı yazılım tespitiyle tarayın.
• Resimler kabul ediliyorsa, gömülü kötü amaçlı içeriği temizlemek için güvenilir bir görüntü işleme kütüphanesi aracılığıyla yeniden kodlayın.

Güvenlik, geliştirmenin sonunda eklenemez — yazılım geliştirme yaşam döngünüz (SDLC) boyunca gömülü olmalıdır. Sürekli test ve disiplinli kod incelemesi, üretime geçmeden önceki son savunma hattınızdır.

• Her çekme isteği için güvenlik odaklı kod incelemeleri yapın; inceleme şablonunuzun bir parçası olarak güvenlik kontrol listesi kullanın.
• Kod işlendikçe güvenlik açıklarını otomatik olarak yakalamak için CI boru hattınıza Statik Uygulama Güvenliği Testi (SAST) entegre edin.
• Hazırlama ortamlarına karşı Dinamik Uygulama Güvenliği Testi (DAST) çalıştırın; Sensagraph, canlı uygulamanızı istismar edilebilir güvenlik açıklarına karşı sürekli tarar.
• Yılda en az bir kez veya önemli mimari değişikliklerden sonra manuel sızma testi gerçekleştirin.
• Herhangi bir kod yazmadan önce güvenlik risklerini belirlemek ve gidermek için tasarım aşamasında tehdit modellemesi (örn. STRIDE) kullanın.
• Harici araştırmacılardan raporlar almak için sorumlu ifşa / hata ödül politikası oluşturun ve takip edin.
• Geliştiricileri güvenli kodlama uygulamaları konusunda düzenli olarak — yılda en az bir kez veya yeni bir teknoloji yığını benimsendiğinde — eğitin.
• Tanımlanan tüm güvenlik açıklarını kapsam derecelendirmeleri ve SLA odaklı giderme son tarihleriyle birlikte sorun izleyicinizde takip edin.
• Kimlik doğrulama, veri işleme veya erişim kontrolünü etkileyen her kullanıcı hikayesi veya biletine güvenlik kabul kriterlerini dahil edin.