يا صديقي المطوّر، إذا فكّرت إنو خلصت شغلك وقت ما خلصت الكود ورفعت المشروع على السيرفر… فأنت بخطر 
لأنو أكبر المشاكل بتبلّش بعد النشر!
التصميم والبرمجة مهمين، بس إذا ما حطيت اعتبار للثغرات الأمنية، فمشروعك عبارة عن صندوق كنز مفتوح للهاكرز 
خلينا نغوص سوا بأشهر الثغرات، الأمثلة الواقعية، والحلول يلي بتحمي شغلك.
١. SQL Injection – حقن الاستعلامات
أشهر وأقدم ثغرة، وللأسف بعدها موجودة كتير لليوم.
شو بصير؟
الموقع بياخد مدخل من المستخدم (متل اسم مستخدم أو ID)، وبيحطه جوّا استعلام SQL بدون تعقيم، فالمهاجم بيحقن كود ضار.
مثال واقعي:
موقع Yahoo بـ 2012 انضرب، وتسرّب منه أكتر من 450 ألف حساب.
الحل:
استخدم دائمًا prepared statements أو ORM (متل Eloquent بلارافيل أو Prisma بنود).
٢. XSS – Cross-site Scripting
ثغرة بتسمح بزرع سكربت جافاسكريبت ضمن الموقع.
شو بصير؟
مهاجم بيزرع كود ضمن كومنت أو اسم مستخدم، والموقع بعرضه بدون تعقيم → الكود بنفذ بمتصفح الضحية.
مثال:
موقع eBay اتعرض لكتير XSS بثغرات ضمن صفحات المنتجات.
الحل:
- Escaping للمخرجات (output)
- فلترة المدخلات
- Content Security Policy (CSP)
٣. CSRF – Cross-site Request Forgery
هجوم بيستغل وجودك كمستخدم مسجّل (وعندك توكن دخول)، وبيخليك تنفّذ عملية بدون ما تعرف.
مثال:
ثغرة بـ Netflix كانت بتسمح بتغيير البريد الإلكتروني للمستخدم!
الحل:
- استخدم CSRF tokens
- حدد الـ HTTP method (POST بدل GET)
- تحقق من Origin/Referer
٤. IDOR – Insecure Direct Object Reference
ثغرة بتسمح للمهاجم يوصل لموارد مو إله، من خلال تغيير ID بالـ URL أو البيانات.
مثال:
ببعض مواقع الدفع، المستخدم غيّر رقم الطلب بـ URL وقدر يشوف فواتير ناس تانية 
الحل:
- تحقق من ملكية البيانات بالسيرفر (مش بس الرقم!)
- لا تعتمد فقط على IDs بالـ frontend.
٥. RCE – Remote Code Execution
أخطر نوع، لأنه بيعطي صلاحية تنفيذ أوامر على السيرفر.
مثال:
ثغرة Log4Shell (2021) ضربت ملايين السيرفرات حول العالم بسبب مكتبة بسيطة بلوجات الجافا!
الحل:
- راقب مكتبات الطرف الثالث
- حدث بشكل مستمر
- استخدم sandbox أو isolated execution إذا ممكن
٦. SSRF – Server-side Request Forgery
ثغرة بتخلي الموقع يعمل طلبات داخلية على الخوادم (حتى لو كانت محمية).
مثال:
شركة Capital One انضربت بهالثغرة بسبب صلاحيات زيادة، وانسرق أكتر من 100 مليون سجل!
الحل:
- لا تسمح بطلبات HTTP من السيرفر بناءً على مدخل المستخدم
- فلترة العناوين، رفض الـ localhost والـ metadata IPs
٧. File Upload Vulnerabilities
رفع ملف بدون تحقق؟ مبروك، فتحت باب بيتك للهاكر 
مثال:
بعض إضافات WordPress كانت تسمح برفع ملفات PHP وتشغيلها!
الحل:
- حدد الامتدادات المقبولة
- تحقق من الـ MIME type
- غيّر اسم الملف بعد الرفع
- خزن الملفات بمكان غير قابل للتنفيذ
٨. Open Redirect
بيسمح بإعادة توجيه الزوار لموقع خارجي، ممكن يستخدم بالهندسة الاجتماعية (phishing).
مثال:
كتير من روابط إعادة التوجيه (redirect) بمواقع كبيرة انضربت بهالطريقة، متل Google وLinkedIn.
الحل:
- لا تستقبل رابط إعادة التوجيه كـ GET param
- إذا ضروري، فلتره وتأكّد من الدومين
٩. Email Spoofing / Phishing
أنت ممكن تبعت إيميلات من موقعك، بس إذا ما ضبطت الـ DNS بشكل منيح، ممكن حدا تاني يبعث إيميلات باسمك!
الحل:
- طبّق SPF, DKIM, وDMARC بسجلات DNS
- راقب سمعتك البريدية
١٠. Business Logic Vulnerabilities
هاي الأخطر أحيانًا، وبتجي من سوء تصميم منطق الموقع.
مثال:
موقع بيع إلكتروني سمح للناس يغيروا سعر المنتج عن طريق الـ JavaScript بالمتصفح قبل الإرسال 
الحل:
- لا تثق أبدًا بأي شي جاي من الـ frontend
- راجع منطق الدفع/الخصم بالسيرفر
١١. Rate Limiting & Brute Force
إذا ما حطيت حد لمحاولات الدخول، الهاكر رح يحاول يحزر الباسورد للصبح 
الحل:
- حد المحاولات (Rate Limit)
- CAPTCHA
- 2FA للمستخدمين
١٢. Misconfigured Permissions
Permissions غلط = وصول غير شرعي 
مثال:
ثغرات S3 buckets بأمازون بسبب إعدادات عامة (Public Read).
الحل:
- راجع صلاحيات الملفات والمجلدات
- خليك دايمًا بـ principle of least privilege
١٣. Clickjacking
الموقع بينعرض ضمن iframe، والمستخدم بيضغط على شي ما بيعرفه.
الحل:
- حط
X-Frame-Options: DENY - استخدم CSP headers
نصائح ختامية:
- لا تثق بالـ frontend… أبدًا.
- دايمًا فكّر بأسوأ سيناريو، واشتغل لتمنعه.
- اختبر موقعك بأدوات اختراق أخلاقية (OWASP ZAP, Burp Suite…)
- تابع تحديثات الأمان دايمًا، خصوصًا للمكتبات الجاهزة.