Webhook Nedir? Sunucu Tarafında Güvenli Webhook Yönetimi Rehberi
Webhook Nedir? Sunucu Tarafında Güvenli Webhook Yönetimi Rehberi
Son Güncelleme: Nisan 2026
Webhook, bir sistemde gerçekleşen olayın başka bir sisteme otomatik olarak bildirilmesini sağlayan olay tabanlı iletişim yöntemidir. Özellikle sunucu entegrasyonları, otomasyon, ödeme bildirimleri, stok senkronizasyonu ve uygulamalar arası veri akışı için kritik öneme sahiptir. Bu rehberde webhook mantığını, güvenlik risklerini, doğrulama yöntemlerini, loglama yaklaşımını ve üretim ortamında en iyi uygulamaları detaylı şekilde ele alacağız.
İçindekiler
- Webhook Nedir?
- Webhook Nasıl Çalışır?
- Webhook ve API Arasındaki Fark
- Webhook Kullanım Alanları
- Webhook Güvenlik Riskleri
- Doğrulama ve İmza Kontrolü
- Idempotency ve Yeniden Deneme Mantığı
- Loglama ve İzleme
- Örnek Mimari ve Uygulama Akışı
- Webhook Servisleri İçin Sunucu Seçimi
- En İyi Uygulamalar
- Sıkça Sorulan Sorular
- Sonuç
Webhook Nedir?
Webhook, bir uygulamanın belirli bir olay gerçekleştiğinde önceden tanımlanmış bir URL adresine HTTP isteği göndermesidir. Türkçe karşılığıyla bunu olay tetiklemeli bildirim mekanizması olarak düşünebilirsiniz. Yani bir sistemde “bir sipariş oluşturuldu”, “ödeme başarılı oldu”, “kullanıcı kaydoldu” ya da “depo stoğu güncellendi” gibi bir olay meydana geldiğinde, başka bir sistem bu gelişmeden anında haberdar edilir.
Geleneksel sorgulama modelinde istemci tarafı düzenli aralıklarla “yeni bir şey oldu mu?” diye sunucuya sorar. Webhook yaklaşımında ise sistem, olay gerçekleştiği anda karşı tarafa haber verir. Bu yapı hem kaynak tüketimini azaltır hem de gerçek zamana yakın veri akışı sağlar.
Özellikle e-ticaret, SaaS platformları, ödeme sistemleri, CI/CD süreçleri, CRM araçları ve otomasyon servislerinde webhook kullanımı yaygındır. Uygulamalar arası entegrasyon kurmak isteyen ekipler için webhook, çoğu zaman API kadar önemli bir bileşendir.
Webhook Nasıl Çalışır?
Webhook çalışma mantığı oldukça nettir ancak üretim ortamında doğru kurgulanması gerekir. Temel akış şu şekilde işler:
- Olay oluşur: Kaynak sistemde belirli bir tetikleyici meydana gelir. Örneğin bir ödeme başarılı olur.
- HTTP isteği hazırlanır: Kaynak sistem, hedef URL adresine genellikle
POSTisteği yollar. - Veri iletilir: Olay detayları çoğunlukla
JSONformatında iletilir. - Hedef sunucu doğrulama yapar: İmza (signature), gizli anahtar (secret), IP kontrolü veya token doğrulaması uygulanır.
- İstek işlenir: Sipariş oluşturma, kayıt güncelleme, bildirim üretme veya kuyruk sistemine ekleme yapılır.
- Yanıt döndürülür: Hedef sistem genellikle
200 OKya da uygun bir HTTP durum kodu döndürür.
Basit bir webhook isteği örneği şu yapıda olabilir:
POST /webhook/odeme HTTP/1.1
Host: example.com
Content-Type: application/json
X-Signature: sha256=ornekimzadegeri
{
"event": "payment.success",
"order_id": "ORD-1024",
"amount": 1499.90,
"currency": "TRY",
"customer_email": "musteri@example.com"
}
Burada önemli olan konu, isteğin sadece alınması değil; güvenli, doğrulanmış ve tekrar işlenmeye karşı korumalı şekilde ele alınmasıdır. Aksi halde aynı olay birden fazla işlenebilir veya kötü niyetli talepler sisteme sızabilir.
Webhook ve API Arasındaki Fark
Webhook ve API kavramları sıkça karıştırılır. Aslında ikisi birbirini tamamlar fakat çalışma mantıkları farklıdır. API, istemcinin ihtiyaç duyduğu anda sunucuya istek gönderdiği yapıdır. Webhook ise olay olduğunda sunucunun karşı tarafa bildirim yaptığı yöntemdir.
| Özellik | API | Webhook |
|---|---|---|
| İletişimi başlatan taraf | İstemci | Kaynak sistem |
| Çalışma modeli | Sorgulama (polling) | Olay tabanlı bildirim |
| Gecikme | Sorgu sıklığına bağlı | Düşük, çoğu zaman anlık |
| Kaynak tüketimi | Daha yüksek olabilir | Daha verimli olabilir |
| Kullanım amacı | Veri almak/göndermek | Olay bildirimi yapmak |
Örneğin bir e-ticaret sitesi, ödeme sağlayıcısına API üzerinden işlem başlatabilir. Ancak ödemenin sonucunu sürekli sormak yerine, ödeme sağlayıcısı sonucu webhook ile bildirir. Böylece sistem hem daha hızlı tepki verir hem de gereksiz istek yükünden kurtulur.
Webhook Kullanım Alanları
Webhook teknolojisi farklı sektörlerde çok geniş kullanım alanına sahiptir. Özellikle mikro servis (microservice) mimarisi, entegrasyon projeleri ve otomasyon tabanlı iş akışlarında önemli rol oynar.
E-ticaret Sistemleri
- Ödeme bildirimi: Siparişin ödendiği bilgisinin mağaza altyapısına aktarılması.
- Kargo güncellemesi: Kargo firmasından teslimat durumlarının alınması.
- Stok senkronizasyonu: Farklı satış kanalları arasında ürün adetlerinin eşitlenmesi.
SaaS ve Üyelik Platformları
- Abonelik durumu: Yenileme, iptal veya başarısız tahsilat olaylarının iletilmesi.
- Kullanıcı yaşam döngüsü: Yeni kullanıcı kaydı, doğrulama veya plan yükseltme süreçleri.
DevOps ve Yazılım Geliştirme
- CI/CD tetikleme: Depoya kod gönderildiğinde otomatik test ve dağıtım başlatılması.
- Alarm ve otomasyon: İzleme sistemi kritik hata gördüğünde mesajlaşma veya ticket sistemi tetiklenmesi.
CRM ve Pazarlama
- Lead aktarımı: Form dolduran kullanıcı bilgisinin CRM sistemine anlık iletilmesi.
- Kampanya akışları: Belirli kullanıcı davranışlarına göre otomatik e-posta veya SMS başlatılması.
Webhook kullanımı, özellikle manuel işlem yükünü azaltmak ve entegrasyon gecikmesini düşürmek isteyen işletmeler için ciddi avantaj sağlar.
Webhook Güvenlik Riskleri
Webhook uç noktaları (endpoint), dış dünyadan istek kabul ettiği için ciddi güvenlik riskleri barındırır. En yaygın hata, “URL gizliyse yeterince güvenlidir” düşüncesidir. Oysa yalnızca URL’nin bilinmemesi bir güvenlik kontrolü değildir.
Başlıca riskler
- Sahte istekler: Yetkisiz bir kaynaktan gelen ama meşru webhook gibi görünen HTTP talepleri.
- Replay attack (tekrar oynatma saldırısı): Geçerli bir isteğin sonradan tekrar gönderilmesi.
- Çift işleme: Aynı olayın birden fazla kez uygulanması nedeniyle siparişin iki kez oluşturulması gibi problemler.
- Payload manipülasyonu: İstek içeriğinin yolda veya istemci tarafında değiştirilmesi.
- DDoS ve kaynak tüketimi: Açık webhook uç noktasına aşırı istek gönderilmesi.
- Hatalı loglama: Hassas verilerin düz metin olarak kayıt altına alınması.
Bu nedenle webhook uç noktaları yalnızca çalışıyor olmalı değil; aynı zamanda kimlik doğrulama, bütünlük kontrolü, oran sınırlama (rate limiting), izleme ve hata yönetimi mekanizmalarıyla korunmalıdır.
Doğrulama ve İmza Kontrolü
Webhook güvenliğinin temelini isteğin gerçekten beklenen kaynaktan gelip gelmediğini doğrulamak oluşturur. Bunun için yaygın olarak şu yöntemler kullanılır:
Gizli anahtar ile HMAC imzası
En güvenli yöntemlerden biri, istek gövdesinin (payload) paylaşılmış gizli anahtar ile HMAC algoritması kullanılarak imzalanmasıdır. Hedef sunucu aynı veriyi aynı anahtarla yeniden hesaplar ve gelen imza ile karşılaştırır.
payload="raw request body"
secret="super-secret-key"
signature=$(echo -n "$payload" | openssl dgst -sha256 -hmac "$secret")
Uygulama tarafında yapılması gerekenler:
- Ham gövdeyi koruyun: JSON parse edilmeden önce raw body alın.
- Sabit zamanlı karşılaştırma kullanın: Timing attack (zamanlama saldırısı) riskini azaltın.
- Zaman damgası kontrol edin: Çok eski istekleri reddedin.
IP adresi doğrulaması
Bazı servisler webhook isteklerini sabit IP bloklarından gönderir. Sunucu güvenlik duvarında (firewall) veya uygulama katmanında yalnızca bu IP’lere izin vermek ek koruma sağlayabilir. Ancak tek başına yeterli değildir; IP kontrolü değişebilir veya proxy arkasında karmaşıklaşabilir.
Bearer token veya özel başlık
Bazı sistemler Authorization başlığı veya özel bir token ile kimlik doğrulama yapar. Bu yöntem kullanılabilir ancak imza doğrulamasına göre daha sınırlı güvenlik sağlar çünkü payload bütünlüğünü tek başına garanti etmez.
TLS/HTTPS zorunluluğu
Webhook uç noktaları mutlaka HTTPS üzerinden yayınlanmalıdır. Geçerli bir sertifika ile şifreli iletişim sağlamak için SSL Sertifikası kullanmak, veri bütünlüğü ve gizliliği açısından temel gereksinimdir.
Idempotency ve Yeniden Deneme Mantığı
Webhook sistemlerinde en kritik kavramlardan biri idempotency, yani aynı isteğin birden fazla kez gelse bile sonucu değiştirmeden tek işlem gibi ele alınabilmesidir. Birçok sağlayıcı, hedef sunucu zamanında yanıt vermezse veya hata dönerse webhook’u otomatik olarak yeniden gönderir.
Eğer sisteminiz aynı siparişi, ödemeyi veya kullanıcı kaydını tekrar tekrar işlerse veri tutarsızlığı oluşur. Bu yüzden her webhook olayının benzersiz bir olay kimliği (event ID) ile takip edilmesi gerekir.
İyi bir idempotency yaklaşımı
- Olay kimliği saklayın: Her webhook isteğinin benzersiz anahtarını veritabanında kaydedin.
- Tekrar gelen isteği tanıyın: Aynı event ID daha önce işlendi ise işlemi tekrarlamayın.
- Atomic işlem kullanın: Veritabanında yarış koşullarına (race condition) karşı dikkatli olun.
- Kuyruk sisteminden yararlanın: İstek kabulü ile işleme adımını birbirinden ayırın.
Örnek pseudo akış şu şekilde olabilir:
1. Webhook isteğini al
2. İmzayı doğrula
3. event_id veritabanında var mı kontrol et
4. Varsa 200 dön ve tekrar işleme
5. Yoksa kaydet
6. Olayı kuyruğa gönder
7. Asenkron olarak işle
8. İşlem sonucunu logla
Bu yaklaşım, yoğun trafik altında daha kararlı çalışır ve dış servislerin retry (yeniden deneme) mantığıyla uyumludur.
Loglama ve İzleme
Webhook altyapısında sorun çözmenin anahtarı doğru loglama ve izleme sistemidir. “Webhook çalışmıyor” şikayetinin kaynağı çoğu zaman aslında ağ problemi, imza doğrulama hatası, zaman aşımı ya da uygulama mantığındaki beklenmeyen bir durumdur.
Loglarda neler tutulmalı?
- İstek zamanı: Webhook’un sunucuya ulaştığı an.
- Olay türü: Örneğin
payment.successveyasubscription.cancelled. - Olay kimliği: Tekrar işleme tespiti için.
- Doğrulama sonucu: İmza geçti mi, başarısız mı oldu?
- HTTP durum kodu: Uygulamanın verdiği yanıt.
- İşleme süresi: Performans analizi için.
Ancak burada dikkat edilmesi gereken önemli nokta, hassas verileri maskelemek veya hiç loglamamaktır. Kart bilgileri, kimlik numaraları, token değerleri, gizli anahtarlar ve tam kişisel veri içerikleri doğrudan log dosyasına yazılmamalıdır.
Üretim ortamında webhook uç noktalarının izlenmesi için merkezi loglama, metrik toplama ve alarm üretimi yaklaşımı benimsenmelidir. Yüksek erişilebilirlik gerektiren projelerde bu servisleri Kiralık Sunucu veya ölçeklenebilir Sanal Sunucu altyapısı üzerinde konumlandırmak operasyonel kolaylık sağlar.
Örnek Mimari ve Uygulama Akışı
Sağlıklı bir webhook mimarisi, istek alındığı anda tüm işi yapmak yerine yükü katmanlara ayırmalıdır. Özellikle yoğun trafik alan platformlarda senkron işlem yaklaşımı darboğaz yaratır.
Önerilen mimari bileşenleri
- Load balancer (yük dengeleyici): Gelen trafiği birden fazla uygulama sunucusuna dağıtır.
- Webhook receiver: Yalnızca doğrulama yapan ve isteği kabul eden hafif servis.
- Message queue (mesaj kuyruğu): İstekleri arka planda güvenli şekilde sıralar.
- Worker servisleri: Olayları asenkron işler.
- Database: Event ID, işlem durumu ve hata kayıtlarını tutar.
- Monitoring: Metrik, log ve alarm katmanı.
Basitleştirilmiş akış:
Webhook Provider
|
v
HTTPS Endpoint
|
v
Signature Verification
|
v
Queue
|
v
Worker
|
+-- Sipariş Güncelle
+-- E-posta Gönder
+-- CRM Kaydı Aç
+-- Log/Metrik Yaz
Bu yapı sayesinde webhook isteğine hızlıca 200 OK dönülebilir, ağır işlemler ise arka planda tamamlanır. Böylece timeout (zaman aşımı) riski ve yeniden deneme trafiği azalır.
Webhook Servisleri İçin Sunucu Seçimi
Webhook sistemleri için doğru altyapı seçimi, beklenen trafik ve işlem yoğunluğuna göre yapılmalıdır. Küçük ölçekli projelerde tek bir uygulama sunucusu yeterli olabilirken, yüksek hacimli entegrasyonlarda daha dayanıklı mimariler gerekir.
Hangi senaryoda hangi yapı uygundur?
- Küçük ve orta ölçekli projeler: API ve webhook işlemlerini tek bir Türkiye VPS Sunucu üzerinde başlatmak maliyet açısından uygundur.
- Kaynak izolasyonu gereken projeler: Garantili kaynak ve daha kararlı performans için Türkiye VDS Sunucu tercih edilebilir.
- Yoğun trafik ve kurumsal entegrasyonlar: Ayrı uygulama, kuyruk ve veritabanı katmanları için Türkiye Kiralık Sunucu veya Bulut Sunucu daha esnek olabilir.
- Linux tabanlı uygulama servisleri: Node.js, PHP veya Python tabanlı webhook alıcıları için Linux Hosting başlangıç seviyesi projelerde değerlendirilebilir; ancak ileri seviye webhook işleme için genellikle VPS/VDS daha uygundur.
Sunucu seçimi yaparken sadece CPU ve RAM’e değil; ağ gecikmesi, disk I/O, yedekleme, DDoS koruması ve ölçeklenebilirlik gibi kriterlere de bakılmalıdır. Veri güvenliği için düzenli Yedekleme Hizmeti kullanılması da önemlidir.
En İyi Uygulamalar
Webhook mimarisini üretim ortamında güvenli ve sürdürülebilir şekilde çalıştırmak için aşağıdaki uygulamalar önerilir:
- HTTPS zorunlu kullanın: Şifrelenmemiş iletişimi tamamen kapatın.
- HMAC imza doğrulaması yapın: Mümkünse payload bütünlüğünü garanti eden yöntem tercih edin.
- Ham isteği saklayın: Adli inceleme ve hata analizi için kontrollü şekilde raw payload arşivleyin.
- Idempotency uygulayın: Aynı event’in tekrar işlenmesini önleyin.
- Kuyruk mekanizması kullanın: Webhook endpoint’i hızlı yanıt versin, ağır işler arka planda çalışsın.
- Timeout sürelerini optimize edin: Sağlayıcının beklentilerine göre hızlı dönüş yapın.
- Retry farkındalığı geliştirin: Başarısız isteklerin yeniden geleceğini varsayarak tasarım yapın.
- Rate limiting uygulayın: Aşırı trafik ve kötüye kullanım girişimlerini sınırlayın.
- Gizli verileri loglamayın: Maskelenmiş veya özetlenmiş kayıt tercih edin.
- Test ve staging ortamı kurun: Canlıya almadan önce webhook senaryolarını güvenli ortamda doğrulayın.
Özellikle finansal işlemler, lisans aktivasyonları, üyelik yönetimi ve otomasyon süreçlerinde webhook hataları doğrudan gelir kaybına veya operasyonel probleme yol açabilir. Bu nedenle webhook tasarımı, “küçük bir entegrasyon detayı” değil; doğrudan altyapı mimarisinin parçası olarak değerlendirilmelidir.
Sıkça Sorulan Sorular
Webhook ile API aynı şey midir?
Hayır. API genellikle istemcinin veri almak veya işlem başlatmak için yaptığı çağrıdır. Webhook ise bir olay gerçekleştiğinde sistemin başka bir sisteme otomatik bildirim göndermesidir.
Webhook neden güvenlik riski oluşturabilir?
Çünkü internet üzerinden erişilebilen bir uç noktaya dış sistemler istek gönderir. İmza doğrulaması, HTTPS, IP filtreleme ve tekrar işleme koruması yoksa sahte veya zararlı istekler sisteme ulaşabilir.
Webhook istekleri neden birden fazla kez gelir?
Birçok sağlayıcı, hedef sistem zamanında yanıt vermezse veya hata döndürürse isteği yeniden yollar. Bu nedenle idempotency tasarımı uygulanmalı ve aynı olay yalnızca bir kez işlenmelidir.
Webhook için VPS mi VDS mi tercih edilmeli?
Küçük ve orta ölçekli projelerde VPS yeterli olabilir. Ancak daha kararlı performans, kaynak garantisi ve yoğun entegrasyon yükü için VDS veya kiralık sunucu tercih edilmesi daha doğru olur.
Webhook endpoint doğrudan veritabanına yazmalı mı?
Basit senaryolarda mümkün olsa da en iyi yaklaşım önce doğrulama yapıp isteği kuyruk sistemine aktarmaktır. Ağır işlemlerin arka planda yürütülmesi performans ve güvenilirlik açısından daha iyidir.
Webhook loglarında hangi veriler tutulmamalıdır?
Gizli anahtarlar, token değerleri, ödeme verileri, kişisel hassas bilgiler ve güvenlik açısından kritik başlıklar açık biçimde loglanmamalıdır. Gerekirse maskeleme uygulanmalıdır.
Sonuç
Webhook, modern uygulama entegrasyonlarının en pratik ve güçlü bileşenlerinden biridir. Doğru tasarlandığında sistemler arasında hızlı, düşük gecikmeli ve otomatik veri akışı sağlar. Ancak bu gücün sürdürülebilir olabilmesi için güvenlik doğrulaması, idempotency, asenkron işleme, izleme ve doğru sunucu altyapısı birlikte düşünülmelidir.
Eğer webhook tabanlı servisler, API altyapıları, otomasyon sistemleri veya yüksek trafikli entegrasyon projeleri için uygun bir altyapı arıyorsanız Corelux’in Sanal Sunucu, Kiralık Sunucu, Bulut Sunucu ve SSL Sertifikası çözümleriyle güvenli ve ölçeklenebilir bir yapı kurabilirsiniz. Projenizin büyüklüğüne uygun altyapıyı seçmek, entegrasyon başarısında doğrudan fark yaratacaktır.
Yazar
Boran BAR