كل ما يستحق المعرفة، ولا شيء مما لا يستحقها.
كيفية إنشاء التوقيع
تعتمد طريقة شائعة على بناء السلسلة المرجعية على الشكل `${timestamp}.${requestBody}`، ثم حساب `HMAC-SHA256(canonical, secret)`، وترميز الناتج بالنظام الست عشري، وإرسال الملخص مع الطابع الزمني في ترويسة توقيع. يمنع تضمين الطابع الزمني داخل الحمولة الموقّعة هجمات إعادة الإرسال — وينبغي أن ترفض نقطة النهاية لديك أي webhook يزيد عمره على 5 دقائق. تختلف أسماء الترويسات والصيغة المرجعية الدقيقة من منصة إلى أخرى، لذا تحقّق منها لدى مزوّدك قبل كتابة شيفرة التحقق.
لماذا استخدام HMAC وليس توقيعات RSA
تتميز خوارزمية HMAC بالتناظر - حيث يتشارك الطرفان سرًا واحدًا - مما يعني أن التوقيع والتحقق أسرع بنحو 10000 مرة من خوارزمية RSA-2048. في حالة انتشار روابط الويب، حيث قد يُصدر مركز خدمة الرسائل القصيرة (SMSC) الواحد 50000 طلب DLR في الثانية، يستهلك توقيع RSA معظم موارد المعالج. أما خوارزمية HMAC-SHA256 على الأجهزة الحديثة فتستغرق بضعة ميكروثوانٍ فقط. في المقابل، يستطيع أي شخص يملك السر أن يوقّع، لذا يجب ألا يُشارك السر إلا بين المنصة وبيئتك، وأن يُخزَّن كأي بيانات اعتماد أخرى، وأن يكون قابلًا للتدوير عند الطلب.
مشاكل التحقق
ثلاثة أخطاء شائعة. مقارنة السلاسل النصية باستخدام `==` بدلاً من مقارنة ثابتة الوقت (هجوم التوقيت - استخدم `crypto.timingSafeEqual`). التحقق من صحة التوقيع بعد تحليل محتوى JSON (يجب التحقق من البايتات الخام، وليس من تمثيل مُعاد تسلسله - إعادة ترتيب JSON تُفسد التجزئة). نسيان نافذة منع إعادة الإرسال للطابع الزمني.
ما وراء HMAC
في البيئات الخاضعة للتنظيم (البنوك والرعاية الصحية)، تدعم بعض المنصات أيضًا تسليم webhooks عبر mTLS — إذ يقدّم المُرسِل شهادة عميل يتحقق منها موازن الأحمال لديك قبل أن يصل الطلب إلى التطبيق. هذا أقوى من HMAC لأنه يربط التسليم بمفتاح عتادي، لكنه لا يبرر تكلفته إلا لأعباء العمل الحساسة فعلًا. بالنسبة لمعظم عمليات التكامل، يبقى HMAC-SHA256 عبر HTTPS هو الخيار الصحيح.