Web Uygulama Güvenliği: İşletmenizi Koruyan 10 Temel Pratik

Bir web uygulaması veya SaaS ürünü geliştiriyorsunuz ya da mevcut sisteminizin ne kadar güvenli olduğunu sorguluyorsunuz. Güvenlik, çoğu zaman 'sonradan hallederiz' listesine girer — ta ki bir ihlal yaşanana dek. Gerçekte güvenlik açıkları; müşteri verilerinin çalınması, KVKK kapsamında idari para cezası ve kamuoyunda itibar kaybı anlamına gelir. Bu yazı teknik ekibinize bir kontrol listesi, size ise 'nelerin sorulması gerektiği' konusunda bir çerçeve sunuyor.

Neden Web Uygulama Güvenliği Ertelenebilir Değil?

OWASP (Open Web Application Security Project), web uygulama güvenlik risklerini her birkaç yılda bir güncelliyor. 2021 baskısında 'Broken Access Control' ilk sıraya oturdu — yani çoğu sistemdeki en kritik açık, kullanıcıların yetkisiz verilere erişebildiği senaryolardır. Bu ne anlama geliyor? Sizin sisteminizde, bir kullanıcı URL'yi değiştirerek başka bir müşterinin siparişlerini veya faturalarını görebiliyor olabilir. Bu, teknik bir hata değil, tasarım kökenli bir güvenlik açığıdır.

Türkiye'de KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) kapsamında kişisel veri ihlallerinde Kişisel Verileri Koruma Kurumu'na bildirim yükümlülüğü ve idari yaptırım riski bulunmaktadır. Avrupa'da iş yapan veya AB vatandaşlarının verilerini işleyen işletmeler için GDPR ek bir katman ekler. Güvenlik bir maliyet kalemi değil, yasal bir zorunluluktur.

OWASP Top 10 (2021): İşletme Sahiplerinin Bilmesi Gereken Liste

OWASP Top 10 2021 listesi şu kategorilerden oluşuyor: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, A10 Server-Side Request Forgery (SSRF). Bu yazıda iş etkisi en yüksek başlıkları pratik önlemlerle ele alıyoruz.

Broken Access Control: Yetkilendirme Neden #1 Risk?

Kimlik doğrulama 'kim olduğunuzu kanıtlamak', yetkilendirme ise 'ne yapabileceğinizi belirlemek' demektir. Pek çok uygulamada kimlik doğrulama güçlü olsa da yetkilendirme kontrolleri eksiktir. Tipik örnek: bir admin panelinin URL'si bilindiğinde, sıradan kullanıcı olarak da açılabilmesi. Önlem: her işlem öncesinde sunucu tarafında (server-side) yetki kontrolü yapılmalı; yetkilendirme kararı asla yalnızca istemci (client-side) tarafına bırakılmamalıdır. Uygulamada en sık karşılaşılan yöntem RBAC (Role-Based Access Control) — her rolün yalnızca ihtiyaç duyduğu kaynaklara eriştiği 'least privilege' prensibidir.

Kimlik Doğrulama ve Oturum Yönetimi: JWT, Session ve MFA

Güvenli kimlik doğrulama için şu pratikler temeldir:

• Parola depolamada bcrypt, Argon2 veya PBKDF2 kullanın — düz metin veya MD5 ile SHA-1 kabul edilemez.
• JWT (JSON Web Token) kullanıyorsanız kısa ömürlü access token + güvenli refresh token döngüsü kurun; token'ları localStorage yerine httpOnly cookie'de saklayın.
• Session yönetiminde oturum açıldıktan sonra session ID'yi yenileyin (session fixation önlemi); oturum kapatmada sunucu tarafında token'ı geçersiz kılın.
• MFA (Çok Faktörlü Kimlik Doğrulama) — özellikle admin hesapları ve finansal işlemler için TOTP (Google Authenticator, Authy) veya SMS tabanlı OTP uygulayın.
• Brute-force koruması: belirli sayıda başarısız denemeden sonra hesap kilitleme veya CAPTCHA devreye alın.

SQL Injection ve XSS: Enjeksiyon Saldırılarını Durdurmak

SQL Injection, saldırganın kullanıcı girdisi üzerinden veritabanı komutları çalıştırdığı bir açıktır. Önlem basit ama uygulanması disiplin ister: parametrik sorgular (prepared statements) ve ORM kullanımı. Örnek — güvensiz:

SELECT * FROM users WHERE email = '" + userInput + "' — bu yapı, girdi olarak ' OR '1'='1 girildiğinde tüm kayıtları döndürür. Güvenli alternatif: parametrik sorgu ile WHERE email = $1 ve değeri ayrı geçmek.

XSS (Cross-Site Scripting), saldırganın zararlı JavaScript kodunu uygulamanıza enjekte ederek diğer kullanıcıların tarayıcısında çalıştırmasıdır. Önlem: kullanıcıdan gelen her veriyi HTML çıktısına yazmadan önce encode edin (HTML escaping); içerik politikası için Content Security Policy (CSP) header'ı yapılandırın; React, Vue gibi modern frameworklerin otomatik escaping özelliğini devre dışı bırakmayın (dangerouslySetInnerHTML gibi kaçınılması gereken API'ler).

XSS'in özellikle tehlikeli olduğu senaryo, çalınan session cookie'leri üzerinden hesap ele geçirmedir (session hijacking). Bir saldırgan, XSS açığı sayesinde kullanıcının oturumunu çalabilir ve o kullanıcı gibi işlem yapabilir. Bu nedenle httpOnly cookie kullanımı hem XSS hem de oturum güvenliği için çakışan kritik bir önlem olarak öne çıkar.

API Güvenliği: Rate Limiting, Input Validation ve Kimlik Doğrulama

Günümüz uygulamalarının omurgası API'lerdir; dolayısıyla API güvenliği uygulama güvenliğinin merkezindedir. Temel önlemler:

• Her endpoint, kimlik doğrulama gerektirmeyen public kaynaklar dışında korumalı olmalıdır. Unutulan 'internal' endpoint'ler en sık veri sızıntısı kaynağıdır.
• Rate limiting: belirli süre içindeki istek sayısını sınırlayın. Bu hem brute-force hem de DDoS yüzeyini daraltır.
• Input validation: istemciden gelen tüm veriler sunucu tarafında doğrulanmalıdır. İzin verilen tip, uzunluk ve format dışındaki girdiler reddedilmelidir.
• API yanıtlarında gereksiz veri döndürmeyin (over-fetching). Kullanıcının yetkisi olmadığı alanlar response'dan çıkarılmalıdır.
• API anahtarları ve secret'lar asla kaynak koduna veya client-side bundle'a gömülmemelidir.

Veri Şifreleme: Transit ve Rest Güvenliği

İki temel şifreleme katmanı vardır. Transit (aktarım sırasında): tüm bağlantılar TLS 1.2 veya üzeri ile şifrelenmelidir; TLS 1.0 ve 1.1 güvenli değildir. HTTP'den HTTPS'e zorunlu yönlendirme ve HSTS (HTTP Strict Transport Security) header'ı ile sertifika bypass saldırılarına karşı ek koruma sağlanır. Rest (durağan halde): veritabanında hassas veriler (parola hash'leri, TC kimlik numaraları, ödeme bilgileri) şifreli tutulmalıdır. Tam disk veya sütun düzeyinde şifreleme uygulamaları platform seçimine göre değişir (PostgreSQL pgcrypto, AWS RDS encryption, vb.).

Dependency ve Supply-Chain Güvenliği

Modern bir web uygulaması yüzlerce açık kaynak kütüphaneye bağımlıdır. Bu kütüphanelerden biri ele geçirilirse, sizi de etkiler. 2020'deki SolarWinds saldırısı ve 2021'deki Log4Shell açığı supply-chain riskinin ne denli ciddi olduğunu gösterdi. Pratik önlemler:

• npm audit, yarn audit veya Snyk ile bağımlılıklarınızı düzenli tarayın.
• CI/CD pipeline'ınıza güvenlik tarama adımı ekleyin; yüksek önem dereceli açık tespit edildiğinde build'i durdurun.
• Kullanılmayan bağımlılıkları kaldırın; bağımlılıkları minimum tutun.
• Package-lock.json veya yarn.lock dosyalarını versiyon kontrolüne dahil ederek tam bağımlılık ağacını sabitleyin.
• SBOM (Software Bill of Materials) — kurumsal müşteriye teslim edilen projelerde bağımlılık envanteri kritik önem taşır.

Secrets Yönetimi: Parolalar ve API Anahtarları Nereye Saklanmalı?

En sık karşılaşılan güvenlik ihlallerinden biri, GitHub'a yüklenen kaynak kodun içinde kalan veritabanı parolası veya üçüncü taraf API anahtarıdır. Doğru yöntem: tüm hassas değerler environment variable'lara taşınmalı ve kaynak kontrolüne girmemelidir. Üretim ortamı için AWS Secrets Manager, HashiCorp Vault, Azure Key Vault veya benzeri bir secrets management servisi kullanılmalıdır. .env dosyaları .gitignore'a eklenmeli; .env.example dosyasında yalnızca anahtar adları (değer olmadan) yer almalıdır. Bu kuralı ekip genelinde uygulayabilmek için pre-commit hook veya git-secrets gibi araçlar işe yarar.

Secrets yönetimindeki disiplin eksikliği, dünya genelinde defalarca büyük veri ihlalinin kaynağı olmuştur. GitHub’ın kendi istatistiklerine göre her yıl milyonlarca secret, kaynak koduna gömülü halde halka açık depolara düşmektedir. Doğru yaklaşım: tüm hassas değerler ortam değişkenlerine (environment variables) taşınmalı, asla versiyon kontrolüne girmemeli; üretim ortamlarında AWS Secrets Manager, HashiCorp Vault veya Azure Key Vault gibi özel bir secret yönetim servisi kullanılmalıdır. .env dosyaları .gitignore içine alınmalı, ekip genelinde pre-commit hook veya git-secrets gibi araçlarla bu kural zorunlu kılınmalıdır.

Güvenli Yazılım Geliştirme Yaşam Döngüsü (Secure SDLC)

Güvenlik, sprint bitiminde 'güvenlik testi' başlığıyla değil, her aşamaya entegre edilerek sağlanır. NIST Secure Software Development Framework (SSDF) ve OWASP SAMM bu konuda referans çerçevelerdir. Pratik uygulama:

• Tasarım aşamasında tehdit modelleme (threat modeling): 'Bu özelliği kötüye kullanmak isteyen biri ne yapar?' sorusu sorulur.
• Geliştirme sırasında SAST (Static Application Security Testing) araçları: SonarQube, Semgrep gibi araçlar kodunuzu otomatik tarar.
• Yayına alma öncesinde DAST (Dynamic Application Security Testing): çalışan uygulamayı dışarıdan tarar (OWASP ZAP ücretsiz ve yaygın kullanılan bir seçenektir).
• Penetrasyon testi: düzenli aralıklarla bağımsız güvenlik uzmanlarına uygulama üzerinde kontrollü saldırı testi yaptırın.
• Güvenlik yamalarının hızlı uygulanması için açık bir süreç — kaç gün içinde kritik açıklar kapatılıyor?

Secure SDLC yaklaşımının somut kazanımı şudur: yayına almadan önce bulunan bir açığı kapatmak, yayına aldıktan sonra bulunana kıyasla genellikle çok daha az zaman ve kaynak gerektirir. IBM'in 'Cost of a Data Breach' raporları, erken aşama tespitinin ihlal başına maliyeti önemli ölçüde azalttığını her yıl tutarlı biçimde göstermektedir. Bu nedenle güvenlik testini son kilometre sorunu olmaktan çıkarıp geliştirme sürecinin her halkasına yaymak, hem ticari hem de teknik açıdan doğru karardır.

KVKK ve GDPR Uyumu: Yasal Çerçeve ile Teknik Güvenliği Bağlamak

KVKK'nın 12. maddesi, veri sorumlusuna kişisel verilerin güvenliğini sağlamaya yönelik teknik ve idari tedbirleri alma yükümlülüğü getirir. Bu, yalnızca hukuk departmanının meselesi değil, teknik ekibin günlük çalışmasının parçasıdır. Uygulama düzeyinde şu pratikler KVKK/GDPR uyumunu destekler:

• Veri minimizasyonu: uygulamanın işlevsel olarak ihtiyaç duymadığı kişisel veriyi toplamayın.
• Saklama sınırlaması: artık işlenme amacı kalmayan kişisel verileri silin veya anonim hale getirin.
• Erişim günlüğü (audit log): kişisel verilere kimlerin ne zaman eriştiğini kayıt altına alın.
• Veri ihlali bildirimi: KVKK'da yetkili makamlara (Kişisel Verileri Koruma Kurumu) bildirimi, ihlalin öğrenilmesinden itibaren 72 saat olan GDPR süresine yakın uygulamak iyi pratik sayılır.
• Veri işleme envanteri (VERBİS): Türkiye'de belirli kriterleri karşılayan veri sorumluları VERBİS'e kayıt yaptırmakla yükümlüdür.

Güvenlik Bir Hizmet Olarak: ADWEBX'te Web Uygulaması Nasıl Geliştirilir?

Güvenli bir web uygulaması inşa etmek, doğru altyapı seçimi ve disiplinli bir geliştirme sürecinin ürünüdür. ADWEBX, büyüyen işletmeler ve kurumsal müşteriler için web uygulaması ve SaaS geliştirirken güvenliği sprint'ten sprint'e taşınan bir madde değil, mimarinin başından itibaren bir parçası olarak ele alır: tehdit modelleme, güvenli kimlik doğrulama yapıları, OWASP kontrol listeleri ve bağımlılık yönetimi dahil.

Mevcut uygulamanızın güvenlik durumu hakkında ön değerlendirme almak için /analiz sayfamızı ziyaret edin veya WhatsApp üzerinden ekibimizle iletişime geçin.

Sıkça Sorulan Sorular

OWASP Top 10 nedir ve neden önemlidir?

OWASP (Open Web Application Security Project) tarafından yayımlanan Top 10 listesi, web uygulamalarındaki en kritik güvenlik risklerini kategorize eder. 2021 baskısı en güncel sürümdür. Liste, sektörde evrensel referans kabul edilir; penetrasyon testleri, güvenlik denetimleri ve geliştirme standartları bu listeye göre şekillenir. Herhangi bir güvenlik yatırımına nereden başlanacağını bilmek isteyen işletmeler için temel başlangıç noktasıdır.

Web uygulamamın güvenliğini test ettirmek için ne yapmalıyım?

İki temel yaklaşım vardır: (1) Otomatik tarama — OWASP ZAP veya Burp Suite Community Edition gibi araçlarla çalışan uygulamanızı dışarıdan tarayabilirsiniz. Bu, bilinen zafiyetleri hızlı tespit eder. (2) Penetrasyon testi (pentest) — bağımsız güvenlik uzmanları uygulamanızı kontrollü saldırı senaryolarıyla test eder; bu yöntem çok daha kapsamlı bulgular sağlar. Finansal veri veya kişisel veri işleyen uygulamalar için yılda en az bir kez pentest önerilir.

JWT mi yoksa session cookie mi kullanmalıyım?

Her ikisi de doğru uygulandığında güvenli olabilir; tercih uygulama mimarisine göre şekillenir. JWT, stateless ve dağıtık mimariler (mikro-servisler, mobil-backend) için uygundur; ancak token'ın iptal edilmesi (revocation) ek bir mekanizma gerektirir. Session cookie ise sunucu tarafında saklandığı için anında geçersiz kılınabilir; monolitik uygulamalarda daha basit bir seçenektir. Her iki durumda da token veya session ID httpOnly ve Secure flag ile işaretlenmiş cookie'de saklanmalıdır.

KVKK ihlali durumunda ceza ne kadar olabilir?

KVKK'nın 18. maddesi kapsamında idari para cezaları uygulanabilir. Kanunun 12. maddesindeki veri güvenliği yükümlülüklerini yerine getirmeyenlere Kişisel Verileri Koruma Kurulu tarafından idari para cezası uygulanabilmektedir; kurul kararları KVK Bülteni üzerinden kamuoyuyla paylaşılmaktadır. Ceza tutarları ihlal türü, kapsam ve kurulun takdir yetkisine göre belirlenir. Ancak asıl risk yalnızca para cezası değil — müşteri güveni ve itibar kaybıdır.

Yazılım geliştirme sürecine güvenlik nasıl entegre edilir?

Bu yaklaşım 'DevSecOps' veya 'Shift-Left Security' olarak adlandırılır: güvenlik kontrollerini geliştirme döngüsünün mümkün olan en erken aşamasına taşımak. Pratik başlangıç adımları: kod incelemesinde (code review) güvenlik kontrol listesi kullanmak, CI/CD pipeline'a bağımlılık tarama (npm audit, Snyk) eklemek, geliştirici ekibe temel güvenlik eğitimi vermek. Bu önlemler, yayına alma sonrası bulunan açıkların onarım maliyetini önemli ölçüde düşürür — IBM'in 'Cost of a Data Breach' araştırması erken aşama tespitinin maliyeti önemli ölçüde azalttığını her yıl teyit etmektedir.