قائمة عملية من سبعة مجالات، لكل بند فيها سببه في كلمات قليلة، تستخدمها عند بدء مشروع الويب وقبل إطلاقه.
المشروع الآمن افتراضيًا هو الذي يكون الخيار الأسلم فيه هو ما تحصل عليه دون جهد إضافي: جلسات محكمة، واستعلامات بمعاملات، وأسرار خارج الشيفرة، ولا شيء يُطلق قبل أن يتحقق منه أحد. تغطي هذه القائمة سبعة مجالات، ولكل بند فيها سببه في كلمات قليلة، لتحكم بنفسك هل ينطبق على منتجك بدل أن تضع عليه علامة دون تفكير.
كيف تستخدم هذه القائمة
مرّ عليها مرتين: مرة عند بدء المشروع حين يكون التغيير رخيصًا، ومرة قبل الإطلاق بوصفها بوابة إصدار. انسخ البنود إلى أداة المهام عندكم، وسجّل لكل بند إحدى ثلاث إجابات: تم، أو لا ينطبق (مع السبب)، أو خطر مقبول (مع مسؤول باسمه وموعد لإعادة النظر).
القائمة حدٌّ أدنى لا سقف. هي تمنع أخطاء شائعة، يرد كثير منها في قائمة [OWASP Top 10](/glossary/owasp-top-10)، لكنها لا تغني عن التفكير في قواعد منتجك أنت.
الحسابات والجلسات
| البند | السبب |
|---|---|
| جزّئ كلمات المرور بدالة مصممة لذلك، مثل Argon2id أو scrypt أو bcrypt. | قاعدة بيانات مسروقة لا ينبغي أن تسلّم كل كلمات المرور. |
| اشترط [المصادقة متعددة العوامل](/glossary/multi-factor-authentication) لحسابات الإدارة والموظفين، وأتحها للعملاء. | كلمة مرور مسرّبة وحدها لن تفتح بعدها شيئًا مهمًا. |
| افحص الصلاحيات على الخادم في كل طلب، بحسب المستخدم المسجّل والعنصر المطلوب معًا. | إخفاء زر ليس ضابطًا أمنيًا. وتغيير رقم في العنوان هو الباب الكلاسيكي للاختراق. |
| اضبط ملفات تعريف الارتباط للجلسة بالخصائص HttpOnly وSecure وSameSite. | لا تقرؤها سكربتات الصفحة، ولا تنتقل إلا عبر HTTPS، ومعظم الطلبات القادمة من مواقع أخرى لا تحملها. |
| أصدر معرّف جلسة جديدًا عند تسجيل الدخول وعند تغيّر الصلاحيات، وأنهِ الجلسات الخاملة. | المعرّف الذي زُرع قبل الدخول يتوقف عن العمل، ولا تبقى نافذة منسية مفتوحة إلى الأبد. |
| احمِ الطلبات التي تغيّر البيانات من تزوير الطلبات عبر المواقع (CSRF). | يرسل المتصفح ملفات تعريف الارتباط حتى حين تطلق صفحة خبيثة الطلب. |
| حدّد عدد محاولات الدخول وإعادة التعيين، واجعل روابط إعادة التعيين صالحة لمرة واحدة ولمدة قصيرة. | يمنع تخمين كلمات المرور وإعادة استخدام بريد قديم. |
المدخلات والمخرجات
كل ما يصل من الخارج مدخل لا تتحكم فيه. وكل ما ترسله إلى الخارج يقع في مكان له قواعده الخاصة.
- **تحقّق على الخادم بقائمة مسموح بها** من النوع والطول والمدى والصيغة. فتحقق المتصفح مجاملة لا أكثر، لأن المهاجم يرسل الطلبات مباشرة.
- **استخدم استعلامات بمعاملات** أو الأساليب الآمنة في طبقة ORM، ولا تبنِ SQL من نصوص مدموجة. بهذا يُغلق الباب أمام [حقن SQL](/glossary/sql-injection).
- **رمّز المخرجات بحسب المكان الذي تقع فيه:** HTML أو خاصية أو عنوان أو سكربت. اعتمد على التهريب التلقائي في إطار العمل، وراجع كل منفذ يتيح إدراج HTML خام. وهذا خط الدفاع الأول ضد [البرمجة النصية عبر المواقع](/glossary/cross-site-scripting).
- **عامل الملفات المرفوعة على أنها معادية.** افحص نوع الملف من محتواه لا من اسمه، وحدّد حجمًا أقصى، واحفظ الملفات خارج جذر الويب بأسماء تولّدها أنت، ولا تنفّذها أبدًا.
- **قيّد العناوين التي يجلبها خادمك نيابة عن المستخدمين.** اسمح بمضيفات مسماة واحجب العناوين الداخلية، وإلا تحولت ميزة معاينة الروابط إلى سلاح موجّه إلى شبكتك.
- **أعد الحقول التي تحتاجها الشاشة فقط.** واجهة API التي ترسل سجل قاعدة البيانات كاملًا تسرّب ما اختارت الواجهة الرسومية إخفاءه.
الترويسات ونقل البيانات
تطبّق المتصفحات مجموعة من الحمايات، لكن بشرط أن يطلبها الخادم عبر ترويسات الاستجابة.
| الإعداد | ما يفعله وسببه |
|---|---|
| HTTPS في كل مكان، مع إعادة توجيه من HTTP وترويسة Strict-Transport-Security (HSTS) وإصدارات TLS الحديثة (1.2 و1.3) وشهادات تتجدد تلقائيًا | لا يمكن قراءة الحركة أو تعديلها في الشبكات المشتركة، ويرفض المتصفح الرجوع إلى HTTP العادي. ابدأ بمدة قصيرة لـ HSTS ثم أطِلها. وشهادة منتهية تُسقط الموقع. |
| Content-Security-Policy | تحدد المصادر التي يجوز تحميل السكربتات والأنماط والإطارات منها، فيُوقَف السكربت المحقون حتى لو أفلتت ثغرة. |
| X-Content-Type-Options: nosniff | يمنع المتصفح من تخمين نوع الملف، وهو تخمين قد يحوّل ملفًا مرفوعًا إلى سكربت. |
| التوجيه frame-ancestors أو الترويسة X-Frame-Options | يمنع المواقع الأخرى من تضمين صفحاتك، وهكذا تعمل هجمات الاختطاف بالنقر (clickjacking). |
| Referrer-Policy: strict-origin-when-cross-origin | يبقي العناوين الكاملة، وقد تحمل رموزًا، خارج الطلبات التي ترسلها صفحتك إلى مواقع أخرى. |
| CORS: سمِّ المصادر المسموح بها، ولا تعد أبدًا أي مصدر يصلك حين يُسمح بالاعتمادات | وإلا استطاع أي موقع قراءة استجابات مخصصة لمستخدميك المسجّلين. |
اعتبر الترويسات شبكة أمان لا علاجًا. فالسياسة لا تبرر مخرجات غير مهرَّبة. وأطلق [سياسة أمان المحتوى](/glossary/content-security-policy) في وضع التقرير فقط أولًا، لتعرف ما الذي ستكسره قبل أن تكسره فعلًا.
الأسرار والإعدادات
- **أبقِ الأسرار خارج المستودع، وخارج سجله أيضًا.** استخدم متغيرات البيئة لدى المضيف أو مدير أسرار. ودوّر أي سر أُودع يومًا، فحذف الملف لا يحذف السجل.
- **استخدم أسرارًا مختلفة لكل بيئة.** مفتاح تسرّب من بيئة تجريبية يجب ألا يفتح الإنتاج.
- **فعّل فحص الأسرار،** وفحصًا قبل كل دفع إن أمكن، ليُكتشف الخطأ في ثوانٍ.
- **اعرف ما يرسله إطار العمل إلى المتصفح.** في Next.js مثلًا توضع المتغيرات التي تبدأ أسماؤها بـ NEXT_PUBLIC_ في شيفرة المتصفح. ولا يجوز أن يحمل أي سر هذه البادئة.
- **امنح كل حساب ومفتاح أقل صلاحية يحتاجها.** مستخدم قاعدة البيانات في التطبيق لا ينبغي أن يستطيع حذف الجداول. فيكون ضرر أي خطأ محدودًا.
- **راجع إعدادات الإنتاج الافتراضية.** أطفئ وضع التصحيح وصفحات الأخطاء المفصلة، واحذف الحسابات التجريبية والافتراضية، وأبقِ قواعد البيانات ولوحات الإدارة بعيدًا عن الإنترنت العام.
الاعتمادات والمكتبات
- **أودع ملف القفل (lockfile) وثبّت منه في البناء،** ليستخدم كل بناء الإصدارات نفسها التي اختبرتها.
- **افحص الاعتمادات في كل طلب دمج وعلى جدول زمني.** تُنشر ثغرات جديدة في مكتبات تستخدمها أصلًا.
- **أضف الحزمة لسبب وجيه.** انظر من يصونها ومتى حُدّثت آخر مرة، واسأل هل تكفي بضعة أسطر من شيفرتك. فكل حزمة تعمل بصلاحيات تطبيقك.
- **احذف ما لم تعد تستخدمه، وثبّت أدوات البناء وخطوات الأتمتة** على إصدارات محددة. فيقل ما تحتاج إلى ترقيعه، ولا يتغير شيء من تحتك دون إنذار.
- **قرّر مسبقًا مدى سرعة نشر الإصلاح الحرج،** ومن يملكه. وحين يصلك تنبيه، اسأل هل الشيفرة المعرضة للثغرة قابلة للوصول فعلًا في منتجك.
السجلات والتعافي
تحدد هذه البنود هل ستلاحظ الحادثة، وماذا ستتعلم منها، وبأي سرعة ستتعافى.
| البند | السبب |
|---|---|
| سجّل الأحداث الأمنية: تسجيل الدخول ومحاولاته الفاشلة، وتغيير كلمة المرور والمصادقة متعددة العوامل، وتغيير الصلاحيات، وإجراءات الإدارة، والطلبات المرفوضة. | لا يمكنك التحقيق فيما لم تسجّله. |
| أبقِ كلمات المرور والرموز وأرقام البطاقات الكاملة والبيانات الشخصية خارج السجلات. | تُنسخ السجلات إلى أدوات كثيرة وتُحفظ زمنًا طويلًا. |
| أرسل السجلات إلى مكان منفصل لا يستطيع التطبيق تعديله. | المهاجم الذي يدخل التطبيق يجب ألا يتمكن من محو أثره. |
| نبّه على إشارات قليلة سيتحرك أحد بسببها، كتكرار فشل الدخول أو ظهور مسؤول جديد. | سجلات لا يقرؤها أحد لا تحمي شيئًا. |
| خذ نسخًا احتياطية آلية للبيانات، وجرّب الاستعادة منها. | نسخة احتياطية لم تُستعد قط أمل لا خطة. |
| اكتب خطة حوادث من صفحة واحدة: من يقرر، ومن يُتصل به، وكيف تُلغى المفاتيح والجلسات، وكيف يُبلَّغ المستخدمون. | تمر الساعة الأولى أفضل حين تكون القرارات قد اتُّخذت قبلها. |
بوابة الإطلاق
قبل الإطلاق حوّل القائمة إلى اعتماد قصير يستطيع شخص غير كاتب الشيفرة أن يجيب عنه بنعم.
وهذه أيضًا طريقتنا في المنتجات التي نبنيها: يبدأ كل مشروع بمراجعة للتهديدات، وتسلّمك مراجعة أمنية قبل الإطلاق قائمة إصلاحات مرتبة حسب الأولوية. وتشرح صفحة [خدمة الأمن السيبراني](/services/cybersecurity) كيف يتم ذلك.
ما لا تغطيه هذه القائمة
تلتقط القائمة الأخطاء المعروفة. أما عيب في قواعدك أنت، كخصم يمكن تطبيقه مرتين، فلا تراه. وهذا مستوى التصميم الذي تتناوله [نمذجة التهديدات](/glossary/threat-modelling)، أما النظام العامل فيفحصه [اختبار الاختراق](/blog/penetration-test-vs-vulnerability-scan).
ولا تخبرك القائمة أيضًا أي القوانين تنطبق على بياناتك. فأحكام البيانات الشخصية تختلف بحسب البلد والقطاع، فتأكد مما ينطبق عليك مع مستشار قانوني مؤهل. وللصورة الأوسع، من المتطلبات إلى الإطلاق، اقرأ [دليل تطوير التطبيقات الآمنة](/guides/secure-app-development).