أخطاء النشر على السيرفر وطرق الحماية الشائعة!

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

أول غلطة: تحط الـ Backups في الـ Home Directory ​

كتير من الناس بيرفعوا نسخة احتياطية (ZIP أو RAR) على مجلد الـ Home عشان "سهل يوصلهم". المشكلة إن ده أسهل طريق لأي حد عنده وصول بسيط للسيرفر أو بيحاول يخمن اسم الملفات. الهاكر يقدر يخمن أسماء زي code.zip أو backup.zip ويلاقي شغلك كله.

نصيحة سريعة:

• ما تحطش نسخ احتياطية في مكان متاح للويب.
• استخدم مكان خاص ومقفول أو S3/Storage خارجي.
• خليك دايمًا مشفر النسخة لو مضطر تخزنها على نفس السيرفر.

مثال لو عايز تحرك ملف من public_html:

# ما تسيبش backup في public_html
mv ~/public_html/code.zip ~/backups/code_$(date +%F).zip
chmod 600 ~/backups/code_$(date +%F).zip

تسيب مجلد الـ .git بعد الـ Deploy - خطأ كارثي ​

لو نسيت تمسح مجلد .git بعد الرفع، أي حد هيقدر يعمل clone للمشروع أو يشوف الـ history ويطلع ملفات حساسة (زي config أو ملفات تحتوي على Secrets).

حلول عملية:

• احذف المجلد بعد الـ deploy: rm -rf .git
• أو امنع الوصول عبر الـ web server (مثال nginx):

location ~ /\.git {
    deny all;
    return 404;
}

• لو بتستخدم Git على السيرفر، خليك متأكد إن مجلد الـ repo مش في مكان متاح للويب.

صلاحيات ملفات الـ Configuration غلط - ودي بتفتح باب للسرقة ​

أنا بشوف ملفات زي .env بصلاحيات 777 وموجودة في فولدر متاح للويب - وده بيسهل لأي أداة بحث أو هكر إنها تقرا الإعدادات: DB، API keys، إلخ.

نصيحة مهمة:

• امنح الملفات الحساسة صلاحيات ضيقة: chmod 600 .env
• خلي صاحب الملف هو المستخدم اللي بيشغل التطبيق (مثلاً www-data).

chown www-data:www-data .env
chmod 600 .env

• استخدم secrets manager لو أمكن (AWS Secrets Manager, Vault,...).

تسيب Debug Mode شغال في الـ Production - هدية للهاكر ​

لو تركت الـ Debug شغال، أي error هيطلعلك Stack Trace مليان معلومات عن الكود، المكتبات، والـ paths - كل التفاصيل دي بتسهل عملية الاستغلال.

افعل دايمًا:

• تأكد إن APP_DEBUG=false في الـ env بتاع الـ production.
• درّج رسالة الخطأ للمستخدم بحيث تكون عامة ومفيهاش معلومات تقنية.
• فعل نظام logging داخل السيرفر بدل من إظهار الأخطاء للزوار.

صفحة الـ Administrator متاحة لكل الناس - غلطة بتفتح الباب قدام التخمين ​

لو لوحة الإدارة (/admin أو /dashboard) متاحة لأي حد، يبقى قدامهم محاولات تخمين كلمات مرور، brute-force، والهجمات. لازم تقلل النقاط المكشوفة.

اللي ممكن تعمله:

• استخدم IP-based restriction لو الإدارة من مكان ثابت.
• فعل 2FA على حسابات المسؤولين.
• استخدم Zero Trust / VPN للوصول للوحة.
• غيّر روابط الدخول الافتراضية (مش حل وحيد لكن بيصعب الأمور شوية).

مثال بسيط في nginx لحظر غير الـ IP معين:

location /admin {
    allow 1.2.3.4;
    deny all;
}

نسيان عمل Rate Limit - ممكن يخسرك فلوس وموارد ​

خاصًة لو عندك أنظمة بتكلف (SMS OTP، إيميلات مدفوعة)، عدم وجود Rate Limit يخلي المهاجم يبعت آلاف الطلبات ويكلفك كتير.

نقاط مهمة:

• لازم تحط حد للطلبات لكل IP أو لكل حساب على endpoints الحساسة (OTP, Password Reset, Contact Form).
• استخدم caching أو queue للحفاظ على الموارد.
• مثال بسيط في nginx:

limit_req_zone $binary_remote_addr zone=one:10m rate=10r/m;
server {
    location /api/ {
        limit_req zone=one burst=20 nodelay;
        ...
    }
}

شوية نصايح إضافية سريعة وعملية ​

• Scan الكود قبل الرفع بأدوات Static Analysis زي bandit للـ Python أو npm audit للجافاسكريبت.
• فعل HTTPS وForce HTTPS للـ site كله.
• حدّث الـ dependencies بانتظام وما تترك Libraries قديمة.
• استخدم WAF أو طبقة حماية لو تقدر.
• راجع الLogs بانتظام عشان تلاقي محاولات اختراق بدري.

مثال عملي لخطوات جاهزة قبل كل Deploy ​

1. شغل اختبارات الوحدة (unit tests) وCI.
2. خفّض صلاحيات الملفات الحساسة: chmod 600 .env.
3. احذف .git أو امنعه من الوصول.
4. تأكد APP_DEBUG=false.
5. امنع الوصول للـ backups من public folder.
6. فعل Rate Limit و2FA.
7. شغل مسح سريع للـ vulnerabilities.

خاتمة - اختصرها في 3 حاجات ​

1. متسيبش حاجات حساسة في المكان اللي أي حد يوصل له.
2. خلي صلاحيات الملفات مظبوطة وما تسيبش Debug شغال.
3. احمِ صفحة الإدارة وفعل Rate Limit عشان تحمي مستخدمينك وفلوسك.