WHATS CRM HUB

عن الأمان

الأمان = تدقيق + معالجة

الأمان ليس وعدًا تسويقيًا — الأمان تدقيق يُنجز حتى نهايته

نحن لا نقول "نحن آمنون"، بل نُريك التدقيق: 27 ملاحظة محددة، 7 مراحل معالجة، جميعها مغلقة قبل الإطلاق إلى الإنتاج.

كثير من مزوّدي SaaS يقولون "بياناتك آمنة" دون أن يُريك كيف. نحن مختلفون. الواجهة الخلفية Go والواجهة الأمامية Vue الخاصتين بـ WhatsCRM Hub خضعت لتدقيق (read-only) في مايو 2026 من فريق هندسي خبير، مع 27 ملاحظة محددة — كل واحدة مرتبطة بموقع file:line في الكود.

تم إغلاق كل ملاحظة في 7 مراحل متسلسلة، بدءًا من الأكثر حرجة (تسرّب بيانات بين المستأجرين) وصولًا إلى نظافة (تنقية السجلات + رؤوس الأمان). كل إصلاح يجب أن يُشحن مع اختبار انحدار — بدون اختبار، لا يُعتبر الإصلاح منتهيًا.

النتيجة: 0 CRITICAL، 0 HIGH مفتوح، جميع ملاحظات MEDIUM وLOW عولجت. النظام جاهز للإنتاج لنموذج SaaS متعدد المستأجرين بمدفوعات.

finding diidentifikasi

fase remediasi

100%

CRITICAL + HIGH closed

سبع ركائز للأمان

ماذا نحمي؟

1. عزل متعدد المستأجرين

بيانات المستأجر A لن تتسرّب أبدًا إلى المستأجر B. ترويسة X-Business-ID يُتحقق من ملكيتها للمستخدم في JWT + قاعدة البيانات قبل تنفيذ أي استعلام. تم تدقيق كل مستودع (58 ملف)، وهناك اختبار CI lint يفشل تلقائيًا إذا أضاف مطوّر مستقبلي استعلامًا بدون فلتر business_id.

تسرّب بيانات بين المستأجرين (CRITICAL) — أُغلق في المرحلة 0

2. رموز لا تتسرّب

تُحفظ رموز الوصول في الذاكرة فقط (ليس في localStorage)، ورموز التجديد في cookie httpOnly غير قابل للقراءة من JavaScript. WebSocket يستخدم تذاكر للاستخدام مرة واحدة (TTL 30 ثانية)، وليس JWT في الـ URL — مما يمنع تسرّب الرمز عبر سجلات البروكسي وسجل المتصفح وترويسة Referer.

تسرّب الرمز عبر URL في WebSocket (CRITICAL) — أُغلق في المرحلة 1

3. مصادقة مقاومة للاختراق

تجديد رمز Refresh يستخدم CAS ذرّي — عند اكتشاف محاولة إعادة تشغيل، تُلغى سلسلة رموز المستخدم بأكملها (استجابة لحادث أمني). OTP من 6 أرقام للاستخدام مرة واحدة مع bcrypt cost 12. مُحدّد المعدّل fail-closed عند تعطّل Redis — يستخدم احتياطيًا في الذاكرة لمنع الاختراق حتى أثناء عُطل البنية التحتية.

سباق Refresh + إعادة استخدام OTP + تجاوز Rate Limit (HIGH×3) — أُغلقت في المرحلة 2

4. Webhooks لا يمكن انتحالها

Webhooks من Meta (WhatsApp Business API) تشترط التحقق من توقيع HMAC في الإنتاج — يفشل startup إذا كان app_secret فارغًا. بوّابات الدفع تستخدم subtle.ConstantTimeCompare (مضادّ هجمات التوقيت). حماية إعادة التشغيل لمدة 24 ساعة: الحمولات المتطابقة في تلك النافذة تُرفض كمكررات.

انتحال Webhook (HIGH) + هجوم توقيت Duitku (MEDIUM) — أُغلق في المرحلة 3

5. حماية المتصفح (CSRF + XSS)

جميع نقاط النهاية المُعدِّلة (POST/PUT/PATCH/DELETE) محمية بـ CSRF token، وليس فقط /auth/*. Vue 3 يفلت تلقائيًا كل التداخلات — مدخلات الدردشة تُعرض بدون v-html، فيُحظر XSS عبر رسائل WhatsApp من المهاجمين. رؤوس أمان كاملة: HSTS وX-Frame-Options DENY وX-Content-Type-Options nosniff وCSP report-only.

فجوة تغطية CSRF + رؤوس أمان مفقودة — أُغلقت في المرحلتين 4 و6

6. الإعدادات لا يمكن نشرها بخطأ

إعدادات الإنتاج تُتحقق منها عند startup — الخادم يرفض البدء إذا كان TOKEN_ENCRYPTION_KEY فارغًا، أو JWT secret أقل من 32 حرفًا، أو CORS بـ wildcard * في الإنتاج. تحميلات الملفات تُتحقق من نوع MIME على جانب الخادم (sniff لأول 512 بايت — لا نثق بترويسة العميل) — ملف .exe أُعيد تسميته إلى .png سيُرفض.

مفخّخ إعدادات + انتحال MIME (MEDIUM×4) — أُغلق في المرحلة 5

7. سجلات نظيفة (لا تسرّب PII)

سجلات الإنتاج تُنقّى تلقائيًا: أخطاء SQL وstack traces وعناوين المؤشرات ومسارات الكود تُجرَّد قبل الكتابة إلى الملف. الرموز وكلمات المرور والأسرار لا تُسجَّل أبدًا خام — فقط 8 أحرف بادئة عند الحاجة للتتبع. كل طلب لديه request-id لمسارات تدقيق دون كشف بيانات حساسة.

تنقية الأخطاء + إخفاء حقول السجلات — أُغلق في المرحلة 6

المعايير التي نتبعها

متوائم مع معايير الصناعة

لا نَدّعي "متوافق" بدون أساس — نُريك المعايير التي نقيس بها والضوابط التي طبّقناها.

OWASP ASVS Level 2

Application Security Verification Standard — قائمة تحقّق أمان تطبيقات الويب المقبولة عالميًا. مناسبة لـ SaaS يخزّن بيانات العملاء الحساسة.

OWASP Top 10 (2021)

تحديدًا A01 (التحكم بالوصول المعطّل) وA02 (الإخفاقات التشفيرية) وA05 (سوء إعدادات الأمان) وA07 (إخفاقات الهوية والمصادقة) — جميعها عولجت في تدقيقنا.

PDPL المملكة العربية السعودية

بيانات المستأجر تبقى في منطقة العميل (أو على VPS العميل لرخصة الكود المصدري). لا نقل عبر الحدود تلقائيًا. حق الوصول + حق الحذف مدمجان في النموذج.

GDPR (الاتحاد الأوروبي) / LGPD البرازيل / UU PDP إندونيسيا

متوائم مع لوائح أسواقنا الرئيسية. عزل المستأجرين يضمن أن طلب "احذف بياناتي" من مستأجر لا يمسّ مستأجرًا آخر.

عملية، لا تدقيق مرة واحدة

الأمان انضباط مستمر

تدقيق مايو 2026 ليس سوى لقطة. إليك ما وضعناه حتى لا تتراجع وضعية الأمان مع الوقت.

اختبارات انحدار إلزامية

كل إصلاح يجب أن يُشحن مع اختبار — بدون اختبار، الإصلاح غير منتهٍ. CI يفشل إن عاد عيب سبق إصلاحه.

اختبار Lint لعزل المستأجرين

تحليل ساكن في CI يفحص كل مستودع — إذا أُضيف استعلام جديد بدون فلتر business_id، يفشل البناء. مضادّ انحدار طويل الأمد.

مراجعة دورية

وثيقة التدقيق تُراجع في نهاية كل مرحلة معالجة، وعلى الأقل مرة قبل كل إطلاق إنتاج كبير.

سجل قرارات شفّاف

كل مقايضة أمنية موثّقة في SECURITY.md — لماذا اخترنا A بدل B، حتى يفهم المهندسون اللاحقون السياق.

الأثر التجاري

لماذا هذا مهم لعملك؟

يبدو الأمان التقني شأنًا هندسيًا، لكن أثره يقع مباشرة على الإيراد والاحتفاظ بالعملاء وراحة بالك ليلًا.

ثقة العملاء

حين يعلم العملاء أن بيانات أعمالهم آمنة، لن ينتقلوا إلى منافس. ثقة = احتفاظ = LTV عالٍ.

بدون مخاطر قانونية

تسرّب بيانات العملاء قد يجلب غرامات بموجب GDPR/LGPD/PDPL (تصل إلى 4% من الإيراد السنوي). عزل قوي بين المستأجرين = راحة بال.

سمعة تبقى سليمة

حادث تسرّب واحد ينتشر على Twitter/LinkedIn قد يمحو 5 سنوات من بناء العلامة. لدينا حواجز متعدّدة لمنع ذلك.

عملاء المؤسسات يدفعون أكثر

العملاء المؤسسيون الكبار (الذين يدفعون شهريًا عاليًا) يشترطون قائمة تحقّق أمان قبل توقيع العقود. توثيق تدقيق شفّاف = بيع أسهل لشريحة Premium.

ترغب برؤية تفاصيل التدقيق؟

فريقنا الهندسي مستعدّ لنقاش تقني عميق — بما في ذلك الوصول إلى وثيقة التدقيق الكاملة (SECURITY.md، 468 سطر) تحت اتفاقية NDA لعملاء المؤسسات في تقييم جدّي.

احجز استشارة اسأل فريق الأمان