İleri Seviye Dropshipping: Hız & Güvenlik

Dropshipping Mağazasında Hız ve Güvenlik Mimarisi​

Hız ve güvenlik e-ticarette iki ayrı proje değildir. Kontrolsüz pazarlama etiketi ödeme sayfasını hem yavaşlatabilir hem de hassas veriye erişen yeni bir risk oluşturabilir. Aşırı agresif önbellek ise hızlı görünen sayfada yanlış fiyat veya başka kullanıcıya ait sepet bilgisi gösterebilir.

Bu rehber, dropshipping mağazasını yalnız PageSpeed puanına veya “güvenlik eklentisi kuruldu” kutusuna indirgemiyor. Amaç; ürün sayfasından ödeme ve tedarikçi entegrasyonuna kadar performans ile güvenliği aynı değişiklik sürecinde yönetmek.

---

Hızlı ve güvenli mağaza, en az kod kullanan değil; hangi kodun neden çalıştığını bilen mağazadır.

Önce veri ve istek akışını çizin​

Neyi koruduğunuzu ve neyin yavaşlattığını görmek için mağazanın dış bağlantı haritasını çıkarın. Tarayıcıdan, sunucudan ve zamanlanmış görevlerden hangi hizmetlere veri gidiyor?

• Ödeme sağlayıcısı ve 3D Secure dönüşleri,
• tedarikçi/ürün/stok entegrasyonu,
• kargo ve takip hizmeti,
• analitik, reklam ve etiket yöneticileri,
• canlı destek, yorum, kişiselleştirme ve A/B test araçları,
• e-posta/SMS, fatura ve muhasebe bağlantıları.

Her bağlantı için sahibi, gönderilen veri, kullanılan yetki, çalıştığı sayfalar, performans maliyeti ve kapatma yolu yazılsın. Kimsenin sahiplenmediği eski etiketler hem saldırı yüzeyini hem JavaScript yükünü büyütür.

Değişiklik kuralı' Alıntı:

Yeni bir uygulama veya etiket eklenirken yalnız “ne kazandırıyor?” değil, “hangi veriye erişiyor, hangi sayfayı yavaşlatıyor ve bozulursa nasıl kapatılır?” soruları da yanıtlanmalıdır.

Genişletmek için tıkla ...

Ödeme kapsamını bilinçli olarak daraltın​

Kart verisini kendi sunucunuzda toplamak veya saklamak, küçük bir mağazanın gereksiz yere ağır güvenlik ve uyum sorumluluğu üstlenmesine yol açabilir. Güvenilir ödeme sağlayıcısının önerdiği barındırılan sayfa, yönlendirme veya güvenli gömülü form yaklaşımını değerlendirin. Hangi entegrasyonun PCI DSS kapsamınıza uygun olduğunu ödeme sağlayıcınız, bankanız ve gerekiyorsa yetkin uyum kuruluşuyla doğrulayın.

Gömülü ödeme formu kullanmak mağaza sayfasını risksiz yapmaz. PCI Security Standards Council, ödeme formunu etkileyebilen e-ticaret sayfalarında script saldırılarına karşı koruma ve ilgili sağlayıcıyla güvenli uygulama teyidini vurgular. Ödeme sayfasındaki her script için iş gerekçesi ve sahiplik kaydı tutun.

TLS’yi yalnız kilit simgesi olarak görmeyin​

Tüm oturumu HTTPS üzerinden sunun; HTTP isteklerini tek kanonik HTTPS adrese yönlendirin. Geçerli sertifika, doğru ara sertifika zinciri ve otomatik yenileme uyarısı bulunmalıdır. HSTS gibi başlıklar yararlı olabilir fakat yanlış kapsam veya hazırlıksız `includeSubDomains` ayarı alt alan adlarını erişilemez kılabilir; önce raporlayın ve kademeli uygulayın.

Oturum çerezlerinde platformunuzun desteklediği `Secure`, `HttpOnly` ve uygun `SameSite` özelliklerini kullanın. OWASP, oturum kimliğinin tüm oturum boyunca TLS ile korunmasını ve riskli olaylarda oturumun yenilenmesini önerir. SSL/TLS temelini açıklayan SSL ve SEO ilişkisi rehberi bu bölümün devamıdır.

Yönetici hesaplarını müşteri hesabından daha sıkı koruyun​

Yönetici, destek, ajans ve geliştirici hesaplarını ortak kullanmayın. Her kişiye ayrı hesap ve yalnız görevi için gereken yetki verin. Yönetici girişlerinde çok faktörlü doğrulama, parola yöneticisi ve düzenli erişim gözden geçirmesi kullanın.

• Ayrılan çalışan/ajans erişimini aynı gün kapatın.
• Yeni cihaz veya şüpheli girişte yeniden doğrulama isteyin.
• Yüksek tutarlı iade, ödeme ayarı ve yetki değişikliğini ek onaya bağlayın.
• Kurtarma kodlarını sohbet veya e-postada açık bırakmayın.
• Kullanılmayan servis hesaplarını ve API anahtarlarını kaldırın.

Müşteri girişlerinde parola denemelerini sınırlayın; fakat saldırganın kullanıcı hesabı var/yok bilgisini kolayca ayırmasına imkân veren hata mesajlarından kaçının. Hesap ele geçirme belirtileri için başarısız giriş, parola sıfırlama ve teslimat adresi değişikliklerini birlikte izleyin.

Üçüncü taraf JavaScript’i envantersiz çalıştırmayın​

Pazarlama pikselleri, sohbet kutuları ve kişiselleştirme araçları tarayıcıda mağazanızın yetkileriyle çalışabilir. OWASP’ın üçüncü taraf JavaScript rehberi, bu kodların DOM’daki verilere ulaşabileceğini ve tedarik zinciri riski oluşturabileceğini açıklar.

Her etiket için şu kararları verin:

• Ürün, sepet veya ödeme sayfasında gerçekten gerekli mi?
• Hangi DOM/veri katmanı alanlarını okuyabiliyor?
• İzin/onay tercihlerine uygun zamanda mı çalışıyor?
• Sağlayıcı dosyayı değiştirdiğinde haber alabiliyor musunuz?
• Yüklenmezse sayfa ve ödeme akışı çalışmaya devam ediyor mu?

Sabit sürümlü dış kaynaklarda Subresource Integrity uygun olabilir; tarayıcı, dosyanın beklenen kriptografik özetle eşleşmesini kontrol eder. Ancak dinamik sağlayıcı dosyalarında körlemesine SRI eklemek güncellemeleri kırabilir. İçerik Güvenlik Politikası’nı da önce raporlama modunda gözleyip gerekli alan adlarını çıkararak kademeli uygulayın.

Eklenti ve bağımlılık sayısını işlevle yönetin​

“Devre dışı” eklenti her zaman risksiz veya maliyetsiz değildir. Kullanılmayan tema, uygulama ve paketleri kaldırın. Aktif bileşenlerde bakım sıklığı, güvenlik duyuruları, yetki kapsamı ve kaldırma planı bulunsun.

Güncellemeyi doğrudan yoğun saatte canlıya göndermeyin:

1. Dosya ve veritabanı yedeğini alın.
2. Değişiklik kaydını ve güvenlik notlarını okuyun.
3. Mümkünse test ortamında ürün–sepet–ödeme–iade akışını çalıştırın.
4. Canlı dağıtım sonrasında sentetik test ve hata oranını izleyin.
5. Sorun oluşursa geri alma ölçütünü ve sorumlusunu uygulayın.

Güncelleme düzenini mağaza operasyonuyla birleştirmek için dropshipping bakım rutinini kullanabilirsiniz.

API anahtarlarını ürün kodundan uzak tutun​

Tedarikçi, kargo, e-posta ve ödeme anahtarlarını tema dosyasına, tarayıcı JavaScript’ine, ekran görüntüsüne veya sürüm kontrolüne yazmayın. Sunucu tarafı sır yöneticisi ya da hostingin güvenli ortam değişkenlerini kullanın. Her anahtar yalnız ihtiyaç duyduğu işlem ve kaynağa erişsin.

Anahtar envanterinde sahibi, kapsamı, oluşturulma tarihi ve yenileme/iptal yöntemi yer alsın. Bir anahtar sızmış olabileceğinde önce yenisini üretip sistemi geçirerek eskisini iptal edin; ardından loglarda kötüye kullanım arayın. Aynı anahtarı test ve canlı ortamda kullanmayın.

Webhook ve sipariş otomasyonunda tekrarları güvenli yönetin​

Ödeme veya tedarikçi webhook’u ağ hatası nedeniyle tekrar gelebilir. Aynı olayın iki kez işlenmesi çift sipariş, çift iade veya yanlış stok doğurabilir. Sağlayıcı imzasını doğrulayın, olay kimliğini kaydedin ve işlemleri idempotent tasarlayın.

Webhook uç noktası hızlı yanıt verip ağır işi kuyruğa bırakabilir; fakat kuyruktaki başarısızlık görünür olmalıdır. Tekrar deneme sayısı, karantina/dead-letter kuyruğu ve elle yeniden işleme adımı belirleyin. Ham istekte kişisel veya ödeme verisini gereksiz süre loglamayın.

Kişisel veriyi önce azaltın, sonra koruyun​

Tedarikçinin siparişi göndermesi için gerekli olmayan veriyi paylaşmayın. Doğum tarihi, pazarlama tercihi veya müşteri notu lojistik sağlayıcısına gerekmeyebilir. Her entegrasyonda veri alanlarını iş amacıyla eşleştirin.

Saklama sürelerini “belki lazım olur” diye sonsuz bırakmayın. Fatura, tüketici işlemi ve yasal kayıt gereksinimleri ülkeye göre değişebilir; güncel süreleri uzmanla doğrulayın. Erişim, dışa aktarma ve silme talepleri için kimin ne yapacağı önceden yazılı olsun.

Dolandırıcılığı yalnız IP engeliyle çözmeye çalışmayın​

Yüksek adet, hızlı adres değişikliği, sıra dışı ülke/ödeme uyuşmazlığı veya art arda başarısız deneme risk sinyali olabilir; tek başına suç kanıtı değildir. Katmanlı ve ölçülü kontroller kullanın. Yüksek riskli siparişi otomatik iptal etmek yerine insan incelemesine göndermek yanlış pozitifleri azaltabilir.

Kupon ve stok botlarına karşı hız sınırı, cihaz/hesap davranışı ve işlem başına sınırlar uygulanabilir. Kontroller gerçek müşteriyi sürekli CAPTCHA ile cezalandırmamalı. Reddedilen siparişler ve itirazlar üzerinden kuralın ayrım gücünü düzenli ölçün.

Logları olay anında işe yarayacak biçimde tutun​

“Hata oluştu” kaydı yeterli değildir. Olay zamanı, istek/işlem kimliği, ilgili servis, sonuç kodu ve güvenli bağlam bulunmalıdır. Parola, tam kart verisi, oturum belirteci veya gereksiz kişisel veriyi loglamayın.

Şu olaylar için uyarı kurun:

• Ödeme başarılı fakat sipariş oluşmadı,
• aynı işlem kimliği birden fazla işlendi,
• stok/fiyat senkronizasyonu beklenen sürede çalışmadı,
• yönetici hesabında olağan dışı giriş veya yetki değişikliği,
• ödeme sayfası script/başlık envanterinde beklenmeyen değişiklik,
• hata oranı, yanıt süresi veya kaynak tüketiminde ani sıçrama.

Uyarının sahibi ve müdahale süresi yoksa pano yalnız dekor olur. Kritik uyarıyı e-postadaki yüzlerce pazarlama mesajının arasına bırakmayın.

Önce gerçek kullanıcı verisini ölçün​

Tek bir Lighthouse koşusu faydalı teşhis sağlar fakat gerçek kullanıcıların cihaz, ağ ve coğrafya çeşitliliğini temsil etmez. Laboratuvar testiyle nedenleri araştırın; saha verisi/RUM veya Chrome User Experience Report ile gerçek deneyimi izleyin.

Core Web Vitals’ın kararlı ölçümleri LCP, INP ve CLS’dir. web.dev, iyi deneyim için en az ziyaretlerin yüzde 75’inde LCP’nin 2,5 saniye veya altında, INP’nin 200 ms veya altında ve CLS’nin 0,1 veya altında hedeflenmesini önerir. Bu eşikler başlangıçtır; iş hedefleri ve kritik akış ölçümleriyle birlikte ele alınmalıdır.

LCP’yi kahraman görselden önce ağ zincirinde arayın​

Ürün sayfasının ana görseli çoğu zaman LCP öğesidir. Tarayıcı bu kaynağı geç keşfediyorsa yalnız JPEG kalitesini düşürmek yetmez. İlk HTML yanıtı, render engelleyen CSS/JS, görsel keşif zamanı ve kaynak indirme süresini ayrı inceleyin.

• İlk ekrandaki ana görseli HTML’de keşfedilebilir tutun; gereksiz lazy-load uygulamayın.
• Doğru boyutta AVIF/WebP ve `srcset/sizes` kullanın; küçük ekrana masaüstü dosyası göndermeyin.
• Gerekiyorsa LCP kaynağının önceliğini artırın, fakat her görseli preload etmeyin.
• Sunucu yanıtı, sayfa önbelleği ve CDN etkisini gerçek bölgelerden ölçün.
• Kritik olmayan uygulama/etiketleri ilk render sonrasına bırakın.

web.dev’in LCP rehberi süreci ilk HTML belgesi ile LCP kaynağının keşif, indirme ve render alt parçaları üzerinden incelemeyi önerir.

INP için sepet ve varyant etkileşimini ayrı ölçün​

Ürün sayfasında varyant seçimi, adet değişimi, sepete ekleme ve kupon işlemi yüksek JavaScript işi oluşturabilir. Kullanıcı tıkladığında uzun görevler ana iş parçacığını meşgul ediyorsa hızlı açılan sayfa yine ağır hissedilir.

Tekrarlanan olay dinleyicilerini, büyük üçüncü taraf paketlerini ve gereksiz yeniden render işlemlerini profilleyin. Ağ isteği gerekiyorsa anında görsel geri bildirim verin; aynı butona tekrar basılması çift sipariş üretmemeli. Üçüncü taraf sohbet veya öneri motorunun ödeme adımındaki iş değerini ayrıca sorgulayın.

CLS için alanı baştan ayırın​

Ürün görselleri, reklam/öneri kutuları, kupon mesajları ve çerez banner’ı sonradan sayfayı itebilir. Görsel ve iframe’lere boyut/aspect-ratio verin; stok veya kampanya mesajı için ayrılmış alan kullanın. Sayfanın üstüne geç yüklenen içerik en çok yanlış tıklamaya neden olur.

Font değişimi de buton ve fiyat alanını kaydırabilir. Gerekli karakter setini ve ağırlıkları sınırlayın; fallback metriklerini ayarlayın. CLS yalnız ilk yüklemede değil, tüm sayfa yaşamında oluşabildiği için gerçek kullanıcı oturumlarını da izleyin.

Önbellekte kişisel ve dinamik alanları ayırın​

Ürün açıklaması ve statik varlıklar agresif biçimde önbelleğe alınabilir; sepet, hesap, ödeme, stok ve kişiye özel fiyat aynı kuralla ele alınmamalıdır. CDN/cache anahtarında para birimi, ülke veya oturum varyasyonunu yanlış yönetmek başka kullanıcıya ait veri gösterebilir.

Sepet ve ödeme sayfalarını platformun önerdiği biçimde dinamik bırakın. Önbellek temizleme olaylarını fiyat/stok güncellemesiyle bağlayın. Değişiklikten sonra yalnız ana sayfayı değil, oturumlu ve oturumsuz kullanıcıyla ürün–sepet–ödeme akışını test edin.

Dağıtım için ortak hız–güvenlik kapısı kurun​

Her yeni tema, uygulama veya etiket şu kapılardan geçsin:

• Yetki ve veri akışı değişti mi?
• Yeni üçüncü taraf script hangi sayfalarda çalışıyor?
• Mobil ürün, sepet ve ödeme performans bütçesi aşıldı mı?
• Başarılı/başarısız ödeme, webhook ve iade testleri geçti mi?
• Güvenlik başlıkları, çerezler ve erişim kontrolleri bozuldu mu?
• Log/uyarı ile geri alma planı hazır mı?

SEO ve tarama tarafındaki teknik kontroller için dropshipping teknik SEO rehberini, daha geniş güvenlik rotası için web güvenliği başlangıç rotasını kullanabilirsiniz.

Olay müdahale kartını krizden önce yazın​

Ödeme sayfasında şüpheli script, anahtar sızıntısı veya hesap ele geçirme görüldüğünde ilk kararlar önceden belli olmalıdır:

1. Etkilenen akışı güvenli biçimde durdurun veya sağlayıcıya yönlendirin.
2. Kanıtı koruyun; logları temizlemeyin ve rastgele dosya değiştirmeyin.
3. Anahtar/oturumları kontrollü biçimde iptal edip yenileyin.
4. Ödeme, hosting ve güvenlik sağlayıcılarıyla olay kanalını açın.
5. Etkilenen veri ve kullanıcı kapsamını yetkin kişilerle belirleyin.
6. Yasal bildirim ve müşteri iletişimini geçerli mevzuata göre yönetin.
7. Temiz yedekten geri dönüş ve yeniden açılış ölçütünü kaydedin.

Olayı kapattıktan sonra yalnız “eklenti güncellendi” demeyin; ilk sinyalin neden görülmediğini ve aynı sınıf hatayı hangi kontrolün yakalayacağını yazın.

30 günlük uygulama sırası​

• 1. hafta: Veri/istek haritası, hesap ve anahtar envanteri, ödeme kapsamı görüşmesi.
• 2. hafta: Üçüncü taraf script temizliği, çerez/oturum, webhook ve log kontrolleri.
• 3. hafta: Saha ölçümü, LCP/INP/CLS teşhisi, görsel/JS/cache iyileştirmeleri.
• 4. hafta: Gerçek ödeme/iade testi, dağıtım kapıları, geri yükleme ve olay tatbikatı.

Hosting/CDN/TLS tarafında daha geniş altyapı sırası gerekiyorsa Hosting–CDN–SSL başlangıç rotasına geçin.

Sık sorulan sorular​

Yüksek PageSpeed puanı mağazanın hızlı olduğunu kanıtlar mı?

Tek başına hayır. Laboratuvar testi teşhis sağlar; gerçek kullanıcı saha verisi, ürün–sepet–ödeme süreleri ve hata oranlarıyla birlikte okunmalıdır.

CDN kullanınca güvenlik ve hız sorunu biter mi?

Hayır. CDN statik varlık ve ağ katmanında yardımcı olabilir; yavaş uygulama sorgusu, ağır JavaScript, bozuk oturum veya hatalı yetkiyi düzeltmez. Yanlış önbellek kuralı yeni risk de yaratabilir.

Ödeme sağlayıcısı kullanıyorsam PCI DSS beni ilgilendirmez mi?

Entegrasyon modeline göre sorumluluk ve doğrulama kapsamı değişir. Mağaza sayfanız ödeme formunu veya ilgili scriptleri etkileyebiliyorsa ek kontroller gerekebilir. Kesin kapsamı ödeme sağlayıcınız ve uyum kuruluşunuzla belirleyin.

Güvenlik eklentisi yeterli mi?

Hayır. Kimlik, yetki, güncelleme, script envanteri, sır yönetimi, log, yedek ve olay müdahalesi birlikte çalışır. Eklenti bu yapının yalnız bir parçasıdır.

İlk hangi metriği düzeltmeliyim?

Gerçek kullanıcı verisinde en çok ziyaret ve gelir etkileyen darboğazdan başlayın. Ödeme hatası veya veri sızıntısı riski varsa performans puanından önce güvenli akışı düzeltin.

Güvenilir dış kaynaklar​

• web.dev – Core Web Vitals yaşam döngüsü ve ölçümleri
• web.dev – LCP teşhis ve iyileştirme rehberi
• OWASP – Üçüncü taraf JavaScript yönetimi
• OWASP – Güvenli oturum yönetimi
• PCI SSC – Ödeme sayfası güvenliği ve e-skimming rehberi
• MDN – Subresource Integrity

Özetle​

Dropshipping mağazasında hız ve güvenlik, dağıtımdan sonra yapılan iki ayrı kontrol değildir. Veri akışını, üçüncü taraf kodu, ödeme kapsamını, gerçek kullanıcı performansını ve geri alma planını aynı değişiklik kapısında yönetin. İlk iş olarak ödeme sayfanızda çalışan tüm scriptleri çıkarın: Her birinin sahibi, iş gerekçesi ve kapatma yolu bugün belli mi?

---