Bir web sitesinde güvenliği kontrol etmek, SSL sertifikasının aktif olup olmadığına bakıp işi kapatmak değildir. Özellikle web sitesi; ERP, Netsis, e-ticaret altyapısı, ödeme sistemi, CRM veya başka bir kurumsal uygulamayla veri alışverişi yapıyorsa saldırı yüzeyi genişler. Kullanıcı hesabından API anahtarına, sunucu ayarından hata kayıtlarına kadar farklı noktaların birlikte değerlendirilmesi gerekir.
OWASP'ın Web Security Testing Guide çalışması da web uygulaması güvenliğini yapılandırma, kimlik doğrulama, yetkilendirme, oturum yönetimi, veri doğrulama, hata yönetimi, kriptografi, iş mantığı ve API güvenliği gibi ayrı alanlarda ele alıyor.
Aşağıdaki 15 kontrol, kurumsal bir web sitesini veya web tabanlı uygulamayı değerlendirirken iyi bir başlangıç çerçevesi sunar.
1. HTTPS gerçekten tüm sistemde kullanılıyor mu?
SSL sertifikasının bulunması tek başına yeterli değildir. HTTP üzerinden erişilebilen sayfaların HTTPS'e yönlendirilmesi, yönetim panelinin ve API uçlarının da şifreli bağlantı kullanması gerekir.
Özellikle kullanıcı adı, parola, oturum bilgisi ve erişim anahtarı gibi verilerin şifrelenmemiş bağlantı üzerinden gönderilmemesi gerekir. OWASP, kimlik bilgileri ve oturum belirteçlerinin aktarım sırasında HTTPS ile korunmasını temel kontrollerden biri olarak tanımlıyor.
ERP veya Netsis entegrasyonu varsa aynı kontrol web sitesi ile entegrasyon servisi arasındaki trafik için de yapılmalıdır.
2. Yönetim paneli dışarıya gereğinden fazla açık mı?
/admin adresini değiştirmek güvenlik önlemi sayılmaz. Asıl mesele yönetim paneline kimin, nereden ve hangi şartlarla erişebildiğidir.
Mümkün olan projelerde yönetim erişimi IP kısıtlaması, VPN, çok faktörlü kimlik doğrulama veya ek erişim politikalarıyla sınırlandırılabilir. Başarısız giriş denemeleri de kayıt altına alınmalıdır.
Bir saldırganın yönetim ekranını bulması sorun değildir. Yetkisiz şekilde kullanabilmesi sorundur.
3. Kullanıcı yetkileri gerçekten ayrılmış mı?
Bir kullanıcının sisteme giriş yapabiliyor olması bütün verilere erişebileceği anlamına gelmez.
Örneğin e-ticaret yönetiminde ürün düzenleme yetkisi olan bir personelin finansal raporları görmesine gerek olmayabilir. Bayi portalında bir müşterinin başka müşterilere ait siparişleri görüntüleyememesi gerekir. Entegrasyon hesabının da yalnızca ihtiyaç duyduğu işlemleri gerçekleştirebilmesi gerekir.
Yetki kontrolü yalnızca ekrandaki menüleri gizleyerek yapılmamalıdır. Sunucu tarafında her istek için kullanıcının ilgili işlem üzerinde yetkisi doğrulanmalıdır.
OWASP Top 10'un 2025 sürümünde bozuk erişim kontrolü ilk sıradaki risk alanıdır.
4. Parola ve oturum güvenliği nasıl yönetiliyor?
Parola politikası kadar oturum yönetimi de kontrol edilmelidir.
Oturum açıldıktan sonra oluşturulan cookie ve token'ların güvenli olması, tahmin edilebilir değerler kullanılmaması, gerektiğinde oturum süresinin sınırlandırılması ve çıkış işleminin gerçekten oturumu sonlandırması gerekir.
OWASP'ın oturum yönetimi testlerinde cookie özellikleri, oturum sabitleme, oturum zaman aşımı, oturum ele geçirme ve JWT kontrolleri ayrı test başlıkları olarak ele alınıyor.
Yönetici hesaplarında çok faktörlü kimlik doğrulama da değerlendirilmelidir. CISA, işletmeler için temel güvenlik uygulamaları arasında güçlü kimlik doğrulama ve MFA kullanımını açık şekilde öneriyor.
5. Formlardan ve API'lerden gelen veriler doğrulanıyor mu?
İletişim formu, üyelik ekranı, ürün araması veya API isteği fark etmez. Kullanıcıdan ya da başka bir sistemden gelen veri güvenilir kabul edilmemelidir.
Alan türü, uzunluk, format ve izin verilen değerler sunucu tarafında kontrol edilmelidir. Veritabanı sorgularında parametreli sorgular kullanılmalı; SQL injection gibi saldırılara kapı açabilecek doğrudan sorgu birleştirmelerinden kaçınılmalıdır.
ERP entegrasyonlarında bu konu daha da kritiktir. Web sitesinden gelen hatalı bir stok kodunun doğrudan ERP'ye yazılması teknik bir güvenlik probleminden operasyonel veri problemine dönüşebilir.
6. API anahtarları ve erişim bilgileri nerede tutuluyor?
API kullanıcı adı, parola, token veya veritabanı şifresinin kaynak kod içine yazılması ciddi bir risktir.
Bu bilgiler yapılandırma ve secret yönetimi için uygun alanlarda tutulmalı, herkese açık kod depolarına veya istemci tarafındaki JavaScript dosyalarına düşmemelidir.
Aynı API anahtarını geliştirme, test ve canlı ortamda kullanmak da gereksiz risk yaratır.
Özellikle ERP ve e-ticaret entegrasyonlarında her sistem için ayrı kullanıcı ve mümkünse ihtiyaca göre sınırlanmış yetkiler kullanılmalıdır.
7. Web sitesi ile ERP arasındaki bağlantı gereğinden fazla yetkili mi?
Entegrasyon tarafında sık yapılan hatalardan biri, işi kolaylaştırmak için veritabanına geniş yetkili bir kullanıcı tanımlamaktır.
Web uygulaması yalnızca stok miktarını okuyacaksa bütün veritabanında yazma veya silme yetkisine sahip olmamalıdır. Sipariş aktaracak bir servis de gereksiz tablolara erişmemelidir.
Netsis entegrasyonunda hangi tabloların ve alanların gerçekten kullanılacağını önceden belirlemek bu yüzden önemlidir. Netsis veri yapısını anlamak için Piasoft'un hazırladığı Netsis Tabloları ve Açıklamaları rehberi ilgili tablo ve modülleri incelemek için kullanılabilir. Netsis Tabloları ve Açıklamaları
İyi bir entegrasyon hesabının yetkisi şu mantıkla tanımlanır: İşi yapabilecek kadar yetki, daha fazlası değil.
8. Yazılım, eklenti ve kütüphaneler güncel mi?
Web sitesi yıllar önce sorunsuz geliştirilmiş olabilir. Bu, bugün de güvenli olduğu anlamına gelmez.
Framework, CMS, eklenti, JavaScript paketi, sunucu yazılımı ve kullanılan diğer bileşenlerin desteklenen sürümlerde bulunması gerekir. Artık kullanılmayan eklentilerin yalnızca devre dışı bırakılması yerine sistemden kaldırılması daha doğru olabilir.
OWASP'ın güncel risk sınıflandırmasında yazılım tedarik zinciri sorunları da ayrı bir güvenlik alanı olarak yer alıyor.
Güncelleme ise doğrudan canlı ortamda yapılmamalıdır. Özellikle ERP ve ödeme sistemi entegrasyonlarında küçük bir kütüphane değişikliği bile veri akışını bozabilir.
9. Sunucu üzerinde gereksiz servis ve dosyalar bulunuyor mu?
Eski proje klasörleri, yedek ZIP dosyaları, test dosyaları, açık dizin listeleme, kullanılmayan servisler ve yanlış yapılandırılmış sunucu bileşenleri dışarıya gereksiz bilgi verebilir.
backup.zip, eski bir .sql çıktısı veya yanlışlıkla erişilebilir bırakılmış yapılandırma dosyası, saldırgan için uygulamanın kendisinden daha değerli olabilir.
Canlı sunucuda yalnızca gerçekten ihtiyaç duyulan dosya ve servisler tutulmalıdır.
10. Hata mesajları saldırgana teknik bilgi veriyor mu?
Kullanıcıya gösterilen hata ekranında SQL sorgusu, tablo adı, dosya yolu, framework sürümü veya sunucu detayı bulunmamalıdır.
Kullanıcı açısından çoğu durumda işlemin başarısız olduğunu ve gerekiyorsa ne yapması gerektiğini bilmek yeterlidir. Teknik ayrıntı log sisteminde tutulmalıdır.
Üstelik hata yönetimi sadece bilgi sızıntısıyla ilgili değildir. Entegrasyonlarda başarısız bir sipariş aktarımının ne yapılacağı da önceden belirlenmelidir.
Sipariş tekrar mı gönderilecek? Manuel inceleme kuyruğuna mı alınacak? Aynı sipariş ikinci kez ERP'ye yazılabilir mi?
Güvenli sistem, hatayı saklayan değil; hatayı kontrollü yöneten sistemdir.
11. Log kayıtları gerçekten işe yarıyor mu?
“Log tutuyoruz” tek başına pek bir şey söylemez.
Başarısız girişler, yönetici işlemleri, yetki değişiklikleri, kritik veri güncellemeleri, API hataları ve entegrasyon başarısızlıkları gerektiğinde geriye dönük incelenebilmelidir.
Bir e-ticaret siparişinin web sitesinde oluştuğu fakat ERP'ye ulaşmadığı durumda şu soruların cevabı bulunabilmelidir:
Sipariş ne zaman oluşturuldu? Entegrasyon servisine gönderildi mi? ERP ne cevap verdi? İşlem kaç kez denendi? Kim manuel müdahale yaptı?
CISA da işletme sistemlerinde log kullanımını temel güvenlik uygulamalarından biri olarak öneriyor.
12. Yedek var mı, yoksa yalnızca yedek alındığı mı sanılıyor?
Yedekleme sisteminin varlığı yeterli değildir. Yedeğin geri yüklenebilir olması gerekir.
Web dosyaları, veritabanı ve kritik yapılandırmalar için yedekleme kapsamı belirlenmeli; yedeklerin uygulamayla aynı noktada tutulmasının yaratacağı risk değerlendirilmelidir. Belirli aralıklarla geri yükleme testi yapılmadan yedeklerin çalıştığından emin olunamaz.
ERP ve web sitesi ayrı sistemlerse veri tutarlılığı da hesaba katılmalıdır. Web veritabanını dün geceki yedeğe döndürüp ERP'yi bugünkü verilerle bırakmak sipariş, stok veya cari hesap eşleşmelerini bozabilir.
Bu nedenle kurtarma planı tek bir veritabanını değil, birbirine bağlı sistemleri kapsamalıdır.
13. Dosya yükleme alanları kontrol ediliyor mu?
Dosya yükleme özelliği bulunan web sitelerinde sadece dosya uzantısına bakmak yeterli değildir.
İzin verilen dosya türleri sınırlandırılmalı, boyut kontrolleri yapılmalı ve yüklenen dosyaların sunucuda nasıl saklandığı değerlendirilmelidir. Kullanıcının gönderdiği dosya adını doğrudan kullanmak veya yükleme klasöründe çalıştırılabilir dosyalara izin vermek risk oluşturabilir.
Bu kontrol özellikle bayi portalları, insan kaynakları sistemleri, destek sistemleri ve belge yüklenen özel web uygulamalarında atlanmamalıdır.
14. Kritik işlemler iş mantığı açısından test edildi mi?
Teknik olarak geçerli bir istek, iş açısından geçerli olmayabilir.
Örneğin stokta olmayan ürün için sipariş oluşturulabiliyor mu? Bir kullanıcı kendisine ait olmayan sipariş numarasını değiştirerek başka siparişe ulaşabiliyor mu? Aynı ödeme bildirimi iki kez gönderildiğinde iki ayrı sipariş veya tahsilat oluşuyor mu?
ERP entegrasyonlarında çift kayıt özellikle dikkat ister. Ağ bağlantısının kesildiğini düşünelim. Web sitesi ERP'ye siparişi gönderir, ERP kaydı oluşturur ancak cevap web sitesine ulaşamaz. Sistem isteği tekrar gönderdiğinde aynı siparişin ikinci kez oluşmasını engelleyecek bir mekanizma bulunmalıdır.
Bu nedenle entegrasyon güvenliği, yalnızca şifreleme ve firewall konusu değildir. Veri modelinin ve işlem akışının güvenli tasarlanması gerekir.
15. Güvenlik kontrolleri tek seferlik mı yapılıyor?
Canlıya çıkmadan önce yapılan güvenlik testi değerlidir fakat web sitesi orada donup kalmaz.
Yazılımlar güncellenir. Yeni kullanıcılar açılır. API'ler değişir. Yeni entegrasyonlar eklenir. Sunucu ayarları değiştirilir. Bir süre sonra ilk gün yapılan kontrol mevcut sistemi temsil etmemeye başlar.
Güvenlik bu nedenle bakım sürecinin parçası olmalıdır. Güncellemelerin, yedeklerin, hata kayıtlarının, formların ve üçüncü taraf entegrasyonların düzenli kontrol edilmesi gerekir.
Piasoft'un Bakım & Destek hizmeti; web siteleri ve özel web yazılımlarında güncelleme, güvenlik kontrolü, yedekleme, log takibi ve üçüncü taraf entegrasyonların teknik takibini kapsayan yayın sonrası süreçlere odaklanıyor. Piasoft Bakım & Destek hizmetini inceleyin
Entegrasyon varsa güvenlik kontrolü web sitesi sınırında bitmez
ERP, Netsis, CRM veya e-ticaret sistemiyle bağlantılı bir projede üç ayrı soru birlikte cevaplanmalıdır: Hangi veri aktarılıyor, kim bu veriye erişebiliyor ve bir işlem başarısız olduğunda sistem ne yapıyor?
Ürün, stok, fiyat, cari, sipariş ve ödeme verilerinin hangi sistemde ana kayıt olarak tutulacağı baştan belirlenmelidir. Veri alanlarının eşleşmesi tanımlanmalı, API ve veritabanı erişimleri ihtiyaç kadar yetkilendirilmeli, bağlantılar şifrelenmeli ve başarısız işlemler izlenebilmelidir.
Örneğin stok miktarı Netsis'ten web sitesine aktarılıyorsa yalnızca teknik bağlantının çalışması yeterli değildir. Hangi deponun esas alınacağı, rezervasyondaki stokların hesaba katılıp katılmayacağı, güncellemenin ne sıklıkla yapılacağı ve bağlantı kesilirse web sitesinde hangi değerin gösterileceği de tanımlanmalıdır. Aksi halde güvenli çalışan bir API üzerinden yanlış veri taşınabilir.
Piasoft, özel web yazılımlarını ERP, CRM ve benzeri kurumsal sistemlerle entegre çalışacak şekilde planladığını; proje sürecini ihtiyaç analizi, teknik planlama, geliştirme, test ve yayın sonrası destek adımlarıyla yürüttüğünü belirtiyor. Piasoft web yazılım çözümlerini inceleyin
Başarılı bir entegrasyonun ölçüsü verinin A sisteminden B sistemine ulaşması değildir. Doğru verinin doğru yetkiyle aktarılması, tekrar eden veya başarısız işlemlerin kontrol edilmesi ve gerektiğinde bütün hareketin geriye dönük izlenebilmesidir. Web sitesi güvenliği de tam olarak bu zincirin içinde ele alınmalıdır.