قائمة مراجعة أمان سيلزفورس: إيه اللي تصلّحه، وبأي ترتيب

معظم طلبات النشر على AppExchange بتقع في قائمة قصيرة ومتوقعة، وعلى رأسها التحكم في الصلاحيات. اشتغل على القائمة دي بالترتيب: فرض الصلاحيات في وضع المستخدم أولا، ثم فرز نتائج الفحص، ثم مستندات التقديم. كده بتشيل معظم الأسباب اللي بتخلي المراجع يرجّع لك الحزمة. سيلزفورس بتقول إن المراجعة بتاخد عادة من 4 إلى 5 أسابيع، يعني الرفض بيكلفك دورة إصدار كاملة مش بعد الظهر.

تِكوندا عدّت بحزم مُدارة من مراجعة أمان AppExchange في قطاعات الرعاية الصحية واللوجستيات والتصنيع. اللي جاي ده هو ترتيب الشغل عندنا فعلا، مش شرح نظري للعملية.

إيه اللي بيخلي طلب مراجعة الأمان يترفض؟

صلّح من فوق لتحت. البنود اللي فوق هي الأكثر تكرارا وكمان الأغلى لو أضفتها متأخر، وعشان كده تأجيلها للآخر هو اللي بيأخر التقديم دورة كاملة.

1. صلاحيات مش مفروضة في وضع المستخدم. كل استعلام وكل عملية DML في الحزمة لازم تحترم صلاحيات الكائنات وأمان الحقول وقواعد المشاركة للمستخدم الحالي. استخدم WITH USER_MODE مع SOQL وAccessLevel.USER_MODE مع استدعاءات Database بدل سلاسل isAccessible() المكتوبة يدويا، لأنها سهل تفضل ناقصة.
2. المشاركة معلنة على الكلاسات الغلط. كلاس Apex من غير كلمة مشاركة بيورث الإعداد من اللي استدعاه، فممكن كلاس مساعد بيتنادى من ميثود @AuraEnabled يشتغل من غير مشاركة وانت مش واخد بالك. اكتب with sharing صراحة على كل كلاس، بما فيها الكلاسات الداخلية والمساعدة.
3. SOQL ديناميكي مبني من مدخلات. استخدم bind variables. ولو الاستعلام لازم يتبني كنص، اعمل escape لكل قيمة داخله وخلي ده ظاهر في نفس الميثود، لأن ده المكان اللي المراجع بيقرأ فيه.
4. مخرجات من غير escape. أي حاجة بتوصل للصفحة عن طريق escape="false" أو lwc:dom="manual" أو innerHTML لازم تكون اتنضفت قبل ما توصل، مش بعدها.
5. أسرار وبيانات عملاء في مكان غلط. مفاتيح مكتوبة في كود Apex، توكنات في custom settings، أو سجل فيه بيانات شخصية بيعدي على System.debug. المراجعين متوقعين بدلها Named Credentials وprotected custom metadata.
6. نقاط اتصال خارجية محدش فحصها. لو الحزمة بتنادي خدمة انت مشغلها، الخدمة دي داخلة في نطاق المراجعة ومحتاجة تقرير فحص ديناميكي خاص بيها.
7. بيئة اختبار المراجع مش قادر يستخدمها. أورج منتهية، أو تحدي هوية بيقفل عليه الباب، أو كائنات فاضية من البيانات. الفريق بيجرب الحل من أوله لآخره زي أي عميل، ومش هيقدر يراجع حاجة مش شغالة.

أنهي نتائج الفحص بتكون إيجابيات كاذبة، وإزاي توثّقها؟

المطلوب مش صفر ملاحظات، والسقف بيختلف من أداة للتانية. إرشادات التحضير من سيلزفورس نفسها بتحددها كالآتي:

• Salesforce Code Analyzer: صلّح كل خطأ له علاقة بالأمان، وتجاهل الملاحظات اللي مالهاش علاقة بالأمان.
• فحص الكود في Partner Security Portal: صلّح مستويات Low وMedium وHigh، وسيب التنبيهات المعلوماتية زي ما هي.
• أدوات الفحص الديناميكي زي ZAP وBurp Suite وVeracode وIntruder وAcunetix وJiT DAST: صلّح كل حاجة ما عدا البنود المعلوماتية والتنبيهات، وأرفق صورة شاشة تثبت إن النقطة الصح هي اللي اتفحصت.

من ساعة ما سيلزفورس أوقفت ماسح Chimera المستضاف في 2025-06-16، بقيت بتشغّل الفحص الديناميكي ده بنفسك. بُص على تشغيل فحوصاتك الديناميكية بنفسك بعد Chimera عشان الأدوات المعتمدة والتقرير اللي بتسلّمه.

في تقديماتنا، في أربع فئات بترجع إيجابيات كاذبة حقيقية بتكرار يستاهل تحسب حسابه: ملاحظات صلاحيات على كود بيفرض وضع المستخدم أصلا، وملاحظات مشاركة على كلاسات مبيتم الدخول لها إلا من سياق طبّق المشاركة، وملاحظات مكتبات قديمة اتربطت برقم إصدار جوه static resource مرفقة، وملاحظات cross-site scripting منعكس على باراميترات عمرها ما بتوصل للـ DOM.

بس إنك على حق مش كفاية، المستند هو اللي بيعدّي. سيلزفورس بتطلب مستند يشرح ليه كل بند متعلّم عليه مش بيمثل خطر أمني، وبتقول لازم تكون محدد في شرح إزاي بتحمي نفسك من الثغرة المذكورة. اكتب لكل ملاحظة بندا مستقلا: اسم الأداة ورقم القاعدة، الملف والسطر، جملة واحدة توصف مسار البيانات، الإجراء الوقائي بالظبط، ومكانه في الحزمة. الرد بسطر واحد بيرجع لك على شكل سؤال، والأسئلة بتكلف أسابيع. لشرح أعمق لصيغة التبرير والأخطاء اللي بتخليه يترفض، شوف كيف توثّق النتائج الإيجابية الخاطئة للمراجعة الأمنية في Salesforce.

إيه اللي بيتقدم مع الحزمة؟

• توثيق استخدام مكتوب بحيث حد عمره ما شاف التطبيق يقدر يكمّل دورة عمل كاملة.
• توثيق تدفق البيانات بين أورج سيلزفورس وأي composite site أو تطبيق موبايل أو إضافة متصفح.
• كل تقارير الفحص، بالإضافة لمستند الإيجابيات الكاذبة.
• أورج Developer Edition والحزمة متثبتة عليها ومعاها بيانات اختبار واقعية.
• بيانات دخول لكل نظام خارجي التطبيق بيوصل له، شاملة وصول API وOAuth وSAML.
• روابط تثبيت وبيانات دخول لأي تطبيق موبايل أو سطح مكتب.

المراجعة بتاخد قد إيه وبتكلف كام؟

سيلزفورس بتذكر إن الحل بياخد عادة من 4 إلى 5 أسابيع في المراجعة، وإن كل حل مدفوع بيتباع على المتجر عليه رسوم $999 للتقديم الأول ولكل محاولة بعده. الاتنين بيوصلوا لنفس النتيجة: قدّم شغل الصلاحيات في الأول، لأن أرخص تقديم هو اللي بتعمله مرة واحدة بس.

لو بتجهّز منتج للنشر وتفضّل إن المراجعة تكون في إيد ناس عدّتها قبل كده، تِكوندا بتبني وتحزّم منتجات AppExchange كشريك PDO معتمد من سيلزفورس.

FAQ

هل التطبيقات المجانية محتاجة مراجعة أمان؟

أيوه. أي حل بيتوزع على المتجر لازم يعدي المراجعة قبل ما يتنشر. الرسوم اللي سيلزفورس موثقاها بتخص الحلول المدفوعة.

هل Salesforce Code Analyzer لوحده يكفي؟

لا. الإصدار الخامس بيغطي كود Apex وVisualforce وJavaScript وTypeScript جوه الحزمة. أي نقطة اتصال خارجية بينادي عليها تطبيقك لسه محتاجة تقرير فحص ديناميكي خاص بيها.

إيه أكتر سبب متكرر للرفض؟

التحكم في الصلاحيات. الاستعلامات وعمليات DML اللي بتشتغل في وضع النظام، والكلاسات اللي بتورث المشاركة بدل ما تعلنها، بتطلّع ملاحظات أكتر من أي حاجة تانية.

هل تطبيق Agentforce أو تطبيق قائم على وكلاء بيغيّر القائمة؟

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