Webhook Security: كيف تحمي تكامل SMS وWhatsApp API من الطلبات المزيفة؟
عندما ترسل شركتك رسالة SMS أو WhatsApp عبر API، لا ينتهي دور التكامل بمجرد تنفيذ طلب الإرسال.
هناك أحداث تحتاج أن تعود إلى نظامك، مثل وصول الرسالة، فشل التسليم، رد العميل أو تغير حالة الرسالة.
عادة تصل هذه الأحداث عبر Webhook.
لكن هناك سؤال أمني مهم:
كيف يعرف نظامك أن الطلب الذي وصل إلى عنوان الـWebhook جاء فعلًا من منصة المراسلة، وليس من شخص اكتشف الرابط وأرسل إليه Payload مزورًا؟
هنا تبدأ أهمية Webhook Security.
ما هو Webhook؟
الـWebhook هو عنوان HTTP Endpoint يستقبل إشعارات آلية عندما يقع حدث في نظام آخر.
بدل أن يسأل تطبيقك الـAPI كل عدة ثوانٍ:
«هل تغيرت حالة الرسالة؟»
ترسل المنصة الحدث مباشرة إلى نظامك عندما يحدث.
قد يحتوي الـWebhook مثلًا على:
- حالة تسليم SMS.
- رسالة WhatsApp واردة.
- تحديث حالة رسالة.
- حدث متعلق بقالب أو حساب.
- نتيجة عملية تمت بشكل غير متزامن.
هذا يجعل الـWebhooks فعالة جدًا، لكنه يعني أيضًا أن Endpoint غالبًا يحتاج إلى أن يكون قابلًا للوصول عبر الإنترنت.
وهذا يجعله جزءًا يجب تأمينه بعناية.
لماذا يمثل Webhook نقطة أمنية حساسة؟
تخيل أن نظام CRM لديك ينفذ إجراء بمجرد وصول Webhook يقول:
message.status = delivered
أو أن تطبيقك يبدأ Workflow عند وصول رسالة من العميل.
إذا كان الـEndpoint يقبل أي POST Request دون التحقق من المصدر، فقد يستطيع مهاجم إرسال بيانات مزورة إليه.
وقد يؤدي ذلك، حسب تصميم التطبيق، إلى:
- تسجيل حالات رسائل غير صحيحة.
- تشغيل Automation غير مقصودة.
- إدخال بيانات مزيفة في CRM.
- استهلاك موارد الخادم.
- إغراق النظام بعدد كبير من الطلبات.
- تشغيل Workflow أكثر من مرة.
لهذا يجب ألا يكون مجرد معرفة عنوان الـWebhook كافيًا لإقناع نظامك بأن الطلب موثوق.
هل HTTPS وحده يكفي؟
لا.
HTTPS ضروري لأنه يحمي البيانات أثناء انتقالها بين الطرفين ويقلل مخاطر اعتراض أو تعديل الاتصال.
Twilio مثلًا توصي باستخدام HTTPS وTLS لتأمين Webhooks.
لكن HTTPS يجيب عن سؤال:
هل الاتصال بين الطرفين مشفر؟
ولا يجيب وحده عن السؤال:
هل الشخص الذي أرسل هذا الطلب هو المصدر الذي أثق به فعلًا؟
ولهذا تحتاج إلى Authentication أو Signature Validation بالإضافة إلى HTTPS.
ما هو Webhook Signature؟
Webhook Signature عبارة عن توقيع تشفيري يتم إنشاؤه اعتمادًا على محتوى الطلب وSecret معروف للطرفين.
عندما تصل الرسالة إلى خادمك:
- يستقبل التطبيق الـPayload.
- يقرأ Signature المرسل في HTTP Header.
- يعيد حساب التوقيع باستخدام الـSecret الموجود لديه.
- يقارن النتيجتين.
- إذا كانتا متطابقتين، يمكن اعتبار الطلب أصليًا وفق آلية المزود.
- إذا لم تتطابقا، يتم رفض الطلب.
Twilio تستخدم توقيعًا في Header باسم X-Twilio-Signature، وتوصي بالتحقق منه قبل معالجة Webhook.
أما Infobip فتدعم HMAC ضمن خيارات Authentication للـWebhook، حيث يتم توقيع الـPayload باستخدام مفتاح سري ثم التحقق منه لدى الطرف المستقبِل.
كيف يعمل HMAC؟
HMAC هو أسلوب يستخدم:
- Secret Key.
- Hash Algorithm.
- محتوى الطلب.
لإنشاء Signature لا يستطيع طرف آخر إنشاءه بشكل صحيح دون امتلاك الـSecret.
على سبيل المثال، يمكن استخدام:
HMAC-SHA256
ليتم توقيع الـRaw Request Body.
عند وصول الطلب، يحسب Server التوقيع مرة أخرى ويقارنه بالتوقيع الوارد.
والنقطة المهمة هنا أن المقارنة يجب أن تتم بالطريقة التي يحددها مزود الـAPI، لأن كل منصة قد تختلف في طريقة تكوين القيمة التي يتم توقيعها.
لماذا Raw Request Body مهم؟
هذه نقطة تسبب أخطاء كثيرة للمطورين.
بعض أنظمة Webhook توقع الـBody كما وصل حرفيًا.
إذا قام Framework بتحويل JSON إلى Object ثم أعاد تكوينه قبل التحقق، قد تتغير:
- المسافات.
- ترتيب بعض العناصر.
- Encoding.
- شكل البيانات.
وبالتالي يصبح الـHash مختلفًا.
Infobip توضح في توثيق HMAC أن التحقق يجب أن يستخدم JSON Body كما تم استلامه دون إعادة تنسيق قبل حساب التوقيع.
Twilio أيضًا تفرق في آلية التحقق عند التعامل مع JSON وتوصي باستخدام الـraw body في الأدوات المخصصة لذلك.
Verify Token أم Signature Verification؟
هذا الفرق مهم جدًا، خصوصًا عند التعامل مع WhatsApp.
أثناء إعداد Webhook قد ترسل المنصة Request للتأكد من أنك تملك الـEndpoint.
في WhatsApp، توضح وثائق SDK التي استضافتها Meta أن عملية GET يمكن أن تستخدم Verify Token مع hub.challenge للتحقق من الاشتراك.
لكن طلبات POST الفعلية لها عملية تحقق من الأصالة باستخدام x-hub-signature-256 مع App Secret.
بمعنى آخر:
Verify Token يساعد أثناء إنشاء وربط Webhook.
أما Signature Validation فيساعد على التحقق من الطلبات التي تصل بعد ذلك.
من الخطأ اعتبار نجاح خطوة الـVerify Token حماية كافية لجميع Webhook Requests المستقبلية.
أخطر تهديدات Webhooks
1. Fake Requests
يعرف المهاجم عنوان Endpoint ثم يرسل POST Requests مصطنعة.
الحماية الأساسية هنا هي التحقق من Authentication أو Signature قبل تنفيذ Business Logic.
2. Replay Attack
حتى لو كان المهاجم غير قادر على إنشاء Signature جديد، فقد يحاول إعادة إرسال Request صحيح تم التقاطه سابقًا.
لهذا تستخدم بعض التصاميم:
- Timestamp.
- Nonce.
- Event ID.
- نافذة زمنية لقبول الطلب.
إذا كان الـProvider يقدم هذه البيانات أو آلية Replay Protection، استخدمها كما هو موثق.
3. Secret Leakage
إذا وضعت Webhook Secret مباشرة في GitHub أو Source Code أو Logs، فلن يعود التوقيع ذا قيمة كبيرة.
خزن الأسرار في:
- Environment Variables.
- Secret Manager.
- Vault.
- خدمة إدارة أسرار مناسبة للبنية التقنية.
ويجب تدوير Secrets عند الاشتباه في تسريبها.
4. Duplicate Events
ليس كل Event متكرر هجومًا.
أنظمة Webhooks قد تعيد الإرسال عندما لا تستقبل استجابة نجاح مناسبة.
لذلك يجب أن يكون التطبيق قادرًا على اكتشاف Event تمت معالجته مسبقًا باستخدام Event ID أو Message ID عندما يكون ذلك متاحًا.
وهنا يرتبط Webhook Security مباشرة بمفهوم Idempotency.
أفضل ممارسات Webhook Security
استخدم HTTPS دائمًا
لا تستخدم Endpoint غير مشفر في Production.
تحقق من Signature قبل Business Logic
الترتيب الصحيح هو:
استقبال الطلب → التحقق → المعالجة.
وليس:
استقبال الطلب → تحديث قاعدة البيانات → التحقق لاحقًا.
لا تسجل Secrets
راقب Logging Tools وAPM وError Reports حتى لا تظهر الأسرار داخلها.
طبق Rate Limiting
Signature Validation مهمة، لكن Rate Limiting تضيف طبقة مفيدة ضد إغراق Endpoint بعدد هائل من الطلبات.
طبق Deduplication
إذا كان لكل حدث ID فريد، خزنه لفترة مناسبة.
عند استقبال ID سبق تنفيذه، تجاهل المعالجة المكررة أو أعد النتيجة الآمنة.
استخدم Constant-Time Comparison
عند مقارنة Hashes أو Signatures في تطبيقاتك الخاصة، استخدم الدوال الأمنية المخصصة لذلك بدل المقارنة النصية البسيطة متى كان ذلك مناسبًا.
افصل Webhook Processing عن الأعمال الثقيلة
من الأفضل في كثير من الأنظمة أن:
- يتحقق Endpoint من الطلب.
- يسجل الحدث.
- يرسل Job إلى Queue.
- يعيد Success بسرعة.
- تتم المعالجة الثقيلة في Worker.
هذا يقلل احتمالية Timeout وإعادة إرسال الحدث بلا داعٍ.
مثال مبسط
يمكن أن يكون المنطق العام كالتالي:
Receive webhook
↓
Read raw body
↓
Read signature header
↓
Calculate expected signature
↓
Constant-time comparison
↓
Invalid → Reject
Valid → Check event ID
↓
Already processed → Ignore safely
New event → Queue processing
↓
Return success
لاحظ أن اسم الـHeader والخوارزمية وطريقة تكوين Signature تختلف من Provider إلى آخر.
لذلك لا تنسخ مثالًا أمنيًا من منصة وتطبقه تلقائيًا على منصة أخرى.
أخطاء شائعة
من أكثر الأخطاء التي يجب تجنبها:
- الاعتماد على HTTPS فقط.
- اعتبار Webhook URL نفسه Secret.
- عدم التحقق من Signature.
- نشر Secret داخل Git Repository.
- تعديل الـRaw Body قبل التحقق.
- تنفيذ Business Logic قبل Authentication.
- عدم التعامل مع Duplicate Events.
- إنشاء خوارزمية تحقق مخصصة رغم وجود SDK رسمي.
- عدم وجود Rate Limiting.
- قبول Payload دون Schema Validation.
Checklist قبل تشغيل Webhook في Production
قبل إطلاق تكامل SMS أو WhatsApp API، اسأل فريق التطوير:
- هل Endpoint يستخدم HTTPS؟
- هل نتحقق من مصدر كل Webhook؟
- هل Signature يتم فحصها قبل المعالجة؟
- هل نستخدم Raw Body بالطريقة التي يطلبها المزود؟
- هل الأسرار محفوظة خارج الكود؟
- هل لدينا Secret Rotation Plan؟
- هل نعالج Duplicate Events؟
- هل يوجد Rate Limiting؟
- هل يتم التحقق من شكل Payload؟
- هل Logs تخفي البيانات الحساسة؟
- هل فشل Signature يؤدي إلى رفض الطلب؟
إذا كانت الإجابة «لا» على أكثر من نقطة، فهناك مجال واضح لتحسين تصميم التكامل.
إذا كنت تبني تكاملات رسائل داخل متجر إلكتروني أو CRM أو ERP أو تطبيق، يمكنك استكشاف SMS API وWhatsApp Business API لدى OurSMS ومراجعة موارد المطورين قبل تصميم تدفق الـWebhooks والـCallbacks.
وفي التكاملات الحساسة، من الأفضل مراجعة متطلبات الأمان الخاصة بالـAPI المستخدم مع الفريق التقني قبل تشغيله في بيئة Production.
الخلاصة
الـWebhook جزء أساسي من تكاملات Messaging APIs، لكنه أيضًا نقطة دخول عامة إلى نظامك.
أفضل تصميم لا يثق في أي Request لمجرد أنه وصل إلى عنوان صحيح.
استخدم HTTPS، وتحقق من Signature أو Authentication وفق توثيق مزود الخدمة، واحمِ Secrets، وتعامل مع Replay وDuplicate Events، ثم نفّذ Business Logic فقط بعد نجاح التحقق.
هذه الممارسات تساعد على بناء تكاملات SMS وWhatsApp أكثر موثوقية، وتحمي الأنظمة الداخلية من التعامل مع طلبات مزورة أو مكررة باعتبارها أحداثًا حقيقية.