ابدأ بوظيفة كل طلب في نشاطك التجاري
اطلب من المطور قائمة قصيرة بعمليات الموقع التي تتواصل مع الباك إند. اكتب أمام كل عملية معناها التجاري: تحميل تفضيلات المستخدم، حفظ ملاحظة، تشغيل خدمة ذكاء اصطناعي، أو بدء الدفع. ثم حدد البيانات المرسلة والبيانات المستلمة ومن المفترض أن يستخدم العملية.
هذا مهم لأن حساسية العمليات مختلفة. تغيير لون الواجهة ليس مثل منح اشتراك مدفوع. حدد شخصًا داخل الشركة يستطيع شرح النتيجة الصحيحة لكل عملية، حتى لو لم يكن مبرمجًا. راجع أيضًا ما يحدث عندما يغلق العميل نافذة الدخول أو يكرر الضغط على الزر أو يفقد الاتصال أثناء الحفظ. هذه مواقف استخدام حقيقية وليست تفاصيل ثانوية.
افصل بين تعريف المشروع وإثبات الجلسة
توضح وثائق Gammal Tech أن projectID معرف عام للمشروع. الدومين المسجل وجلسة المستخدم يؤديان وظائف مختلفة. عدم وجود مفتاح API سري للمطور لا يعني أن كل القيم الموجودة في المتصفح قابلة للنشر؛ توكن الجلسة يظل معلومة حساسة.
| العنصر | وظيفته | سؤال المراجعة |
|---|---|---|
| projectID | تعريف المشروع | هل الطلب يستخدم المشروع الصحيح؟ |
| الدومين المسجل | تحديد الموقع المعتمد | من يستطيع نشر كود على الموقع؟ |
| توكن الجلسة | التعامل مع جلسة المستخدم الحالية | هل يظهر في السجلات أو أدوات الدعم؟ |
إذا تمكن شخص من نشر كود ضار على الدومين المعتمد، فوجود الدومين في القائمة لا يجعل هذا الكود آمنًا.
حدد ما يحق للمستخدم تغييره
تسجيل الدخول ليس تصريحًا بتنفيذ كل عملية. توصي إرشادات OWASP للصلاحيات بفحص الإذن عند كل طلب وفي موضع موثوق. إخفاء زر الإدارة عن الواجهة لا يكفي لحماية وظيفة إدارية.
في مثال تعليمي افتراضي، يستطيع المتعلم تعديل اللغة وحفظ موضعه في الدرس. لكنه لا ينبغي أن يحصل على اشتراك بمجرد حفظ قيمة paid: true داخل بيانات يستطيع تعديلها. اطلب من المطور أن يوضح أين يُتخذ قرار منح الخدمة، وما الدليل الذي يعتمد عليه. إذا كانت البنية الحالية لا تستطيع فرض القرار بصورة موثوقة، فحل المشكلة قبل إطلاق الاشتراكات، وليس بعد أول شكوى.
اكتب قواعد واضحة للبيانات وعرضها
حدد نوع كل حقل وحجمه المتوقع وقيمه المقبولة. اختيار اللغة يمكن أن يقتصر على قائمة معروفة، والملاحظة الاختيارية يمكن أن يكون لها حد طول مفهوم. اتفق على التعامل مع الحقول الناقصة والبيانات القديمة، حتى لا يؤدي تحديث بسيط إلى محو عمل المستخدم أو تعطيل الصفحة.
راجع أيضًا طريقة عرض البيانات بعد استرجاعها. المعلومة لا تصبح آمنة للعرض ككود لمجرد أنها محفوظة في الباك إند. اسم يكتبه المستخدم أو رد صادر من الذكاء الاصطناعي يجب أن يعرض بالطريقة المناسبة للمحتوى. النص العادي يعرض كنص، وأي حاجة إلى HTML منسق تحتاج قرارًا واضحًا وآلية تنقية مناسبة، مع صيانة مستمرة.
راجع الفشل والتكرار قبل النجاح فقط
تغطي إرشادات OWASP لأمن REST استخدام HTTPS وعدم وضع بيانات الاعتماد في الروابط والفصل بين قواعد المتصفح والصلاحيات. بعد ذلك راجع تجربة العميل عندما يتأخر الطلب أو يُرفض أو يتكرر.
تعطيل زر الإرسال بعد الضغط قد يقلل التكرار العرضي، لكنه لا يمثل حماية كاملة من إساءة الاستخدام. اسأل مقدم الخدمة عن الحدود وآليات التعامل مع الطلبات المتكررة التي تخص الوظيفة المطلوبة. اجعل الرسالة توضح هل تم الحفظ أم لا، وهل يحتاج العميل إلى تسجيل الدخول مجددًا. لا تعرض رسالة نجاح بينما نتيجة العملية ما زالت مجهولة، ولا تكرر الطلب إلى ما لا نهاية.
ورقة مراجعة صغيرة قبل النشر
- اطلب من مختبرين مخولين استخدام حسابيهما الموثقين مع بيانات تطبيق وهمية مختلفة، وراجع الفصل المتوقع بينهما من خلال الوظائف المدعومة.
- جرب حقلًا ناقصًا وتأكد أن رسالة الخطأ مفهومة ولا تمحو بيانات أخرى دون قصد.
- راجع تقارير أخطاء التطبيق والتحليلات، وتأكد أنها لا ترسل توكن الجلسة كاملًا أو نسخة من سجل العميل.
- جرب انقطاع الدخول أو الجلسة، وتأكد أن الواجهة لا تعرض حالة قديمة على أنها حالة حالية.
- حدد الدليل الموثوق الذي يسمح بمنح خدمة مدفوعة أو صلاحية إدارية.
احتفظ بنتيجة المراجعة مع الإصدار. اختبر فقط الحسابات والأنظمة التي لديك تصريح بمراجعتها، وباستخدام واجهات الخدمة المدعومة.
دور Gammal Tech في تقليل مهام الحماية
تستضيف Gammal Tech تسجيل الدخول وتخزين بيانات التطبيق لكل مستخدم داخل كل مشروع. في الموقع المناسب، يقلل ذلك حاجتك إلى تشغيل قاعدة بيانات محلية لهذه الوظائف. يظل اختيار البيانات وقواعد العمل وطريقة عرضها جزءًا من تصميم موقعك.
قدم للمراجع قائمة محددة بما تستضيفه الخدمة، وما ينشره فريقك في الواجهة، وأي نظام مستقل يعتمد الطلبات أو يمنح وصول الموظفين. هذه الحدود الواضحة تجعل مراجعة إضافة حقل أو خدمة جديدة أسهل من الاعتماد على عبارة عامة مثل «الـ API آمن».
أسئلة شائعة
هل ظهور projectID في كود الموقع مشكلة أمنية؟
المعرف العام ليس مفتاحًا سريًا. المهم مراجعة نموذج الوصول كاملًا، بما يشمل الدومين والجلسة وصلاحية تنفيذ العملية المطلوبة.
هل يمكن الاعتماد على قيمة admin داخل بيانات المستخدم؟
إذا كان المستخدم يستطيع تعديل القيمة فلا يصح اعتمادها لمنح صلاحية إدارية. يجب أن يأتي قرار الصلاحية من موضع موثوق لا يتحكم فيه المستخدم.