Webhook doğrulaması yapılmazsa sahte sipariş bildirimi mümkün olur mu?

Webhook, ödeme sistemi, pazar yeri, kargo servisi veya abonelik platformu gibi harici uygulamaların sipariş durumlarını sitenize otomatik bildirmesini sağlar. Ancak bu bildirimler doğrulanmadan işlenirse, kötü niyetli biri gerçek ödeme yapılmamış bir işlemi “başarılı sipariş” gibi gösterebilir. Bu risk özellikle e-ticaret, dijital ürün teslimatı, lisans aktivasyonu ve otomatik faturalama süreçlerinde doğrudan gelir kaybına yol açabilir.

Webhook doğrulaması yapılmazsa sahte sipariş bildirimi mümkün mü?

Evet, mümkündür. Webhook endpoint’i dışarıya açık bir URL’dir. Eğer gelen isteğin gerçekten ödeme sağlayıcısından veya güvenilir entegrasyon servisinden geldiği kontrol edilmiyorsa, saldırgan bu adrese benzer formatta veri gönderebilir. Sisteminiz bu veriyi sorgulamadan kabul ederse siparişi onaylayabilir, stok düşebilir, dijital ürün teslim edilebilir veya kullanıcıya ücretli bir hizmet açılabilir.

Bu nedenle webhook yalnızca “veri geldi” mantığıyla çalıştırılmamalıdır. Gelen isteğin kaynağı, bütünlüğü, zamanı ve işlem kimliği kontrol edilmelidir. Güvenli bir hosting altyapısı bu kontrolleri destekler; fakat asıl güvenlik, uygulama seviyesinde doğru doğrulama yapılmasıyla sağlanır.

Sahte webhook bildirimi nasıl gerçekleşir?

Saldırgan genellikle sitenin webhook URL’sini tespit etmeye çalışır. Bu URL bazen eklenti ayarlarında, hata mesajlarında, log kayıtlarında veya tahmin edilebilir adres yapılarında ortaya çıkabilir. Ardından ödeme sağlayıcısının gönderdiğine benzeyen bir HTTP isteği hazırlanır.

Örneğin saldırgan, sipariş numarası, ödeme durumu, tutar ve kullanıcı bilgisi içeren sahte bir JSON gövdesi gönderebilir. Eğer sisteminiz bu isteği imza, token veya API üzerinden ikinci doğrulama yapmadan işlerse sahte sipariş gerçekmiş gibi kabul edilebilir.

En sık yapılan hatalar

Webhook güvenliğinde en yaygın hata, yalnızca sipariş durum alanına güvenmektir. “paid”, “success” veya “completed” gibi değerler tek başına kanıt değildir. Bir diğer hata, IP adresi kontrolünü tek güvenlik katmanı olarak kullanmaktır. IP filtreleme faydalıdır; ancak servis sağlayıcı IP aralıkları değişebilir veya yanlış yapılandırma nedeniyle güvenlik boşluğu oluşabilir.

Ayrıca test ortamındaki webhook anahtarının canlı ortamda kullanılması, loglarda gizli anahtarların açık görünmesi ve tekrar gönderilen eski webhook bildirimlerinin yeniden işlenmesi de ciddi problemlere neden olur.

Güvenli webhook doğrulaması için temel kontroller

Sağlam bir yapı için ilk adım, sağlayıcının sunduğu imza doğrulama mekanizmasını kullanmaktır. Çoğu ödeme sistemi HMAC, secret key veya benzer kriptografik imza yöntemleri sunar. Sunucu gelen isteğin gövdesini alır, kendi gizli anahtarıyla imzayı yeniden üretir ve gönderilen imzayla karşılaştırır.

İkinci adım, işlem bilgisini sağlayıcının API’si üzerinden tekrar kontrol etmektir. Webhook “ödeme başarılı” dese bile uygulama, ilgili transaction ID için ödeme durumunu, tutarı, para birimini ve sipariş numarasını sağlayıcı sisteminden doğrulamalıdır.

Kontrol edilmesi gereken alanlar

İşlem kimliği benzersiz olmalı ve daha önce işlenmemiş olmalıdır. Tutar ve para birimi, sipariş kaydındaki değerlerle birebir eşleşmelidir. Sipariş durumu yalnızca beklenen geçişlere izin vermelidir; örneğin iptal edilmiş bir sipariş webhook ile tekrar tamamlandıya çevrilmemelidir.

Zaman damgası da önemlidir. Çok eski bir webhook bildirimi tekrar gönderildiğinde sisteminiz bunu yeni bir işlem gibi kabul etmemelidir. Bu yaklaşım replay attack olarak bilinen tekrar saldırılarına karşı koruma sağlar.

WordPress ve e-ticaret sitelerinde dikkat edilmesi gerekenler

WordPress üzerinde WooCommerce veya özel e-ticaret eklentileri kullanılıyorsa webhook endpoint’leri genellikle eklenti tarafından yönetilir. Burada kritik nokta, ödeme eklentisinin güncel olması ve resmi doğrulama yöntemlerini desteklemesidir. Eski veya terk edilmiş eklentiler, webhook güvenliğinde eksik kontroller barındırabilir.

Özel geliştirme yapılıyorsa, webhook işlemleri doğrudan sipariş onayına bağlanmamalıdır. Önce doğrulama yapılmalı, ardından sipariş kaydı güvenli şekilde güncellenmelidir. Hata durumlarında kullanıcıya gereksiz teknik detay gösterilmemeli; ancak sistem loglarına yeterli iz bırakılmalıdır.

Sunucu tarafında alınabilecek ek önlemler

Uygulama doğrulamasına ek olarak güvenlik duvarı, rate limit, HTTPS zorunluluğu ve erişim logları kullanılmalıdır. hosting tarafında güncel PHP sürümü, güvenli TLS yapılandırması ve düzenli yedekleme de operasyonel güvenliği güçlendirir.

IP izin listesi kullanılacaksa bu liste ödeme sağlayıcının resmi dokümantasyonuna göre yönetilmeli ve periyodik olarak kontrol edilmelidir. Ancak IP filtresi, imza doğrulamasının yerine geçmemelidir; yalnızca ek güvenlik katmanı olarak değerlendirilmelidir.

Pratik bir doğrulama akışı nasıl kurulmalı?

Gelen webhook isteği alındığında önce ham gövde okunmalı, imza başlığı kontrol edilmeli ve gizli anahtarla karşılaştırma yapılmalıdır. İmza geçersizse istek işlenmemeli ve sipariş durumu değiştirilmemelidir. İmza geçerliyse işlem kimliğiyle sağlayıcı API’sine sorgu gönderilmeli, sipariş tutarı ve durum bilgisi eşleştirilmelidir.

Daha sonra aynı işlem kimliğinin daha önce işlenip işlenmediği kontrol edilmelidir. Bu kontrol yapılmazsa sağlayıcının aynı bildirimi tekrar göndermesi stok, fatura veya teslimat süreçlerinde mükerrer işlem oluşturabilir.

Canlıya almadan önce başarısız imza, yanlış tutar, eski zaman damgası, tekrar eden işlem kimliği ve geçersiz sipariş numarası senaryoları test edilmelidir. Böylece yalnızca başarılı akış değil, saldırıya açık olabilecek kenar durumlar da güvence altına alınır.

Webhook doğrulaması, ödeme güvenliğinin küçük bir detayı değil, sipariş bütünlüğünü koruyan temel kontroldür. Doğru imza kontrolü, API üzerinden ikinci doğrulama, tekrar saldırısı önleme ve sağlıklı loglama birlikte kullanıldığında sahte sipariş bildirimi riski ciddi ölçüde azaltılır; ekipler de olası hataları daha hızlı tespit eder.