E-Ticaret Sitesi Güvenliği

E-ticaret sitesi güvenliği; müşteri hesaplarını, sipariş verilerini ve ödeme akışını saldırılara karşı koruyan teknik ve yönetsel önlemlerin bütünüdür. Ankara Cyberpark'ta kurulu Secunnix'in araştırma ekibi olarak bu yazıda e-ticaret sitelerinde öne çıkan saldırı yollarını istek örnekleriyle gösteriyor, her biri için uygulanabilir önlemi anlatıyoruz. Yazının sonunda ekibinizle kullanabileceğiniz bir kontrol listesi de bulacaksınız.

E-ticaret sitesi güvenliği neden farklıdır?

Kurumsal bir tanıtım sitesinde saldırganın hedefi genellikle sunucudur. E-ticaret sitesinde ise saldırgan doğrudan paraya ve paraya dönüşebilen verilere yönelir: kart bilgileri, müşteri hesapları, hediye çekleri, kuponlar ve stok.

İkinci fark iş akışıdır. Sepet, kupon, ödeme ve iade adımları birbirine bağlıdır. Her adım tek başına doğru çalışsa bile adımların sırası değiştirildiğinde veya bir değer elle düzenlendiğinde site beklenmedik davranabilir. Otomatik tarayıcılar bu tür mantık hatalarını çoğu zaman yakalayamaz.

E-ticaret sitelerinde saldırı yüzeyi

Bir e-ticaret sitesi yalnızca görünen mağazadan oluşmaz. Saldırı yüzeyi müşteri arayüzü, yönetim paneli, mobil uygulama, API'ler ve üçüncü taraf servislerin toplamıdır.

En sık istismar edilen açıklar

OWASP Top 10:2025 listesinde ilk üç sırada bozuk erişim kontrolü, güvenlik yanlış yapılandırması ve yazılım tedarik zinciri hataları yer alıyor. Üçü de e-ticaret sitelerini doğrudan ilgilendirir.

Başkasının siparişini görmek (IDOR)

Erişim kontrolü hatalarının en bilinen örneği IDOR'dur (Insecure Direct Object Reference). Müşteri kendi siparişini şu istekle görüntülüyor olsun:

GET /api/orders/10482
Cookie: session=...

Sunucu yalnızca oturumun geçerli olduğuna bakıp siparişin bu müşteriye ait olup olmadığını kontrol etmiyorsa, numarayı değiştiren herkes başka müşterilerin adını, adresini ve telefonunu görür. Önlem nettir: Her istekte, istenen kaydın oturumdaki kullanıcıya ait olduğu sunucu tarafında doğrulanmalıdır. Tahmin edilmesi zor kimlikler kullanmak faydalıdır, ama yetki kontrolünün yerini tutmaz.

Fiyat ve iş mantığı manipülasyonu

Tarayıcıdan gelen hiçbir değer güvenilir değildir. Sepete ekleme isteği fiyatı da taşıyorsa saldırgan onu değiştirmeyi dener:

POST /api/cart/add
{"productId": 7731, "quantity": 1, "price": 1.00}

Doğrusu, sunucunun yalnızca ürün kimliğini ve adedi alması, fiyatı kendi veritabanından okumasıdır. Aynı mantık şu durumlarda da test edilmelidir: eksi adet girilmesi, tek kullanımlık kuponun aynı anda gönderilen isteklerle birden çok kez kullanılması (race condition) ve ödeme adımı atlanarak sipariş onay adresine doğrudan gidilmesi.

Hesap ele geçirme

Başka sitelerden sızan kullanıcı adı ve parolaların otomatik denenmesine credential stuffing denir. Müşteriler parolalarını farklı sitelerde tekrar kullandığı için bu saldırı siteniz hiç açık vermese de sonuç verebilir. Ele geçirilen hesaplarda kayıtlı adres, puan ve hediye çeki kötüye kullanılır.

Giriş ve parola sıfırlama adreslerinde istek sınırlandırma, şüpheli girişlerde ek doğrulama ve yönetim paneli için zorunlu çok faktörlü kimlik doğrulama temel önlemlerdir. Parola sıfırlama bağlantıları tek kullanımlık ve kısa ömürlü olmalıdır. Kurum hesaplarınızın sızıntılarda geçip geçmediğini ise BeyondMemory gibi tehdit istihbaratı araçlarıyla izleyebilirsiniz.

Ödeme sayfasına zararlı kod (web skimming)

Web skimming saldırısında saldırgan ödeme sayfasına zararlı bir JavaScript kodu yerleştirir. Kod, müşterinin yazdığı kart bilgisini arka planda kendi sunucusuna gönderir. Müşteri ödemesini sorunsuz tamamladığı için durum uzun süre fark edilmeyebilir. Bu yöntem kamuoyunda Magecart adıyla bilinir.

Kodu eklemek için site sunucusuna girmek şart değildir. Ödeme sayfasında çalışan bir analiz, canlı destek veya etiket yönetimi kodunun ele geçirilmesi de aynı sonucu verir. Bu yüzden ödeme sayfasında yalnızca gerçekten gereken kodlar çalışmalıdır. Content Security Policy (CSP) başlığıyla izin verilen kaynaklar sınırlandırılabilir:

Content-Security-Policy: default-src 'self'; script-src 'self' https://odeme.ornek.com; connect-src 'self' https://odeme.ornek.com; frame-ancestors 'none'

Dış kaynaklardan yüklenen dosyalar için Subresource Integrity (SRI) kullanılması da dosya değiştiğinde çalışmasını engeller. Yeni politikayı önce Content-Security-Policy-Report-Only başlığıyla deneyin; aksi halde sitenizin bir bölümü çalışmayabilir.

Eklentiler ve yanlış yapılandırma

Hazır altyapılardaki güncellenmemiş eklenti ve temalar, saldırganların otomatik taradığı başlıca hedeflerdir. Bu yüzden kullanılan bileşenlerin envanterini tutmak ve güncellemeleri takip etmek gerekir. Zafiyet tarama bu takibe süreklilik kazandırır.

Yanlış yapılandırma ise çoğu zaman basit hatalardan oluşur: dışarıdan erişilebilen yedek dosyaları ve .git dizini, üretimde açık bırakılan hata ayıklama çıktıları, varsayılan yönetici adresi ve parolası, herkese açık bırakılmış test ortamları.

Ödeme güvenliği: kart verisini neden tutmamalısınız?

Kart verilerini işleyen, saklayan veya ileten kuruluşlar PCI DSS standardının kapsamına girer. En güvenli yaklaşım kart verisine hiç dokunmamaktır. Ödeme kuruluşunun barındırdığı ödeme sayfası veya iframe kullanıldığında kart bilgisi sizin sunucunuzdan geçmez. CVV gibi hassas doğrulama verileri ise yetkilendirmeden sonra hiçbir koşulda saklanmamalıdır.

Bu yöntem her riski ortadan kaldırmaz. Ödeme formunu çerçeveleyen sayfa hâlâ sizindir ve ele geçirilirse müşteri sahte bir forma yönlendirilebilir. PCI DSS 4.0.1'in 6.4.3 ve 11.6.1 gereksinimleri de bu nedenle ödeme sayfasındaki kodların yetkilendirilmesini ve değişikliklerin izlenmesini ister.

E-ticaret sitesi güvenlik kontrol listesi

1. Her API isteğinde kaydın sahibini sunucu tarafında doğrulayın.

2. Fiyat, indirim ve kargo tutarını yalnızca sunucuda hesaplayın.

3. Giriş, parola sıfırlama ve kupon uç noktalarına istek sınırı koyun.

4. Yönetim paneline çok faktörlü kimlik doğrulama ekleyin, mümkünse erişimi IP ile sınırlayın.

5. Ödeme sayfasındaki dış kodları envanterleyin ve gereksizleri kaldırın.

6. CSP, HSTS ve güvenli çerez ayarlarını (HttpOnly, Secure, SameSite) uygulayın.

7. Altyapı, eklenti ve kütüphaneleri düzenli güncelleyin.

8. Yedekleri dışarıdan erişilemeyecek bir yerde saklayın ve geri dönüşü test edin.

9. Giriş, yetki ve ödeme olaylarını kayıt altına alın; şüpheli hareketlerde uyarı üretin.

10. Mobil uygulamayı ve API'leri web sitesiyle birlikte test edin.

Kayıtların gerçekten izlenmesi de önemlidir. Küçük ekipler için bu izleme bir SOC hizmeti üzerinden sağlanabilir.

KVKK ve Güven Damgası açısından e-ticaret güvenliği

Müşteri verisi içeren bir ihlal yaşandığında veri sorumlusu olarak yükümlülükleriniz başlar. Kişisel Verileri Koruma Kurulu'nun 2019/10 sayılı kararına göre veri ihlali bildirimi ihlalin öğrenilmesinden itibaren en geç 72 saat içinde Kurula yapılmalıdır. Bu sürenin kriz anında yönetilebilmesi için olay müdahale planının önceden hazır olması gerekir.

TOBB'un Güven Damgası uygulaması da güvenliği ölçülebilir bir şarta bağlar. Damga almak zorunlu değildir, ancak başvuracak sitenin TSE onaylı bir firmaya sızma testi yaptırması ve önlemlerini doğrulama testiyle göstermesi gerekir. Kapsam, sitenin yıllık işlem hacmine göre belirlenir.

Kontrol listesi iyi bir başlangıçtır, ancak iş mantığı hatalarını bulmanın en güvenilir yolu sitenizi gerçek bir saldırgan gibi test ettirmektir. Secunnix olarak TSE onaylı firma sıfatıyla Güven Damgası sızma testi ve e-ticaret sitelerine yönelik sızma testi hizmeti veriyoruz. Sitenizin kapsamını konuşmak için iletişim sayfasından bize ulaşabilirsiniz.