قائمة التحقق من أمان الويب ٢٠٢٦:
١٧ شيئاً تغفله معظم الوكالات

لماذا يهم هذا في ٢٠٢٦

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

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

القائمة الكاملة

١. ترويسات الأمان المفقودة

هذا هو الإيجاد الأكثر شيوعاً. ترويسات الأمان مجانية، تستغرق ٥ دقائق للإعداد، وتمنع فئات كاملة من الهجمات. تحقق من موقعك على securityheaders.com — إذا لم تحصل على تقييم A أو A+، فأنت مكشوف.

الترويسات الدنيا المطلوبة: Content-Security-Policy، X-Frame-Options، X-Content-Type-Options، Referrer-Policy، Permissions-Policy، وStrict-Transport-Security (HSTS).

٢. حقن SQL عبر الاستعلامات الخام

لا يزال يظهر في ٢٠٢٦. المطورون غالباً ما يستخدمون استعلامات خام للتصفية المعقدة وينسون تهيئة المعاملات. أي إدخال مستخدم يمس استعلام قاعدة بيانات يجب أن يمر عبر prepared statements أو query builder — بدون استثناء.

٣. معرفات الجلسة المتوقعة

رموز جلسة ضعيفة أو معرفات تُضمِّن معلومات المستخدم قابلة للاستغلال. معرفات جلستك يجب أن تكون عشوائية تشفيرياً ولا تحتوي على بيانات مستخدم قابلة للفك.

٤. غياب حماية CSRF على النقاط التي تغير الحالة

رموز CSRF مطلوبة على كل نقطة POST وPUT وPATCH وDELETE. نجد بانتظام نقاط API ومسارات AJAX تتجاوز middleware الـ CSRF لأن المطورين افترضوا أن "لا متصفح سيرسل هذا." المهاجمون يعرفون عكس ذلك.

٥. ملفات .env والإعداد المكشوفة

لا يزال مقلقاً بشكل مزعج. Nginx أو Apache المُهيَّأ بشكل خاطئ سيخدم .env أو .git/config لأي شخص يطلبه. ملف .env يحتوي على بيانات اعتماد قاعدة البيانات ومفاتيح API ومفاتيح التشفير. أضف قواعد رفض صريحة لهذه الملفات وتحقق بـ curl https://yourdomain.com/.env.

٦. المراجع المباشرة غير الآمنة (IDOR)

الثغرة الأكثر تأثيراً التي نجدها. تحدث IDOR عندما يمكن للمستخدم الوصول إلى مورد مستخدم آخر بمجرد تغيير معرف في URL — مثلاً /invoices/1234 يعرض بياناتك، لكن /invoices/1235 يعرض بيانات شخص آخر. كل وصول للبيانات يجب أن يتحقق من أن المستخدم المصادق يملك المورد المطلوب.

٧. رفع الملفات بدون قيود

قبول رفع الملفات دون التحقق من النوع والحجم والمحتوى يسمح للمهاجمين برفع shells PHP أو scripts خبيثة. لا تثق أبداً بترويسة Content-Type وحدها — افحص bytes السحرية الفعلية للملف. خزّن الملفات المرفوعة خارج webroot أو في خدمة تخزين منفصلة.

٨. رسائل الخطأ التفصيلية في الإنتاج

رسائل الخطأ التي تكشف stack traces أو استعلامات قاعدة البيانات أو مسارات الملفات أو إصدارات الإطار تمنح المهاجمين خريطة لتطبيقك. APP_DEBUG=true في الإنتاج مشكلة حرجة. رسائل الخطأ للمستخدمين يجب أن تكون عامة؛ التفاصيل تذهب فقط لنظام التسجيل.

٩. غياب تحديد معدل الطلبات (Rate Limiting)

نقاط تسجيل الدخول وإعادة تعيين كلمة المرور والتحقق OTP ونقاط API بدون rate limiting عرضة لهجمات القوة العمياء وهجمات العداد. طبّق rate limiting قائماً على IP على مستوى التطبيق ومستوى Cloudflare. ٥ محاولات/دقيقة/IP لنقاط تسجيل الدخول نقطة بداية معقولة.

١٠. سياسات كلمات المرور الضعيفة

كثير من التطبيقات لا تزال تقبل كلمات مرور من ٦ أحرف ولا تتحقق من قواعد البيانات المخترقة المعروفة. حد أدنى ١٠ أحرف، متطلبات تعقيد، والتكامل مع HaveIBeenPwned API لحجب كلمات المرور المخترقة المعروفة.

١١. غياب Subresource Integrity (SRI) للـ Scripts الخارجية

إذا كنت تحمّل JavaScript أو CSS من CDN، يمكن لـ CDN مخترق حقن كود خبيث في موقعك. أضف سمات integrity وcrossorigin لجميع الموارد الخارجية. هذا حرج بشكل خاص لصفحات الدفع أو المصادقة.

١٢. صلاحيات مستخدم قاعدة البيانات المفرطة

مستخدمو قاعدة بيانات التطبيق الذين يمكنهم DROP TABLE أو CREATE USER كارثة في انتظار الحدوث. مستخدم قاعدة البيانات الذي يستخدمه تطبيقك يجب أن يملك صلاحيات SELECT وINSERT وUPDATE وDELETE فقط على الجداول التي يحتاجها — لا أكثر.

١٣. البيانات الحساسة غير المشفرة في قاعدة البيانات

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

١٤. غياب إعادة توجيه HTTP/HTTPS

التطبيقات التي تخدم المحتوى عبر HTTP وHTTPS معاً تسمح للمهاجمين بهجمات SSL stripping. أجبر HTTPS في كل مكان، واضبط ترويسة HSTS مع max-age طويل، وفكر في التسجيل في HSTS preload list.

١٥. الاعتماديات القديمة بثغرات معروفة (CVEs)

شغّل composer audit (PHP) أو npm audit (Node.js) على كل تطبيق إنتاجي الآن. CVEs المعروفة في حزم الطرف الثالث تُستغل بشكل نشط. أتمت فحص الاعتماديات في pipeline CI/CD — GitHub Dependabot مجاني.

١٦. غياب Web Application Firewall (WAF)

الخطة المجانية من Cloudflare تشمل WAF أساسياً. خططهم المدفوعة تشمل مجموعات قواعد مدارة تحجب هجمات OWASP Top 10 على الحافة قبل أن تصل لخادمك. لأي تطبيق إنتاجي يتعامل مع بيانات المستخدمين أو المدفوعات، WAF غير قابل للتفاوض.

١٧. غياب المراقبة والتنبيه

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

تطبيق هذه القائمة على تطبيقك

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