Proje vitrini hazırlanıyorPreparing project showcaseПодготавливаем витрину проекта

Entegrasyonlar

Webhook güvenliği: imza doğrulama ve tekrar saldırısını önleme

Küçük işletmeler için webhook güvenliği rehberi: imzaları doğrulayın, tekrar saldırılarını durdurun ve CRM'inize yalnızca gerçek olaylar ulaşsın.

Rocketly · 2026-07-18

Açtığınız her entegrasyon, işletmenizin arkasına küçük bir kapı ekler. Bir ödeme onayı, çevrim içi mağazanızdan gelen yeni bir sipariş, bir form gönderimi, bir kargo güncellemesi — bunların hepsi webhook olarak gelir: bir sistemin, bir şey olduğu anda başka bir sisteme gönderdiği minik otomatik mesajlar. Son derece kullanışlıdırlar ve aynı zamanda çoğu işletme sahibinin hakkında hiç düşünmediği kısımdır. İşte tam da bu yüzden webhook güvenliği sade bir dille konuşulmayı hak ediyor.

Bu yazı, sizi kodun içinde boğmadan, sistemlerinize ulaşan mesajların gerçekten sahici olduğundan nasıl emin olacağınızı anlatıyor: imza doğrulama nedir, paylaşılan bir sır ile HMAC bir isteğin kimden geldiğini nasıl kanıtlar ve bir zaman damgası ile küçük bir hafıza, saldırganların eski bir mesajı tekrar oynatmasını neden engeller. Amaç sizi mühendise dönüştürmek değil. Amaç, CRM'inize ya da geliştiricinize doğru iki üç soruyu sorabilmenizi sağlamak.

Webhook aslında nedir

Bir webhook'u iki uygulama arasındaki otomatik bir telefon görüşmesi gibi düşünün. Bir müşteri ödeme yaptığında, ödeme sağlayıcınız CRM'inizi "arar" ve şöyle der: 4471 numaralı sipariş ödendi. CRM'iniz açar, ödemeyi kaydeder, belki bir teşekkür mesajı yollar. Kimse hiçbir yere tıklamaz. Bütün mesele hız — güncelleme, birinin panoyu kontrol etmesini beklemek yerine saniyeler içinde yerine oturur.

İşin püf noktası şu: bu çağrı herkese açık bir adrese gelir — açık internette bekleyen bir URL'ye. Bu adresi öğrenen herkes de o numarayı çevirebilir. Ve telefondaki bir insanın aksine, sistemleriniz arayanın "sesinin doğru gelip gelmediğini" duyamaz. Webhook, bir kapıya ulaşan düz bir metinden ibarettir. Kimin gönderdiğini kontrol etmenin bir yolu olmadan, CRM'iniz bir yabancıya seve seve inanır.

CRM'inizÇevrim içi mağazaÖdemeWeb formuKargo
Tek bir webhook adresi çoğu zaman birçok dış sistemden aynı anda olay alır.

Webhook'ların bu kadar çok kurulumun kalbinde olmasının nedeni budur. CRM'inize bağladığınız çevrim içi mağazadan gerçek bir sipariş alan aynı kapı, açık bırakılırsa sahte bir sipariş de alabilir. Kolaylık ve risk aynı yerden gelir.

Asıl risk: adresi bilen herkes kapıyı çalabilir

Tehdit konusunda dürüst olalım, çünkü korku pazarlamak kimseye fayda sağlamaz. İki kişilik bir emlak ofisini adıyla hedef alan biri pek olası değil. Ama webhook adresleri sıradan yollarla sızar: bir destek sohbetindeki ekran görüntüsü, herkese açık bir kod deposuna yapıştırılan bir bağlantı, bir tarayıcı eklentisi, eski bir çalışanın dizüstü bilgisayarı. Adres bir kez dışarı çıktığında, otomatik bir betik canı ne isterse gönderebilir.

Sahte bir mesaj ne yapabilir? Bu, webhook'unuzun neyi tetiklediğine bağlı. Sahte bir "ödeme alındı" mesajı, ödenmemiş bir faturayı ödenmiş gibi işaretleyip ürünü bedavaya gönderebilir. Sahte bir "yeni potansiyel müşteri" akışınızı çöple doldurabilir. Uydurma bir "sipariş iptal edildi" gerçek bir sevkiyatı durdurabilir. Bunların hiçbiri dâhi bir korsan gerektirmez — sadece açık bir kapı ve mesaj biçimine dair bir tahmin yeter.

Doğrulaması olmayan bir webhook, herkesin basabildiği ve gerçekten önemli bir şeye bağlı bir kapı zilidir.

Matematiğe girmeden imza doğrulama

İşte zarif kısım. Yabancıları adresi gizleyerek durdurmuyorsunuz — adresler her zaman sızar. Onları, her gerçek mesajın yalnızca sahici gönderenin üretebileceği bir mühür taşımasını sağlayarak durduruyorsunuz. Bu mühre imza denir ve arkasındaki yaygın yönteme HMAC adı verilir.

Bunu, yalnızca iki kişinin sahip olduğu bir kaşeden basılan mum mühür gibi düşünün. Bir webhook kurarken, siz ve gönderen bir paylaşılan sır üzerinde anlaşırsınız — internette hiçbir zaman açıkça dolaşmayan, uzun ve rastgele bir parola. Her mesaj için gönderen, mesaj içeriğini bu sırla harmanlar ve kısa bir parmak izi üretir. Bu parmak izini isteğe iliştirir. Sizin tarafınız da aldığı mesajı aynı sırla harmanlar ve kendi parmak izini üretir. İkisi eşleşiyorsa mesaj gerçektir ve dokunulmamıştır. Tek bir karakter bile farklıysa, mesajı çöpe atarsınız.

1Olay olur2Sırla imzala3İstek gelir4Mührü hesapla5Eşleşince kabul et
Doğrulama iki parmak izini karşılaştırır; eşleşeni yalnızca gerçek gönderen üretebilir.

Bunu güçlü kılan iki şey var. Birincisi, sır hiçbir zaman gönderilmez, dolayısıyla araya giren biri onu kopyalayamaz. İkincisi, parmak izi tam içeriğe bağlıdır; yani biri tutarın tek bir hanesini bile değiştirse mühür kırılır. Bunu talep etmek için kriptografiyi anlamanıza gerek yok. Sadece sisteminizin bir mesaja güvenmeden önce imzayı kontrol ettiğinden — ve başarısız olan her şeyi reddettiğinden — emin olmanız yeterli.

Geçerli bir imza neden yetmez: tekrar saldırıları

Şimdi ince mesele. Diyelim ki bir saldırgan mühür üretemiyor, ama geçip giderken gerçek, doğru imzalanmış bir mesajı — mesela hakiki bir "ödeme alındı" mesajını — yakalamayı başarıyor. Aynı mesajı bir saat sonra on kez tekrar göndermesini engelleyen ne? İmza kusursuz biçimde geçerli, çünkü gerçek bir imza. Buna tekrar saldırısı denir ve imzalar tek başına bunu engellemez.

Çözüm, her mesaja bir zaman ve kimlik duygusu vermek. İki basit alışkanlık işin çoğunu halleder:

  • Kısa pencereli zaman damgaları. Gönderen her isteği o anki zamanla damgalar ve bu zamanı imzalanan içeriğin bir parçası yapar. Sizin tarafınız birkaç dakikadan eski her şeyi reddeder. Yakalanan bir mesaj çabucak bayatlar, tıpkı seansı çoktan bitmiş bir sinema bileti gibi.
  • Daha önce gördüğünüzü hatırlayın. Her olay benzersiz bir kimlik taşır. Sisteminiz işlediği kimlikleri not eder ve aynısını iki kez işlemeyi reddeder. Taze görünen bir tekrar bile yakalanır, çünkü onu tanırsınız.

Bu ikisine birlikte çoğu zaman tekrar koruması denir ve sonsuza dek geçerli bir mesajı, yalnızca bir kez ve yalnızca bir an için geçerli hâle getirir. Ciddi webhook sağlayıcılarının çoğu zaten bir zaman damgası ve bir olay kimliği gönderir; iş, sizin tarafınızın bunları gerçekten kontrol etmesini sağlamaktır.

Kapıyı kilitlemek için kısa bir kontrol listesi

İlk günden bunların hepsine ihtiyacınız yok, ama olgun bir kurulumda çoğu bulunur. Küçük bir işletme için "yeterince güvenli" genelde şöyle görünür:

  • Her zaman HTTPS kullanın. Webhook'unuzun bulunduğu adres https ile başlamalı ki mesaj size gelirken şifrelensin ve yolda okunamasın ya da değiştirilemesin.
  • İmzayı her seferinde doğrulayın. İstisna yok, "sonra ekleriz" yok. Kontrolü atlayan bir uç nokta, açığın ta kendisidir.
  • Bir zaman penceresi uygulayın ve olay kimliklerini izleyin. Bu sizin tekrar korumanızdır ve bir kez kurulduktan sonra neredeyse hiçbir maliyeti yoktur.
  • Sırrı sır olarak saklayın. Onu parolaların durduğu yerde tutun; asla bir ekran görüntüsünde, bir sohbet mesajında ya da herkese açık kodda değil. Onu bilen biri işten ayrılırsa sırrı yenileyin.
  • Hızlı yanıt verin, dikkatli davranın. Mesajı hızlıca teslim aldığınızı bildirin, ama asıl işi — sevkiyat, iade — yalnızca doğrulama geçtikten sonra yapın.

Entegrasyonlarınızın arka kapısını kapatın

Rocketly, imzalı webhook'ları doğrular ve tekrarları engeller; böylece CRM'inize yalnızca gerçek olaylar ulaşır.

Rocketly entegrasyonları nasıl koruyor

Bu ne zaman aşırıya kaçar — ve ne zaman kesinlikle kaçmaz

Dürüst olmak gerekirse, her webhook bir kaleye ihtiyaç duymaz. Bir mesaj yalnızca kimsenin otomatik olarak üzerine iş yapmadığı iç bir panoyu güncelliyorsa, sızan bir sahtesi size kafa karıştıran bir grafikten fazlasına mal olmaz. Bunun için bir hafta boyunca elle kriptografik kontroller inşa etmek kötü bir takas olur.

Dikkat edilecek çizgi basit: webhook para, stok ya da müşterilere giden mesajları mı tetikliyor? Ürün serbest bırakan bir "ödeme alındı", stok ayıran bir "yeni sipariş", tüm müşteri listenize SMS atan bir tetikleyici — bunlar tartışmasız biçimde tam doğrulama ve tekrar koruması hak eder. Kapının öbür ucunda gerçek dünya sonuçları varsa, kilit isteğe bağlı değildir.

Yap-mı-satın-al-mı sorusu da tam burada devreye girer. yerel bir entegrasyonu üçüncü parti bir araçla tartıyorsanız ya da Zapier ile Make gibi otomasyon platformlarını karşılaştırıyorsanız, güvenlik yaklaşımı onları değerlendirmek için adil bir ölçüttür. İyi bir platform doğrulamayı, keşfetmeniz gereken bir ayar değil, varsayılan hâline getirir.

İyi çalışan bir CRM sizin için ne yapar

Teknik olmayan bir işletme sahibi için rahatlatıcı haber: bunların çoğu görünmez olmalı. Parmak izlerini elle hesaplıyor olmamalısınız. web formunuz CRM'inize potansiyel müşteri beslediğinde ya da kargonuzdan bir teslimat güncellemesi aktığında, platform her mesajı doğrulamalı, bayat veya çift olanları reddetmeli ve sessizce geri çevirdiği çöpten size hiç söz etmemeli.

Yani pratik hamle kriptografi öğrenmek değil. Webhook'larınızı alan aracın hangisi olursa olsun ona üç soru sormak: Gelen her olayda imzaları doğruluyor musunuz? Eski ya da tekrarlanan mesajları reddediyor musunuz? Ve sızarsa sırrı kendim yenileyebilir miyim? Net yanıtlar kapının kilitli olduğu anlamına gelir. Muğlak yanıtlar, özellikle webhook'u iki sistemi düzgün bir iki yönlü veri senkronizasyonuyla eşleştiren bir şeye bağlamadan önce, daha yakından bakmaya değer demektir.

Sıkça sorulan sorular

Tahmin edilmesi zor bir webhook adresi tek başına yeterli mi?

Hayır. Uzun ve rastgele bir URL çıtayı biraz yükseltir, ama adresler ekran görüntüleri, kayıtlar ve paylaşılan kod yoluyla sızar. URL'yi herkese açık kabul edin ve bir mesajın gerçek olduğunu kanıtlamak için gizliliğe değil, imza doğrulamaya güvenin.

İmza ile parola arasındaki fark nedir?

Parola, kim olduğunuzu bir kez, girişte kanıtlar. İmza ise bu belirli mesajın gerçek gönderenden geldiğini ve değiştirilmediğini kanıtlar — her istek için yeniden hesaplanır, dolayısıyla çalınan eski bir imzanın faydası sınırlıdır.

İmzaları zaten doğruluyorsam tekrar korumasına ihtiyacım var mı?

Webhook gerçek sonuçlar tetikliyorsa evet. İmza bir mesajın sahici olduğunu doğrular, ama yakalanan sahici bir mesaj yeniden gönderilebilir. Zaman damgaları ve hatırlanan olay kimlikleri, gerçek bir mesajın yalnızca bir kez işe yaramasını sağlar.

Paylaşılan sırrı kim oluşturur — ben mi, gönderen mi?

Genellikle gönderen servis onu üretir ve webhook'u kurarken size bir kez gösterir. Siz onu kendi tarafınızda güvenle saklarsınız. Sızarsa yenilersiniz; bu da eski sırla imzalanmış her mesajı basitçe geçersiz kılar.

Webhook'lar, modern otomasyonu zahmetsiz hissettiren sessiz makinelerdir ve tam da bu yüzden bir şeyler ters gidene dek bu kadar az ilgi görürler. Burada sorumlu olmak için kriptografide ustalaşmanıza gerek yok. Gelen her mesajı kontrol edilmesi gereken bir iddia gibi görmeniz, imza doğrulamada ısrar etmeniz, para ya da müşterilerin işin içinde olduğu her yere tekrar koruması eklemeniz ve sırrınızı gerçekten sır tutmanız yeterli. Bunu yapın; webhook'ların kolaylığı, açık bir arka kapı olmadan gelsin. Rocketly gibi bir CRM kontrolü sizin için üstlenebilir; böylece akışınıza yalnızca gerçek olaylar ulaşır ve siz kapıda nöbet tutmak yerine işinizi yürütmeye dönebilirsiniz.