1. Security by Design Nedir?
Security by design, güvenliği “kontrol listesi” olarak değil, sistemin tasarım prensibi olarak ele alır: varsayılan ayarlar güvenli olur (secure-by-default), yetkiler minimumda tutulur (least privilege) ve her katmanda savunma bulunur (defense-in-depth). Bu yaklaşımda güvenlik, sprint sonunda “eklenen” değil; her feature ile birlikte “tasarlanan” bir gereksinimdir.
Security by design nedir, web sitesi için ne ifade eder?
Security by design; web sitesinde kimlik doğrulama, yetkilendirme, input doğrulama, veri koruma ve log/izleme gibi konuların daha proje başında mimariye dahil edilmesidir. Böylece güvenlik, sonradan eklenen yamalarla değil, sistemin varsayılan davranışıyla sağlanır.
Ne yapmalıyım?
- • Security requirements’ı “Definition of Done”a ekle
- • Rol ve yetki modelini (RBAC) baştan çiz
- • Go-live öncesi güvenlik checklist’ini zorunlu yap
2. OWASP Temelleri (Web Uygulama Riskleri)
OWASP, web uygulamalarında en sık karşılaşılan risk sınıflarını anlatır. Buradaki amaç “korkutmak” değil; ekibin aynı dili konuşmasını sağlamaktır. Kurumsal sitelerde risk yüzeyi genelde şu alanlarda büyür: formlar, admin panel, oturum yönetimi, dosya yükleme ve entegrasyonlar.
Kurumsal web sitesinde en sık görülen güvenlik açıkları nelerdir?
Sıklıkla görülen açıklıklar; XSS (kötü amaçlı script), SQLi (veritabanı enjeksiyonu), CSRF (oturumla işlem yaptırma), zayıf kimlik doğrulama, hatalı yetkilendirme, güvenli olmayan dosya yükleme ve yanlış yapılandırmadır. Bunlar genelde input doğrulama, rol modeli ve güvenli varsayılanlar doğru kurulmadığında ortaya çıkar.
XSS / SQLi / CSRF — basit açıklama + pratik karşılık
- •XSS: Kullanıcı girdisi ekranda “ham” basılırsa risk artar → escape/sanitize
- •SQLi: Parametreli sorgu yoksa risk artar → prepared statements/ORM
- •CSRF: Oturumla kritik işlem yapılır, token yoksa risk artar → CSRF token + same-site cookies (Varsayım)
Ne yapmalıyım?
- • En kritik 10 endpoint’i (login/form/upload) listele
- • Her biri için “risk → kontrol” eşleştirmesi yap
- • Staging’de OWASP checklist’ini smoke test gibi çalıştır
| Risk Alanı | Tipik Problem | Hızlı Kontrol | Go-Live Testi |
|---|---|---|---|
| XSS | sanitize yok | output escape | form alanı test |
| SQLi | parametreli sorgu yok | prepared/ORM | API endpoint test |
| CSRF | token yok | CSRF token / same-site | form submit test |
| Auth | zayıf parola/MFA yok | MFA + rate limit | brute force simülasyonu |
| Upload | dosya türü serbest | allowlist + limit | zararlı dosya denemesi |
| Admin | açık erişim | IP/VPN + MFA | erişim testi |
3. Kimlik Doğrulama ve Yetkilendirme
Kurumsal sitelerde en büyük risklerden biri “kimse fark etmeden admin paneline girilmesi” veya “yanlış rolün yanlış veriye erişmesi”dir. Güvenli auth/authorization; sadece login ekranı değil, oturum yönetimi, MFA, şifre politikası ve rol modelini kapsar.
Login ve yetki katmanı tasarımı (RBAC)
- •Rol tanımları: admin, editor, viewer (örnek)
- •Yetkiler: sayfa düzenleme, yayınlama, kullanıcı yönetimi
- •“Minimum yetki”: varsayılan rol en kısıtlı olmalı
Admin panel hardening (kritik)
- •Admin URL gizleme tek başına güvenlik değildir; ama yüzeyi küçültür (Varsayım)
- •IP allowlist/VPN (Varsayım: kurum politikası)
- •MFA zorunluluğu
- •Rate limiting / brute force koruması
Ne yapmalıyım?
- • RBAC matrisini çıkar (kim ne yapar)
- • Admin panel erişimini kısıtla (MFA + rate limit)
- • Log ve alert kurgusunu (şüpheli giriş) aktive et
4. Girdilerin Doğrulanması ve Veri Koruma
“Input validation” güvenliğin temelidir; form alanlarından dosya yüklemeye kadar her yerde geçerlidir. Veri koruma ise hem güvenlik hem uyum (KVKK/PCI gibi) açısından kritik katmandır: hangi veri toplanıyor, nerede tutuluyor, kim erişiyor?
Form ve dosya yükleme güvenliği
- •Dosya türü kontrolü (allowlist)
- •Boyut limiti ve tarama (Varsayım)
- •Upload’ların public path’ten servis edilmemesi (Varsayım)
- •Form abuse (spam) önlemleri: rate limit, honeypot (Varsayım)
Veri koruma (PII) ve minimizasyon
- •Gereğinden fazla veri toplama = risk
- •Şifreleme (in transit + at rest) (Varsayım)
- •Log’larda PII maskeleme (Varsayım)
Ne yapmalıyım?
- • Form alanlarını KVKK perspektifiyle sadeleştir
- • Upload için allowlist + limit + izolasyon uygula
- • PII için saklama ve maskeleme politikasını yaz
5. Otel ve B2B İçin Güvenlik Checklist’i
Otel ve B2B’nin ortak noktası: form akışları ve admin alanlar. Farkı ise otelde ödeme/rezervasyon ve sezon kampanyaları; B2B’de portal/raporlama ekranları ve doküman erişimleridir.
Otel için kritik yüzeyler
- •Rezervasyon/ödeme akışı (Varsayım: ödeme sağlayıcı/PCI uyumu)
- •Kampanya landing’leri (tracking script’leri)
- •Call center / CRM entegrasyonları
B2B için kritik yüzeyler
- •Portal login ve yetki katmanı
- •Raporlama ekranları (data exposure riski)
- •Doküman indirme/erişim kontrolü
Ne yapmalıyım?
- • Go-live’da “security gate” uygula (kritik kontroller geçmeden yayın yok)
- • Otel: ödeme/rezervasyon akışını ayrı test planı yap
- • B2B: rol bazlı yetki ve veri erişimini doğrula
6. “Kurumsal Web Güvenlik Checklist’i” Şablonunu İndir
“Kurumsal Web Güvenlik Checklist’i” Şablonunu İndir — Yazılım / Web Security (v1.0)
Bu checklist, kurumsal web sitelerinde security by design yaklaşımını go-live öncesi uygulanabilir kontrol noktalarına dönüştürür. OWASP riskleri, auth/role, form/upload ve admin panel hardening adımlarını tek dokümanda toplar. Otel ve B2B projelerinde canlıya çıkış öncesi güvenlik kapısı (security gate) gibi kullanılır.
Kim Kullanır?
Tech lead, FE/BE, DevOps, QA, güvenlik sorumlusu, proje yöneticisi.
Nasıl Kullanılır?
- Checklist’i staging ortamında çalıştırın ve bulguları kayıt altına alın.
- Riskleri “kök neden → çözüm” tablosuyla önceliklendirin.
- 14 günlük sprint planıyla hardening’i tamamlayıp go-live’da tekrar doğrulayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ MFA + rate limit aktif mi?
- ▢ ✅ RBAC rol matrisi var mı?
- ▢ ✅ Input validation / output escaping kontrol edildi mi?
- ▢ ✅ CSRF koruması var mı?
- ▢ ✅ Upload allowlist + limit var mı?
- ▢ ✅ Admin erişimi kısıtlı mı (VPN/IP)?
- ▢ ✅ Log/alert (şüpheli giriş) var mı?
- ▢ ✅ KVKK/PII minimizasyonu yapıldı mı?
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
7. Sonuç: Güvenlik sonradan eklenen değil, baştan tasarlanan bir mimari katmandır
Security by design, kurumsal web projelerinde güvenliği yayından sonra çözülmesi gereken bir problem olmaktan çıkarır; proje başında mimari karar haline getirir. OWASP risklerini anlamak, auth/role modelini doğru kurmak, input doğrulama ve veri korumayı standartlaştırmak, admin paneli sertleştirmek ve go-live öncesi security gate işletmek bu yaklaşımın temelidir.
Otel tarafında rezervasyon/ödeme ve admin panel; B2B tarafında portal, raporlama ve doküman erişimleri en kritik yüzeylerdir. Bu yüzeyleri baştan güvenli tasarlamak, hem itibar hem de hukuki riskleri azaltır.
Bir Sonraki Adım
OWASP risklerini, auth/role modelini ve form/admin güvenliğini birlikte değerlendirip uygulanabilir hardening planı çıkaralım.