WooCommerce Magaza Guvenligi ve Musteri Verisi Koruma

Bir e-ticaret sitesi, sıradan bir kurumsal tanıtım sitesinden bambaşka bir risk sınıfındadır. Vitrin sitesinde en kötü ihtimalle ana sayfanız tahrif edilir; oysa WooCommerce mağazanızda sipariş kayıtları, adresler, telefon numaraları, e-posta listeleri ve ödeme akışının kendisi vardır. Saldırgan için bu, doğrudan paraya çevrilebilecek bir hedef demektir: çalınan müşteri verisi karaborsada satılır, ödeme sayfasına gizlice yerleştirilen bir betik kart bilgilerini toplar (buna "web skimming" ya da Magecart tarzı saldırı denir) ve tüm bunlar siz fark etmeden haftalarca sürebilir. Türkiye'de KVKK, veri ihlali durumunda bildirim yükümlülüğü ve idari para cezaları getirdiği için mesele sadece teknik değil, aynı zamanda hukuki bir sorumluluktur.

Bu rehberde WooCommerce mağazanızı katman katman nasıl sertleştireceğinizi, kart verisini neden hiçbir zaman kendi sunucunuzda tutmamanız gerektiğini, yönetici hesabını ve giriş ekranını nasıl koruyacağınızı, güncelleme ve yedekleme disiplinini ve müşteri kişisel verisine dair yasal sorumluluğunuzu somut örneklerle anlatacağım. Henüz mağazanızı kurmadıysanız önce WooCommerce başlangıç rehberine göz atın; WordPress tarafının genel sertleştirmesi için de WordPress güvenliği yazısı bu rehberi tamamlar. Buradaki odağımız, e-ticaretin kendine özgü risk yüzeyidir.

Neden E-Ticaret Siteleri Öncelikli Hedef Oluyor?#

E-ticaret siteleri saldırganların iştahını üç nedenle kabartır. Birincisi, doğrudan finansal veri akar: müşteri ödeme sayfasında kart girer, siz her gün gerçek para tahsil edersiniz. İkincisi, kişisel veri yoğundur; binlerce müşterinin adı, adresi, telefonu ve sipariş geçmişi tek bir veritabanında birikir. Üçüncüsü, WooCommerce siteleri tipik olarak onlarca eklentiyle çalışır (ödeme, kargo, fatura, pazarlama, stok) ve her eklenti yeni bir saldırı yüzeyidir. Tek bir güncellenmemiş kargo eklentisindeki açık, tüm siteyi ele geçirmek için yeterli olabilir.

En yaygın saldırı senaryoları şunlardır: yönetici paneline brute-force ya da credential stuffing ile giriş denemesi, güncellenmemiş eklentilerdeki bilinen açıklardan kod çalıştırma, ödeme sayfasına JavaScript skimmer enjeksiyonu, sahte sipariş ve kart deneme (carding) trafiğiyle ödeme ağ geçidinizin kötüye kullanımı, ve SQL enjeksiyonuyla sipariş tablosunun boşaltılması. Bu tehditlerin ortak özelliği çoğunun otomatik botlarla, hedef gözetmeksizin taranarak yürütülmesidir. Yani "benim sitem küçük, kimse uğraşmaz" varsayımı yanlıştır; botlar büyük-küçük ayırmaz.

SSL ve HTTPS: Pazarlık Konusu Değil#

E-ticarette SSL sertifikası isteğe bağlı bir "artı özellik" değil, temel bir gerekliliktir. Ödeme ve giriş sayfalarında iletilen veri şifrelenmemişse, aynı ağdaki bir saldırgan (örneğin halka açık Wi-Fi) trafiği dinleyip oturum çerezini veya form verisini ele geçirebilir. Ayrıca tarayıcılar HTTPS olmayan sitelerde "Güvenli Değil" uyarısı gösterir ve bu uyarı, sepeti dolduran müşterinin ödemeden vazgeçmesinin en hızlı yoludur. Ücretsiz bir SSL sertifikası ile bile bu koruma sağlanabilir; önemli olan sertifikanın var olması değil, doğru yapılandırılmasıdır.

Kurulumdan sonra tüm trafiği kalıcı olarak HTTPS'e yönlendirin ve HSTS başlığıyla tarayıcıya "bu siteye bir daha asla şifresiz bağlanma" talimatı verin. Nginx tarafında tipik bir yapılandırma şöyledir:

# HTTP'yi kalici olarak HTTPS'e yonlendir
server {
    listen 80;
    server_name magaza.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name magaza.example.com;

    # HSTS: tarayici 1 yil boyunca yalniz HTTPS dener
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

WordPress tarafında da site adresini Ayarlar > Genel altında https:// ile güncelleyin; aksi halde "mixed content" (karışık içerik) uyarıları çıkar ve ödeme sayfasındaki bazı betikler bloklanabilir. Sunucu yönetimiyle uğraşmak istemiyorsanız SSL kurulumu ve otomatik yenilemenin dahil olduğu bir WordPress hosting paketi bu adımı sizin yerinize hallederek doğru yapılandırmayı garanti eder.

PCI-Uyumlu Ödeme Ağ Geçidi: Kart Verisi Sitede Tutulmaz#

E-ticaret güvenliğinin en kritik ilkesi tek cümleyle özetlenebilir: kart verisini asla kendi sunucunuzda tutmayın, hatta işlemeyin. PCI DSS (kart endüstrisi veri güvenliği standardı), kart numaralarının saklanması ve iletilmesi için çok ağır teknik ve idari yükümlülükler getirir. Bunun altından kalkmanın makul yolu, ödeme adımını PCI-uyumlu bir ağ geçidine (iyzico, PayTR, Stripe, param vb.) devretmektir. Böylece kart bilgisi ya ağ geçidinin kendi barındırdığı sayfada girilir ya da iframe/tokenizasyon ile toplanır ve sizin sunucunuza hiçbir zaman ham kart numarası düşmez.

Entegrasyon yönteminizin PCI kapsamınızı doğrudan belirlediğini bilmek önemlidir. Aşağıdaki tablo yaygın yaklaşımları karşılaştırır:

Pratik tavsiye: WooCommerce için resmi ya da köklü bir eklenti kullanın ve mümkünse yönlendirme veya iframe tabanlı yöntemi tercih edin. Kendi ödeme formunuzda kart numarası toplamayın; bu, PCI yükümlülüğünü tamamen sizin üstünüze yıkar ve bir skimmer enjeksiyonunda tüm sorumluluk sizde kalır. Ödeme sayfanızda çalışan üçüncü taraf betiklerini de asgariye indirin — reklam pikselleri ve analitik kodları çoğu skimming saldırısının giriş kapısıdır. Content-Security-Policy başlığıyla ödeme sayfasında yalnızca güvendiğiniz kaynakların betik çalıştırmasına izin verin:

# Odeme sayfasinda yalniz beyaz listedeki kaynaklar betik calistirabilsin
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://www.paytr.com https://sandbox.paytr.com; frame-src https://www.paytr.com;" always;

Yönetici Hesabı, 2FA ve Giriş Koruması#

Saldırıların büyük kısmı /wp-login.php ve /wp-admin üzerinden gelir çünkü tek bir başarılı giriş, tüm siteyi teslim eder. İlk kural: admin kullanıcı adını kullanmayın ve WooCommerce yöneticileri için ayrı, güçlü ve benzersiz parolalar tanımlayın. İkinci kural: iki faktörlü doğrulamayı (2FA) zorunlu kılın. Parola çalınsa bile, telefondaki tek kullanımlık kod olmadan giriş yapılamaz. WordPress için Wordfence Login Security ya da benzeri bir eklentiyle 2FA'yı dakikalar içinde açabilirsiniz.

Giriş ekranını kaba kuvvet denemelerine karşı da sınırlamak gerekir. Aşağıdaki gibi bir başarısız-giriş eşiği ve geçici kilit, otomatik botların işini büyük ölçüde bitirir:

# WP-CLI ile roller ve kullanicilari denetle: fazla yetkili hesap var mi?
wp user list --role=administrator --fields=ID,user_login,user_email

# Suphe duyulan bir hesabin oturumlarini aninda sonlandir
wp user session destroy zayifhesap --all

Sunucu düzeyinde giriş sayfasına oran sınırı (rate limit) koymak, uygulama katmanına yük binmeden botları eler. Nginx ile:

# wp-login.php icin dakikada birkac istekle sinirla
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=20r/m;

location = /wp-login.php {
    limit_req zone=wplogin burst=5 nodelay;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Bu önlemleri tek tek yönetmek istemiyorsanız yönetilen bir WAF (web uygulama güvenlik duvarı) hem giriş korumasını hem de bilinen açık taramalarını uygulama önünde durdurur; hacimli saldırılara karşı DDoS koruması ise kampanya günlerinde sitenizi ayakta tutar. Yönetici oturumlarının yalnızca belirli IP'lerden açılmasını istiyorsanız, wp-admin dizinini .htaccess ya da Nginx allow/deny kurallarıyla kısıtlamak ek bir katman sağlar.

Güncelleme, Eklenti Hijyeni ve Sunucu Sertleştirme#

WooCommerce ihlallerinin en yaygın kök nedeni, güncellenmemiş bir eklenti veya temadaki bilinen açıktır. Saldırganlar yeni bir güvenlik açığı yayınlandığında, o eklentiyi kullanan siteleri saatler içinde tarayıp sömürür. Bu yüzden güncelleme bir "ara sıra yapılan bakım" değil, düzenli bir disiplindir. WordPress çekirdeğini, WooCommerce'i, ödeme eklentinizi ve temayı güncel tutun; kullanmadığınız eklenti ve temaları devre dışı bırakmakla kalmayıp tamamen silin çünkü pasif bir eklenti bile dosyaları sunucuda durduğu sürece istismar edilebilir.

Eklenti hijyeninin altın kuralları şunlardır:

• Yalnızca WordPress.org deposundan ya da doğrudan geliştiricisinden eklenti kurun; "nulled" (kırık lisanslı) premium eklenti ve temalar neredeyse her zaman gizli arka kapı içerir.
• Her eklenti için "gerçekten gerekli mi?" diye sorun. Az eklenti = az saldırı yüzeyi.
• Terk edilmiş, uzun süredir güncellenmeyen eklentileri bakımlı alternatifleriyle değiştirin.

Dosya izinlerini de sıkılaştırın. WordPress dizinlerinde tipik güvenli değerler, klasörler için 755, dosyalar için 644 ve wp-config.php için 640 ya da 600'dür:

# Klasorler 755, dosyalar 644
find /var/www/magaza -type d -exec chmod 755 {} \;
find /var/www/magaza -type f -exec chmod 644 {} \;

# Kritik dosyayi daha da kisitla
chmod 640 /var/www/magaza/wp-config.php

PHP tarafında da bazı ayarlar saldırı yüzeyini daraltır. Üretim ortamında hata mesajlarını ekrana basmayın (yol ve sürüm sızdırır), yükleme boyutunu makul tutun ve tehlikeli fonksiyonları kısıtlayın:

; Uretimde hatalari ekranda gosterme, dosyaya yaz
display_errors = Off
log_errors = On

; Makul yukleme sinirlari
upload_max_filesize = 16M
post_max_size = 20M

; Tehlikeli fonksiyonlari kapat
disable_functions = exec,shell_exec,system,passthru,proc_open

Bu düzeydeki sertleştirmeyi kendiniz yürütmek istemiyorsanız, sunucu yönetimi hizmetiyle çekirdek/eklenti güncellemeleri, izin denetimi ve izleme uzman ekibe devredilebilir. Tam kontrol isteyen büyük mağazalar için izole bir sanal sunucu ya da VDS ortamı, komşu sitelerin risklerinden arınmış bir çalışma alanı sağlar. WordPress'in çekirdek sertleştirme kontrol listesi için WordPress güvenliği yazısındaki adımları da uygulamanızı öneririm.

Yedekleme ve Felaket Kurtarma#

En iyi sertleştirmeyle bile "eğer" değil "ne zaman" ihlal olur diye düşünmek gerekir; bu yüzden çalışan bir yedek, güvenliğin son ve en önemli hattıdır. E-ticarette veri sürekli değiştiği için (her yeni sipariş yeni veri demek) yedek sıklığı da vitrin sitesinden yüksek olmalıdır. Günlük tam yedek ve sık veritabanı yedeği iyi bir başlangıçtır; yoğun mağazalarda saatlik veritabanı yedeği bile mantıklıdır. En kritik nokta, yedeğin sitenin bulunduğu sunucudan farklı bir yerde (off-site) durmasıdır — sunucu tümüyle ele geçirilir ya da fidye yazılımıyla şifrelenirse, aynı diskteki yedek de gider.

Basit bir günlük veritabanı yedeği ve harici kopya şöyle otomatikleştirilebilir:

#!/usr/bin/env bash
# gunluk-yedek.sh — veritabanini al, sikistir, uzak depoya kopyala
set -euo pipefail
TARIH=$(date +%F)
mysqldump --single-transaction --quik woocommerce_db \
  | gzip > "/yedek/woo-$TARIH.sql.gz"

# Uzak (off-site) depoya senkronize et
rsync -az "/yedek/woo-$TARIH.sql.gz" yedek@harici-sunucu:/depo/magaza/

3-2-1 kuralını hedefleyin: verinin en az 3 kopyası, 2 farklı ortamda, 1'i tamamen site dışında. Bir de yedeğin gerçekten geri yüklenebildiğini düzenli olarak test edin; hiç denenmemiş bir yedek, çoğu zaman ihtiyaç anında bozuk çıkar. Kendi cron'unuzu kurmak istemiyorsanız otomatik ve sürüm tutan bir yedekleme hizmeti bu süreci güvenceye alır; mağazanızı başka bir ortama sorunsuz taşımanız gerektiğinde ise site taşıma hizmeti veri kaybı riskini ortadan kaldırır.

KVKK ve Müşteri Kişisel Verisi Sorumluluğu#

WooCommerce mağazanız çalıştığı anda siz, KVKK anlamında bir "veri sorumlusu" olursunuz; çünkü müşterilerinizin ad-soyad, adres, telefon, e-posta ve sipariş geçmişi gibi kişisel verilerini işlersiniz. Bu, hem teknik hem hukuki bir dizi yükümlülük getirir. Kişisel veriyi yalnızca gerektiği kadar toplamalı (veri minimizasyonu), açık bir aydınlatma metni ve gizlilik politikası yayımlamalı, gerekli yerlerde açık rıza almalı ve veriyi güvenli biçimde saklamalısınız. Bir veri ihlali yaşanırsa, KVKK bunu "en kısa sürede" Kişisel Verileri Koruma Kurulu'na ve etkilenen kişilere bildirme yükümlülüğü getirir; bildirim yapılmaması ayrıca cezalandırılır.

Pratik açıdan alınacak önlemler şunları içerir: müşteri verisini şifreli bağlantı üzerinden toplamak (SSL), veritabanı ve yedekleri yetkisiz erişime kapalı tutmak, yalnızca gerçekten ihtiyaç duyan personele erişim vermek (en az yetki ilkesi) ve müşterinin "verimi sil" (unutulma hakkı) talebini karşılayabilecek bir süreç kurmak. WooCommerce ve WordPress'in kişisel veri dışa aktarma/silme araçları bu talepleri karşılamayı kolaylaştırır. E-posta pazarlaması yapıyorsanız ticari elektronik ileti için önceden onay (İYS/ETK kapsamı) almanız gerektiğini unutmayın. Verinin nerede saklandığı da önemlidir; Türkiye içinde barındırma, KVKK'nın yurt dışına veri aktarımıyla ilgili ek koşullarını gündemden çıkarır. Ödeme onayı ve sipariş bildirimi gibi işlemsel e-postaların düzgün ulaşması için de güvenilir bir e-posta altyapısı kurmanızda fayda var.

Sıkça Sorulan Sorular#

WooCommerce güvenli mi, yoksa Shopify gibi hazır platform mu daha güvenli?#

WooCommerce'in kendisi, güncel tutulduğu ve doğru yapılandırıldığı sürece güvenlidir; risk çoğunlukla açık kaynak yazılımın kendisinden değil, ihmal edilen güncellemelerden, zayıf parolalardan ve denetimsiz eklentilerden gelir. Shopify gibi kapalı platformlarda altyapı ve yamalar sağlayıcı tarafından yönetildiği için bakım yükü sizde olmaz, ama karşılığında veri ve yapılandırma üzerindeki kontrolünüzü ve esnekliğinizi kaybedersiniz. WooCommerce ile sorumluluk sizde olduğu için, bu rehberdeki sertleştirme adımlarını uygulamak ya da yönetilen bir hosting ile bu yükü devretmek doğru yaklaşımdır.

Kart bilgilerini kendi sitemde saklamam gerekir mi?#

Hayır, kesinlikle gerekmez ve saklamamalısınız. Kart verisini iyzico, PayTR ya da Stripe gibi PCI-uyumlu bir ödeme ağ geçidine devrederek, kart numarasının hiç sizin sunucunuza düşmemesini sağlayabilirsiniz. Bu yaklaşım hem PCI DSS yükümlülüğünüzü en aza indirir hem de olası bir sızıntıda kart verisi zaten sizde olmadığı için sorumluluğunuzu ciddi ölçüde azaltır. Yönlendirme ya da iframe tabanlı entegrasyonlar bu amaç için en güvenli seçeneklerdir.

Sitem küçük, gerçekten hedef olur muyum?#

Evet, olursunuz. Saldırıların büyük kısmı elle hedef seçilerek değil, otomatik botlarla tüm internet taranarak yapılır; bot, sitenin büyüklüğüne değil güncellenmemiş bir eklentiye ya da zayıf bir parolaya bakar. Küçük mağazalar genellikle daha az güvenlik önlemine sahip olduğu için botlar açısından aslında daha kolay hedeftir. Bu nedenle ilk günden itibaren SSL, 2FA, güncelleme disiplini ve yedekleme gibi temelleri kurmak, mağaza büyüklüğünden bağımsız olarak zorunludur.

2FA'yı tüm yöneticiler için zorunlu kılmalı mıyım?#

Evet, panele erişimi olan her hesap için iki faktörlü doğrulamayı zorunlu tutmalısınız. Tek bir yönetici hesabının bile 2FA'sız kalması, çalınan bir parolayla tüm sitenin ele geçirilmesine yol açabilir. Wordfence Login Security gibi ücretsiz eklentilerle 2FA'yı zorunlu hale getirebilir, mümkünse yönetici girişlerini belirli IP adresleriyle de sınırlayabilirsiniz. Editör ve müşteri hesaplarına gereğinden fazla yetki vermemek de bu korumayı tamamlar.

Bir güvenlik ihlali yaşarsam ilk ne yapmalıyım?#

Öncelikle sakin bir şekilde sitenizi geçici olarak bakım moduna alıp daha fazla veri sızmasını durdurmalı, ardından tüm yönetici parolalarını ve WordPress güvenlik anahtarlarını değiştirmelisiniz. Sonra temiz bir yedekten geri yükleme yapmalı, açığın kaynağını (güncellenmemiş eklenti, zayıf parola vb.) bulup kapatmalı ve gerekiyorsa kötü amaçlı dosya taraması çalıştırmalısınız. Kişisel veri sızması söz konusuysa KVKK gereği ihlali en kısa sürede Kurul'a ve etkilenen müşterilere bildirmeniz gereken hukuki bir yükümlülüğünüz de bulunur.

Hangi sertifika e-ticaret için yeterli, DV mi olmalı?#

Şifreleme açısından ücretsiz bir Domain Validation (DV) sertifikası bile ödeme trafiğini korumaya yeterlidir; SSL'in görevi bağlantıyı şifrelemektir ve DV bunu tam olarak yapar. Kurumsal güven algısını yükseltmek isteyen büyük markalar Organization Validation (OV) sertifikası tercih edebilir, ancak bu bir güvenlik farkından çok kurumsal doğrulama farkıdır. Önemli olan sertifikanın türünden çok doğru kurulması, HTTPS yönlendirmesinin ve HSTS'in aktif olmasıdır.

Kapanış#

WooCommerce güvenliği tek bir eklenti kurup unutulacak bir iş değil, katmanlı ve sürekli bir disiplindir: geçerli bir SSL, kart verisini asla sizde tutmayan PCI-uyumlu bir ödeme ağ geçidi, 2FA ve giriş koruması, düzenli güncelleme, çalışan off-site yedek ve KVKK'ya uygun bir veri işleme süreci. Bu katmanların hepsi bir arada olduğunda, tek bir zafiyetin tüm mağazanızı çökertmesi çok zorlaşır. Küçük başlasanız bile bu temelleri ilk günden kurmak, ileride yaşanacak çok daha pahalı ihlalleri önler.

Clou.TR olarak e-ticaret altyapınızın her katmanında yanınızdayız: SSL kurulumu ve otomatik yenilemenin dahil olduğu WordPress hosting ve web hosting paketlerinden, uygulama önünde saldırıları durduran WAF ve DDoS koruması çözümlerine, otomatik yedekleme ve uzman ekibimizin yürüttüğü sunucu yönetimi hizmetine kadar. Büyüyen mağazanız için izole bir sanal sunucu ya da mağazanızı güvenle taşıyacağınız site taşıma desteğiyle, siz satışa odaklanırken güvenlik ve süreklilik tarafını size bırakmadan çözelim.