SaaS webhook security: signatures, retries और idempotent handling
HMAC verification, HTTPS, replay-aware event handling, idempotent processing और monitored retries से webhook delivery तथा receiver सुरक्षित करें।
इस मार्गदर्शिका में
SaaS webhook receiver को सुरक्षित कैसे करें?
Webhook किसी बदलाव पर event को HTTPS endpoint तक भेजता है। Endpoint को कोई भी internet से call कर सकता है, इसलिए payload पर भरोसा करने से पहले provider का signature verify करें। HMAC तब message authenticate कर सकता है जब sender और receiver साझा secret रखें; इससे अपने-आप duplicate delivery, replay या गलत business action नहीं रुकता।
Signature को original request body पर verify करें
Provider का exact signing format अपनाएँ और JSON parse या normalize करने से पहले raw bytes के विरुद्ध signature verify करें। Vetted cryptographic library और constant-time comparison इस्तेमाल करें। GitHub payload पर HMAC-SHA256 signature बताता है; दूसरे providers के headers या formats अलग हो सकते हैं, इसलिए उन्हें समान न मानें।
HTTPS इस्तेमाल करें और signing secret URL से बाहर रखें
Certificate verification के साथ HTTPS अनिवार्य रखें और हर endpoint secret को managed secret storage में रखें। Secret को query string, source code, client-side config या logs में न डालें। किसे secret देखना, rotate या replace करना है, सीमित करें और value को रखे बिना change record करें।
Event type, tenant और allowed actions validate करें
Signature verify होने के बाद expected event type, payload shape, tenant, resource और state transition जाँचें। सही signature केवल बताता है कि message shared secret से बना; यह साबित नहीं करता कि business action मौजूदा account में allowed या अब भी current है। बदलाव लागू करने से पहले authorization तथा state फिर जाँचें।
| Provider / event | Signature और key version | Deduplication key | Retry और ordering policy | Alert owner / test date |
|---|---|---|---|---|
Receiver retries और duplicate events को कैसे संभाले?
जल्दी acknowledgement दें और काम asynchronous करें
Request verify करें, छोटा delivery record persist करें और काम queue में डालने के बाद provider का अपेक्षित success response लौटाएँ। Request window में धीमे database workflow या third-party calls न चलाएँ। Provider का timeout और retry behavior देखें; उदाहरण के लिए GitHub अपनी delivery का response दस seconds के भीतर देने की सलाह देता है।
Event processing को idempotent बनाएँ
Durable inbox में stable provider delivery ID या event ID पर uniqueness constraint रखें। वही signed delivery दोबारा आए तो side effect दोहराए बिना acknowledge करें। Payment update जैसे business action में current resource state भी जाँचें, क्योंकि अलग event IDs एक ही underlying change बता सकती हैं।
देर से आए और उलटे क्रम के messages के लिए तैयार रहें
Delivery order को business order न मानें। जहाँ उपलब्ध हो provider version, event timestamp या resource version compare करें और stale event गलत transition कर सकता हो तो current provider state fetch करें। Retry, dead-letter और manual replay रास्ते दिखाई दें और दोबारा चलाने पर सुरक्षित हों।
Webhook integration को समय के साथ कैसे चलाएँ?
नियंत्रित overlap के साथ secret rotate करें
Replacement secret बनाएँ, provider में update करें और सफल delivery monitor करने के बाद पुरानी key हटाएँ। Protocol allow करे तो change की छोटी अवधि में सक्रिय key versions की सीमित list से verify करें। पुरानी key हटाने की deadline तय करें; दोनों secrets को हमेशा स्वीकारना retired secret को attacker के काम का बना सकता है।
जरूरी events चुनें और delivery health monitor करें
Integration जिन events को संभालता है केवल वही subscribe करें। Endpoint और tenant के अनुसार accepted, rejected, delayed और लगातार fail हुई deliveries track करें, पर payload secrets तथा personal data हटाएँ। लंबे failure या backlog पर alert दें और authorized replay के लिए scoped tool दें।
Signature, replay और outage की स्थितियाँ test करें
Invalid signature, बदले हुए payload bytes, missing headers, repeated IDs, secret rotation, provider timeout, receiver outage और oversized payload test करें। Confirm करें कि invalid request side effect से पहले reject हो, retry duplicate काम न करे और operator छूटा event सुरक्षित रूप से replay कर सके।
SaaS webhook से जुड़े सवाल
क्या HMAC signature webhook replay रोकता है?
अपने-आप नहीं। Valid signature को signed body के साथ copy किया जा सकता है। Provider timestamp या nonce उपलब्ध हो तो इस्तेमाल करें, freshness window लागू करें और stable delivery ID deduplicate करें। हर provider का documented format जाँचें।
क्या signature जाँचने से पहले JSON parse करना चाहिए?
नहीं, यदि provider original body पर sign करता है। Raw request bytes पढ़ें, documented format से signature verify करें और उसके बाद ही payload parse तथा validate करें। Framework body parser के लिए raw-body route या middleware config जरूरी हो सकती है।
क्या known IP से आने पर webhook पर भरोसा कर सकते हैं?
Provider स्थिर ranges प्रकाशित करता हो तो IP allowlist अतिरिक्त network control हो सकती है, लेकिन signature verification का विकल्प नहीं। Provider ranges बदल सकती हैं; official source से update करते रहें और TLS certificate verification चालू रखें।
क्या webhook retry को business action फिर चलाना चाहिए?
Retry अधूरा काम सुरक्षित रूप से पूरा करे, पहले से committed side effect दोहराए नहीं। Delivery ID persist करें, handler को idempotent बनाएँ और बदलाव लागू करने से पहले resource की current state मिलाएँ।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .