دليل عملي لتطوير التطبيقات الآمنة

لمن هذا الدليل وكيف تستخدمه

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

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

الطريقة هنا هي التي نطبقها على المنتجات التي نبنيها: يبدأ كل مشروع بمراجعة للتهديدات، ونلتزم بممارسات البرمجة الآمنة، ونختبر قبل كل إصدار، وتُنتج مراجعة أمنية قبل الإطلاق قائمة إصلاحات مرتبة بالأولوية. اطلع على طريقة عملنا وممارساتنا الأمنية، ثم استخدم هذا الدليل لتحاسب أي فريق، فريقك أنت أيضًا، بالمعيار نفسه.

الأمن سلسلة موازنات، وليس حالة تصل إليها وتنتهي. الهدف أن تجعل الهجوم مكلفًا، والفشل مرئيًا، والتعافي سريعًا. هذا الدليل إرشاد هندسي عام وليس استشارة قانونية: إذا انطبق قانون أو معيار على منتجك فتأكد من تفاصيله مع مستشار قانوني مؤهل.

الأصول والتهديدات ومتطلبات الأمن

جهد الأمن محدود، فاصرفه حيث يكون الضرر أكبر. ابدأ بقائمة صريحة بما تحميه ومن قد يستهدفه.

اكتب قائمة بما تحميه

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

حدد من قد يهاجم

مصادر التهديد قائمة قصيرة: أدوات مسح آلية تفحص كل ما هو على الإنترنت، ومجرمون يطلبون المال أو البيانات، ومستخدمون يسيئون استخدام صلاحيات يملكونها أصلًا، وحسابات شركاء أو موظفين مخترَقة، وأحيانًا مهاجم يستهدفك أنت. أغلب التطبيقات تواجه الثلاثة الأولى كل يوم، فخطط لها أولًا.

أجرِ نمذجة تهديدات خفيفة

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

1. ارسم المسار في صفحة واحدة: المستخدمون والتطبيق وواجهة API وقاعدة البيانات والأطراف الخارجية وحدود الثقة، أي النقاط التي تنتقل عندها البيانات من جهة أقل ثقة إلى جهة أعلى.
2. عند كل حد اسأل: ماذا يستطيع المهاجم أن ينتحل أو يعبث به أو يسرّبه أو يعطّله أو يسيء استخدامه؟ تصلح أسئلة STRIDE قائمةً للمراجعة: الانتحال والعبث وإنكار الفعل وكشف المعلومات وحجب الخدمة ورفع الصلاحيات.
3. رتّب النتائج حسب الأثر وسهولة الهجوم، ثم حوّل كل نتيجة مقبولة إلى مهمة لها مسؤول واختبار.
4. راجع النموذج كلما أضفت ميزة كبيرة أو تكاملًا جديدًا أو نوعًا جديدًا من البيانات.

حوّل التهديدات إلى متطلبات قابلة للاختبار

المتطلب جملة تستطيع أن تختبرها. عبارة «يجب أن يكون التطبيق آمنًا» لا تُختبر، أما «لا يقرأ المستخدم إلا فواتيره» فتُختبر. يقدم معيار OWASP للتحقق من أمن التطبيقات (ASVS) متطلبات جاهزة بثلاثة مستويات، فاختر المستوى الذي يناسب مخاطرك. واستخدم قائمة OWASP Top 10 للتوعية، لا بوصفها مواصفات.

أجرِ نمذجة التهديدات قبل أن يستقر التصميم: تعديل رسم بياني رخيص، وتعديل نموذج بيانات صدر فعلًا مكلف. وإن أردت ميسّرًا للجلسة فاطلع على خدمة نمذجة التهديدات لدينا.

المعمارية وقرارات التصميم

أرخص إصلاحات الأمن قرارات تُتخذ قبل أن توجد الشيفرة. لهذا يعدّ OWASP التصميم غير الآمن فئة قائمة بذاتها في قائمته: لا تصلح الشيفرة المتقنة مسارًا كان غير آمن من أساسه.

مبادئ تستحق أن تُعلَّق على الجدار

• أقل صلاحية. يحصل كل مستخدم وخدمة ورمز على الوصول الذي تتطلبه مهمته فقط.
• الرفض افتراضيًا. يُرفض الوصول ما لم تسمح به قاعدة، وتبدأ نقاط النهاية الجديدة مغلقة.
• الدفاع على طبقات. افترض أن ضابطًا واحدًا سيفشل وضع خلفه ضابطًا آخر، كالتحقق من المدخلات مع الاستعلامات المُمَعلمة.
• سطح هجوم صغير. كلما قلّت نقاط النهاية والميزات والمكتبات والبيانات المخزنة قلّ ما تدافع عنه.
• الفشل الآمن. حين يتعطل شيء يرفض التطبيق الوصول ويخفي تفاصيله الداخلية.
• لا أسرار في العميل. كل ما يصل إلى المتصفح أو الهاتف يستطيع من يحمله أن يقرأه.

قرارات تزيل فئات كاملة من الأخطاء

حدّد المسارات القابلة للإساءة مبكرًا

بعض المسارات تستحق وقت تصميم إضافيًا لأن إساءة استخدامها مربحة: التسجيل وتسجيل الدخول واستعادة كلمة المرور والدفع والرفع والتصدير وكل إجراء إداري. اكتب لكل منها كيف يمكن إساءة استخدامه على نطاق واسع، وما الحد الذي ستضعه: تحديد معدل الطلبات، أو حصص، أو تحققًا إضافيًا، أو موافقة على الإجراءات الكبيرة.

إعداد السحابة جزء من المعمارية أيضًا. على AWS وAzure وGoogle Cloud تتشابه المبادئ وإن اختلفت أسماء المنتجات: حسابات أو مشاريع منفصلة لكل بيئة، وأدوار بأقل صلاحية، وتخزين خاص افتراضيًا، وبنية تحتية تُعرَّف بالشيفرة وتُراجع كما تُراجع شيفرة التطبيق.

المصادقة والجلسات والتفويض

المصادقة تثبت من هو الشخص، والتفويض يحدد ما يحق له فعله. وتقف نسخ معطوبة من الاثنين وراء اختراقات حقيقية كثيرة، فامنحهما وقت تصميم واختبارًا ومراجعة.

كلمات المرور وتسجيل الدخول

• فضّل مزود هوية مجرَّبًا أو مكتبة موثوقة. وإن خزّنت كلمات المرور بنفسك فاستخدم دالة تجزئة بطيئة بملح مصممة لهذا الغرض: Argon2id أولًا، أو scrypt أو bcrypt أو PBKDF2. لا تكتفِ بتجزئة سريعة، ولا تستخدم تشفيرًا قابلًا للعكس.
• اتبع الإرشادات الحديثة مثل NIST SP 800-63B: اسمح بعبارات مرور طويلة، وافحص كلمات المرور الجديدة مقابل المسرّبة المعروفة، وتجنب قواعد التركيب التعسفية والتغيير الدوري الإجباري.
• حدّد عدد المحاولات لكل حساب ولكل مصدر، ولا تكشف في رسالة خطأ أو استعادة ما إذا كان الحساب موجودًا.
• وفّر المصادقة متعددة العوامل واشترطها على المديرين وعلى الإجراءات الحساسة. وفضّل مفاتيح المرور (passkeys) وتطبيقات المصادقة ومفاتيح الأجهزة على الرسائل النصية، فهي أضعف أمام استبدال شريحة الهاتف والتصيّد.
• عامل الاسترداد جزءًا من المصادقة، فهو في الغالب أضعف مدخل: روابط لمرة واحدة ومحدودة المدة، وإشعار بكل تغيير، وإعادة تحقق قبل تغيير البريد أو كلمة المرور.

الجلسات والرموز

• أصدر معرّف جلسة جديدًا عند تسجيل الدخول وكلما تغيّرت الصلاحيات، لمنع تثبيت الجلسة.
• لجلسات الكوكيز فعّل HttpOnly وSecure وسمة SameSite مناسبة، مع مهلة خمول ومهلة قصوى.
• اجعل تسجيل الخروج وتغيير كلمة المرور ينهيان الجلسات على الخادم، لا في العميل فقط.
• مع رموز JSON Web Tokens تحقق على الخادم من التوقيع والخوارزمية، وافحص الانتهاء والجهة المصدِرة والجمهور المستهدف، واجعل عمرها قصيرًا، ولا تضع داخلها أسرارًا: هي موقَّعة لا مخفية.
• في تطبيقات الجوال والصفحة الواحدة التي تستخدم OAuth 2.0 وOpenID Connect، استخدم تدفق رمز التفويض مع PKCE في متصفح النظام، لا في عرض ويب مدمج ولا بالتدفق الضمني.

التفويض: افحص كل طلب

يحتل كسر التحكم في الوصول مرتبة متقدمة باستمرار في قائمة OWASP Top 10. والخطأ المعتاد بسيط: يتحقق التطبيق أنك سجلت الدخول، لكنه لا يتحقق أن هذا السجل لك.

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

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

الحقن ومعالجة المدخلات

يقع الحقن حين يُعامَل مُدخل غير موثوق على أنه شيفرة أو جزء من أمر. ويبقى في قائمة OWASP Top 10 لأن سببه شائع جدًا: نص يُبنى بالتجميع ثم يُمرَّر إلى مفسّر مثل قاعدة بيانات أو سطر أوامر أو متصفح. وعادتان تمنعان معظمه: افصل البيانات عن الشيفرة، وتحقق من المدخلات عند الحدود.

حقن SQL

يتيح حقن SQL للمهاجم أن يغيّر استعلام قاعدة البيانات بإرسال نص يلصقه التطبيق فيه. والحل قديم وموثوق: الاستعلامات المُمَعلمة تُرسل الاستعلام والقيم منفصلين، فلا تصبح القيمة جزءًا من الاستعلام أبدًا.

• استخدم المعاملات لكل قيمة، في SQL الخام وفي منافذ الهروب داخل أدوات ORM. أداة بناء الاستعلامات تحميك ما دمت داخل حدودها.
• لا تحلّ المعاملات محل أسماء الجداول أو الأعمدة. إذا جاء حقل الترتيب من المستخدم فمرّره عبر قائمة سماح ثابتة.
• امنح حساب قاعدة البيانات في التطبيق الصلاحيات التي يحتاجها فقط، ليقلّ الضرر إذا وُجدت ثغرة.
• اعرض للمستخدم رسالة خطأ عامة، واحتفظ برسائل قاعدة البيانات في سجلات الخادم. والقاعدة نفسها تنطبق على قواعد NoSQL وLDAP ومحركات البحث: مدخل المستخدم يبقى بيانات.

البرمجة النصية عبر المواقع

تشغّل البرمجة النصية عبر المواقع (XSS) سكربت المهاجم داخل صفحتك، فيتصرف كأنه المستخدم المسجَّل. وقد تكون مخزَّنة، أو منعكسة في استجابة، أو قائمة على DOM حين تكتب شيفرة العميل بيانات غير موثوقة في الصفحة.

• رمّز المخرجات بحسب سياقها. نص HTML والسمات والسكربتات وعناوين URL يحتاج كل منها هروبًا مختلفًا، فاعتمد على إطار عمل يفعل ذلك افتراضيًا.
• اعتبر منافذ الهروب علامات تحذير في المراجعة: dangerouslySetInnerHTML في React وv-html في Vue وbypassSecurityTrust في Angular وinnerHTML المباشر.
• اسمح في الروابط المبنية من بيانات المستخدم بـ http وhttps وmailto فقط، وارفض عناوين javascript:.
• إذا كان المستخدمون يرسلون نصًا منسقًا فنظّفه بمكتبة تعقيم HTML مُصانة وقائمة قصيرة من الوسوم المسموحة. وفعّل HttpOnly على كوكيز الجلسة حتى لا يقرأها سكربت محقون.

سياسة أمان المحتوى

سياسة أمان المحتوى (CSP) ترويسة استجابة تخبر المتصفح بالسكربتات والأنماط والإطارات والاتصالات المسموح بها لصفحة ما. وإذا تسرّب حقن فقد توقف السياسة الجيدة تشغيل سكربت المهاجم. وهي طبقة ثانية خلف ترميز المخرجات، لا بديل عنه.

1. ابدأ بوضع التقارير فقط (ترويسة Content-Security-Policy-Report-Only) واجمع التقارير لتعرف ما تحمّله صفحاتك فعلًا.
2. انطلق من أساس صارم: default-src 'self' وobject-src 'none' وbase-uri 'self'، مع frame-ancestors لتحديد من يحق له تضمينك.
3. اسمح بسكربتاتك بالـ nonce أو التجزئة بدل unsafe-inline، وأضف مصادر الأطراف الخارجية واحدًا بعد الآخر ولكل منها سبب.
4. انتقل إلى وضع الإنفاذ، وأبقِ التقارير شغالة لتظهر الأعطال الجديدة.

مخاطر حقن ومدخلات أخرى

تحقق عند الحدود

تحقق من كل مُدخل على الخادم مهما فحصه العميل. فضّل قوائم السماح على قوائم المنع: عرّف شكل القيمة الصحيحة (النوع والطول والمدى والصيغة) وارفض ما عداها. وشارِك مخططًا واحدًا بين الويب والجوال وواجهة API حتى تتفق. ولا يغني التحقق عن الاستعلامات المُمَعلمة وترميز المخرجات: اسم صحيح مثل O'Brien يحوي فاصلة عليا، وهي خطرة في السياق الخطأ.

الأسرار وحماية البيانات

الأسرار مفاتيح كل شيء آخر: كلمات مرور قواعد البيانات ومفاتيح API ومفاتيح التوقيع والرموز. وتحدد حماية البيانات ما يناله المهاجم إذا سقطت طبقة. تعامل مع الاثنين كموضوعي تصميم، لا كإعدادات تُرتَّب قبل الإطلاق.

أبعد الأسرار عن الشيفرة والعملاء

• لا تضع الأسرار في المستودع أبدًا، ولو كان خاصًا. فعّل فحص الأسرار وحماية الدفع (push protection).
• حمّل الأسرار وقت التشغيل من مخزن الأسرار في المنصة أو من مدير مثل AWS Secrets Manager أو Azure Key Vault أو Google Secret Manager. وأبعدها عن الصور والسجلات ورسائل الخطأ.
• استخدم سرًا منفصلًا لكل بيئة وكل خدمة بأضيق صلاحيات تكفي، وفضّل بيانات الاعتماد قصيرة العمر.
• افترض أن كل ما في حزمة المتصفح أو ملف تطبيق الجوال علني. ففي Next.js مثلًا تُرسَل إلى المتصفح المتغيرات التي تبدأ بـ NEXT_PUBLIC_.
• إذا تسرب سر فأبطله أولًا ونظّف ثانيًا: حذف الإيداع لا يلغي التسريب.

احمِ البيانات طوال دورة حياتها

اجمع ما تحتاجه فقط، واحتفظ به المدة اللازمة فقط، واعرف أين يوجد.

• شفّر البيانات أثناء النقل بـ TLS في كل مكان، حتى بين الخدمات الداخلية، وأرسل ترويسة Strict-Transport-Security.
• شفّر البيانات المخزَّنة بالتشفير المُدار في قاعدة بياناتك وتخزينك ونسخك الاحتياطية. وللحقول الأكثر حساسية أضف تشفيرًا على مستوى التطبيق بمفاتيح في خدمة إدارة مفاتيح.
• استخدم مكتبات تشفير جرى فحصها جيدًا. لا تخترع خوارزميات، ولا تستخدم MD5 أو SHA-1 لأغراض أمنية.
• أبعد البيانات الشخصية والأسرار عن السجلات وتقارير الأخطاء، واستخدم بيانات وهمية في بيئات التطوير والاختبار.
• شفّر النسخ الاحتياطية، وقيّد من يقرؤها، وجرّب الاستعادة فعلًا.
• اترك لمزود الدفع أن يستقبل أرقام البطاقات عبر حقوله أو صفحة الدفع المستضافة لديه حتى لا تصل إلى خوادمك. وهذا يقلّص أيضًا قواعد أمن البطاقات المنطبقة عليك؛ تأكد من التفاصيل مع المزود.

تختلف قوانين البيانات الشخصية في الخليج والاتحاد الأوروبي والولايات المتحدة في نطاقها وقواعد الموافقة وما تقوله عن تخزين البيانات أو نقلها عبر الحدود. هذا الدليل للتوعية فقط: تأكد مما ينطبق على منتجك مع مستشار قانوني مؤهل. واطلع أيضًا على دليلنا لإطلاق البرمجيات في الخليج.

المكتبات الخارجية وسلسلة توريد البرمجيات

معظم التطبيق الحديث شيفرة لم تكتبها: أطر عمل وحزم ومجموعات تطوير (SDK) وصور حاويات وأدوات بناء. وكل منها قرار ثقة. والمشكلات ثلاثة أنواع: ثغرة معروفة في إصدار تشغّله، وحزمة خبيثة أو مسروقة الحساب، وخط بناء مخترَق.

تحكّم فيما تضيفه

• أضف الاعتمادية عن قصد. تأكد أنها مُصانة ومراجَعة على نطاق واسع، وفضّل عددًا قليلًا من المكتبات المعروفة على كثير من الصغيرة.
• ثبّت ملفات القفل (lockfiles) في المستودع وثبّت منها في خط البناء (مع npm يعني ذلك npm ci)، ليستخدم البناء الإصدارات التي راجعتها.
• انتبه للأسماء المشابهة (typosquatting). وأبقِ الحزم الداخلية في سجل خاص بنطاق محدد حتى لا تحل محلها حزمة عامة بالاسم نفسه (dependency confusion).
• فعّل المصادقة متعددة العوامل على كل حساب في سجل الحزم وGitHub والسحابة يستطيع النشر.

اكتشف الثغرات المعروفة وأصلحها باستمرار

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

حدّث على دفعات صغيرة متكررة: الفريق الذي يحدّث كل أسبوع يتعامل مع رقعة عاجلة بهدوء، أما الفريق الذي لم يحدّث منذ سنة فيواجه قفزة محفوفة بالمخاطر. واحتفظ بقائمة مواد البرمجيات (SBOM) بصيغة مثل CycloneDX أو SPDX لتعرف سريعًا هل تؤثر ثغرة أُعلن عنها حديثًا فيك.

قوِّ خط النشر

يستطيع خط CI/CD لديك أن ينشر إلى الإنتاج، ولذلك يستهدفه المهاجمون مباشرة.

• احمِ الفرع الرئيسي: مراجعات إلزامية وفحوص ناجحة ولا دفع مباشر.
• امنح كل مهمة أقل صلاحية تحتاجها، وأبعد بيانات النشر عن المهام التي تشغّل شيفرة من نسخ مشتقة (forks).
• ثبّت إجراءات خط النشر الخارجية وصور الأساس على إصدار محدد أو بصمة (digest)، لا على وسم متحرك.

عامل السكربتات الخارجية في المتصفح بالعناية نفسها. أداة دردشة أو مدير وسوم يعمل بكامل صلاحيات صفحتك، فحمّل أقل عدد ممكن، وقيّدها بسياسة CSP، وأبعدها عن الصفحات التي تتعامل مع كلمات المرور أو المدفوعات.

أمن تطبيقات الجوال

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

المرجع المعياري هو معيار OWASP للتحقق من أمن تطبيقات الجوال (MASVS)، مع دليل اختبار أمن تطبيقات الجوال (MASTG) الذي يشرح كيف يُختبر كل بند. والتطبيق الأصلي والتطبيق متعدد المنصات المبني بـ Flutter أو React Native يواجهان التهديدات نفسها؛ فالإطار يغيّر طريقة تعبئة الشيفرة لا ما يريده المهاجم. أما الاختيار بينهما فقرار مستقل، نناقشه في مقال الأصلي أم متعدد المنصات.

ما تفعله على الجهاز

على الخادم ألا يثق بالتطبيق

التعتيم (obfuscation) وكشف الجهاز المخترَق (root وjailbreak) وخدمات التصديق مثل Play Integrity API وApple App Attest ترفع جهد المهاجم وتعطي خادمك إشارة. لكن لا شيء منها دليل قاطع لأن المهاجم يتحكم في الجهاز. ومهما أبلغ التطبيق، يبقى الخادم هو الذي يصادق كل طلب ويتحقق من التفويض ويحدّ من الإساءة.

خطط للتحديثات

تبقى إصدارات التطبيق القديمة في أيدي المستخدمين أشهرًا. حدّد في واجهة API أدنى إصدار مدعوم وأضف تنبيهًا داخل التطبيق للتحديث، ليصل الإصلاح الحرج إلى المستخدمين. وحافظ على تحديث مجموعات SDK الخارجية، وتأكد أن إقرارات الخصوصية في المتجر تطابق ما يفعله التطبيق فعلًا.

الاختبار: المراجعة والأتمتة واختبار الاختراق

لا توجد طريقة واحدة تكشف كل شيء. فاجمع الطبقات: يكشف الناس عيوب التصميم والمنطق، وتكشف الأدوات الأنماط المعروفة بسرعة، ويهاجم مختبِر مستقل النظام كله كما يفعل مهاجم حقيقي.

مراجعة الشيفرة بعين أمنية

أضف أسئلة أمنية إلى قالب المراجعة. هل تتحقق نقطة النهاية هذه من هوية المستدعي ومن السجل الذي يحق له لمسه؟ هل كل استعلام مُمَعلم؟ هل يضيف التغيير سرًا أو اعتمادية أو نوعًا جديدًا من البيانات؟ وللمجالات عالية الخطورة، كالمصادقة والمدفوعات ومعالجة الملفات وأدوات الإدارة، اطلب موافقة مراجع مدرَّب على الأمن. وتكشف مراجعة الشيفرة الآمنة المتخصصة لهذه المجالات قبل الإطلاق ما تفوّته المراجعة اليومية، ومن طرق الحصول عليها خدمة مراجعة الشيفرة الآمنة لدينا.

الفحوص الآلية في خط البناء

اجعل الفحوص المهمة تمنع الدمج، وأرسل البقية إلى قائمة مهام مرئية. الماسح الذي لا يقرأ نتائجه أحد ضجيج لا أكثر.

اختبار الاختراق

اختبار الاختراق هجوم مصرَّح به ومحدود بالوقت يقوم به شخص متمرس على تطبيقك العامل. يسرد فحص الثغرات المشكلات المعروفة آليًا، بينما يربط المختبِر نقاط الضعف ببعضها ويسيء استخدام منطق العمل، كما يشرح مقالنا عن اختبار الاختراق وفحص الثغرات. خطط لاختبار قبل الإطلاق وبعد التغييرات الكبيرة، وبصورة دورية للتطبيقات التي تحمل بيانات حساسة.

• اتفق كتابةً على النطاق ونافذة الاختبار وقواعد الاشتباك.
• اختبر بيئة قريبة من الإنتاج ببيانات وهمية، وامنح المختبِرين حسابًا لكل دور.
• اطلب نتائج قابلة للتكرار وخطورة مقدَّرة في سياقك ونصائح للإصلاح، لا مجرد مخرجات ماسح.
• خصّص وقتًا للإصلاح واطلب إعادة اختبار للنتائج الخطيرة.

وإن أردت مختبِرًا من خارج الفريق فاطلع على خدمة اختبار الاختراق لدينا.

بوابات الإصدار والتعامل مع الثغرات

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

بوابة إصدار تستحق الاعتماد

• تنجح كل الاختبارات، ومنها الاختبارات الأمنية للتحكم في الوصول ومعالجة المدخلات.
• لا نتائج حرجة أو عالية معلقة من الفحوص أو المراجعات أو اختبارات الاختراق، أو استثناء مسجَّل لكل منها.
• فحص الأسرار نظيف، والإنتاج يستخدم أسرارًا لا تراها بيئة التجربة.
• الإنتاج مُحصَّن: أوضاع التصحيح وصفحات الأخطاء المفصلة مغلقة، والحسابات الافتراضية محذوفة، وأدوات الإدارة مغلقة أمام الإنترنت العام، وسياسة CORS محصورة في مصادر معروفة.
• ترويسات الأمن مضبوطة: Strict-Transport-Security وContent-Security-Policy مع frame-ancestors وX-Content-Type-Options وReferrer-Policy.
• السجلات والتنبيهات تعمل، وجُرّبت استعادة النسخ الاحتياطية، وتوجد خطة تراجع. وفي الجوال تُوقَّع نسخ الإصدار بمفاتيح محمية ويُغلق وضع التصحيح.

سجّل وراقب واستعد

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

اكتب خطة قصيرة للحوادث قبل أن تحتاجها: من يقرر، وكيف تُبطل المفاتيح والجلسات، وأين السجلات، وكيف تُبلغ المستخدمين. وتختلف واجبات إبلاغ الجهات التنظيمية أو المستخدمين بعد الاختراق باختلاف القانون والقطاع، فتأكد منها مع مستشار قانوني مؤهل مسبقًا، لا أثناء الحادثة.

استقبل البلاغات وأصلح الثغرات

سيجد شخص من خارج فريقك عيبًا يومًا ما، فامنحه طريقة آمنة ليخبرك. انشر سياسة للإفصاح عن الثغرات تغطي النطاق وما تطلبه من المبلّغين وما يتوقعونه منك؛ وسياستنا للإفصاح عن الثغرات مبنية هكذا. وينشر كثير من الفرق أيضًا ملف security.txt (وفق RFC 9116) ليجد الباحثون جهة الاتصال بسرعة.

1. أقرّ باستلام البلاغ وأعد إنتاج المشكلة.
2. قدّر الخطورة في سياقك: من يستطيع استغلالها وماذا يكسب. تساعد درجة مثل CVSS لكنها مُدخل لا الجواب.
3. عيّن مسؤولًا وموعدًا مستهدفًا بحسب الخطورة.
4. أصلح السبب لا العَرَض فقط، وأضف اختبارًا يفشل إذا عادت الثغرة.
5. أصدر الإصلاح، وأبلغ المتأثرين عند الحاجة، وأجرِ مراجعة بلا لوم: أي بوابة كان ينبغي أن تلتقطها؟

قائمة تحقق للتطبيق الآمن يمكنك نسخها

استخدمها قائمة أولى لأداة متابعة المهام، واحذف منها أو أضف إليها بما يناسب منتجك. كل بند سؤال إجابته نعم أو لا.

التصميم

• هل لدينا قائمة مكتوبة بالأصول ونموذج تهديدات لكل مسار أساسي؟
• هل المتطلبات الأمنية مكتوبة بصيغة نستطيع اختبارها؟

البناء

• هل كل استعلام مُمَعلم وكل مخرج مرمَّز بحسب سياقه؟
• هل تتحقق كل نقطة نهاية من هوية المستدعي ومن السجل الذي يحق له لمسه؟
• هل الأسرار بعيدة عن الشيفرة والعملاء؟

التحقق

• هل تعمل فحوص الاعتماديات والتحليل الساكن والأسرار مع كل طلب دمج؟
• هل أُجري اختبار اختراق مستقل، وأُعيد اختبار النتائج الخطيرة؟

الإصدار والتشغيل

• هل بوابة الإصدار مكتوبة ومؤتمتة قدر الإمكان؟
• هل تُسجَّل الأحداث الأمنية وتُراقب، وتصل التنبيهات إلى شخص؟
• هل لدينا خطة للحوادث، واستعادة مجرَّبة، وطريقة منشورة للإبلاغ عن الثغرات؟

عمل الأمن لا ينتهي، لكنه يصبح أرخص حين يكون جزءًا من كل دورة عمل بدل أن يكون إنقاذًا قبل الإطلاق. وإن أردت عينًا ثانية فخدمة الأمن السيبراني لدينا تغطي نمذجة التهديدات ومراجعة الشيفرة الآمنة واختبار الاختراق.